Family Naming Robofont

Has anyone transitioned from FontLab to Robofont that previously used Karsten's Font Naming with FontLab and is there some type of translation? I had naming dialed with FontLab, but I'm having trouble getting the same results with Robofont. I want a naming convention that allows the individual weights to work together as a big family no matter how many styles there are.

With this example above the name takes on 'Example' instead of specifically being 'Example Regular' but all weights style-link as a family. The other variants of this naming ended up splitting all the styles into individual non style-linked fonts or still would have the indivdual fonts have the generic family name 'Example' and not named appropriately.

With this example above the name takes on 'Example' instead of specifically being 'Example Regular'

Because
the Preferred Family Name is “Example.” Most environments these days
will respect the Preferred Family Name at the level of presentation in
the UI.

Leaving the name fields in the Font Info > OpenType and Postscript tabs empty with Use Default Value checked, as Adrien is suggesting, is a pretty solid approach. Did you try this and not get the results you wanted in generated fonts?

Yeah it's strange maybe I'm overlooking something simple, but with all default values checked except the 'General>Identification' tab no matter what I either end up with the actual font instance taking on the Family name (e.g. 'Example' instead of being 'Example Regular') and/or the Family name becomes the font instance (e.g. 'Example Regular') which separates all font styles.

With all the default values selected except for the main General Identification page being:

Family Name: ExampleStyle Name: RegularStyle Map Family Name: Example

my workaround is going into a .ttx conversion and editing the name table. I just have to change nameID="4" platformID="1" from 'Example' to 'Example Regular' and everything works, all font styles have the correct family name and correct individual style names.

Oh, right. Sorry, it’s been a couple years since I delved deeply into RF’s
basic generation. (The work I do for Font Bureau uses a proprietary
generation tool.)

Now that I look back on my notes, I recall that
there were some idiosyncrasies to the RF default generation. There are,
in fact, a few name fields that we overwrite during post-processing. I had forgotten about all that.

Not
ideal, but there it is. Not sure what others do.

FWIW, below are my notes from awhile back about what RF does by default.

Another somewhat related thing I noticed is with old FontLab generated fonts when looking say… at all the font information in a font management program the Robofont generated fonts have a 'Unique name' and 'Version' that looks a bit different.

Adrien is right. All of that RoboFont name behavior is pretty much just pure ufo2fdk -> makeotf, so it’s basically just letting Adobe’s compiler do what it does by default.

I’m pretty sure you can’t force either the Unique Name or Version nameIDs to compile differently via RoboFont-> makeotf, even if you put custom data in those Font Info fields in the UFO.

Technically speaking, the Version format you show from FontLab is not quite up-to-spec, which states that the nameID 5 “Should begin with the syntax 'Version <number>.<number>''’. So, technically, you should fill out the Complete Version Record in the FL Font Info to start with the word “Version ”. (Which then gets overwritten each time you increment the Version & Revision, so you have to do it again.) I’m not sure that most FontLab users bother. And maybe that behavior has been changed in more recent versions than I have installed (5.14).

It may not really matter, but the spec does say, “Note that some installers may require the string to start with "Version "”.

All of that RoboFont name behavior is pretty much just pure ufo2fdk -> makeotf, so it’s basically just letting Adobe’s compiler do what it does by default.

That's not what ufo2fdk does, it has fallbacks for data that wasn't filled out and can be inferred from other fields. makeotf itself doesn't do much.The documentation of ufo2fdk explain the general logic and you can look up the details in fontInfoData.py.

FYI: Naming in DTL FontMaster and GlyphMaster is stored in the ‘UFM’ (URW Font Meta data) ﬁle. The CFF table info is always taken from the UFM file, because CFF is just a compressed copy of the intermediate Type1 font temporarily created with the URW++ Type1 tool, which ‘knows’ nothing about features files. As long as one doesn’t specify a features file with it’s own name table block, CFF names are compatible because they are based on the same data source (UFM). The modified URW++ version of Adobe’s HOT tool will also take the name ID’s in the range of 1-6 (the standard range) from the UFM ﬁle.

An example of the naming part in an UFM file for OpenType CFF fonts can be found below. The entries underneath the ‘TTName’ ones are used for the CFF table.

What I was specifically thinking with that last phrase about the compiler is that, with regard to the various name fields that control menu and style-linking behaviors, there are only those few variables that get handed by ufo2fdk to makeotf in the FontMenuNameDB (four, at most) and makeotf determines how to distribute those to Mac/Win IDs 1, 2, 4, 16, 17, [& 18].

And this changed slightly with FDK v2.5, specifically Mac IDs 1 & 2. Which is a large part of the differences that I think Michael was puzzling over.

So, my point was that it’s not so much that this is how RoboFont does it, per se, as how makeotf now writes those. That, and ufo2fdk handles all those inferrable/constructable fields that we were both advising him to let RoboFont manage.

Which is basically what I thought you were pointing out. (Just not as verbosely. ;-)