Family Naming Robofont

Michael Jarboe

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.

I've tried diff. variations of this naming

General
Family Name: Example Regular
Style Name: Regular
Style Map Family Name: Example Regular

OpenType name Table
Preferred Family Name: Example
Preferred Subfmaily Name: Regular
Compatible Full Name: Example

Postscript
FontName: Example-Regular
FullName Example Regular
WeightName: Normal

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.

Michael Jarboe

In comparison, FontLab naming would look like this:

Basic set of font names
Family Name: Example Regular
Weight: Regular
Style Name: Regular
PS Font Name: Example-Regular
Full Name: Example Regular
Menu Name: (blank)
FOND Name: (blank)

OpenType-specific font names
OT Family Name: Example
OT Style Name: Regular
Mac Name: (blank)

attar

You don't need to specify OpenType/Postscript names, they'll be inferred at compile-time.

Kent Lew

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?

Michael Jarboe

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: Example
Style Name: Regular
Style 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.

Michael Jarboe

And if I check the default value for 'Style Map Family Name' in the above changing it from 'Example' to 'Example Regular' leaving everything else as was previously

Then nameID="1" platformID="1" takes on the Example Regular name

and nameID="4" platformID="3" becomes Example Regular Regular

in which case all styles become separate instances and don't combine as one family.

Kent Lew

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.

KEY (from the RoboFont Font Info > General: Identification dialog):
    Family Name = familyName
    Style Name = styleName
    Style Map Family Name = styleMapFamilyName
    Style Map Style checkboxes = styleMapStyleName

ROBOFONT Bare Bones Generation

(1, 1, 0, 0): styleMapFamilyName *
(2, 1, 0, 0): styleMapStyleName  *
(4, 1, 0, 0): familyName styleName *
(6, 1, 0, 0): familyName-styleName
(16, 1, 0, 0): familyName
(17, 1, 0, 0): styleName
(18, 1, 0, 0): styleMapFamilyName styleMapStyleName *

(1, 3, 1, 1033): styleMapFamilyName
(2, 3, 1, 1033): styleMapStyleName
(4, 3, 1, 1033): familyName styleName *
(6, 3, 1, 1033): familyName-styleName
(16, 3, 1, 1033): familyName
(17, 3, 1, 1033): styleName 

The asterisks mark those fields that we overwrite.

There’s no way around the fact of RF writing the Mac nameIDs 1 & 2 with styleMapFamilyName and styleMapStyleName. Not that I could find. Explicitly filling out OpenType name fields doesn’t help.

There aren’t a lot of apps that use the Mac nameIDs 1 & 2. But there are a few, and we write those to match the familyName and styleName.

We abbreviate and truncate the Mac nameID 4 as necessary to be ≤31 characters (according to an algorithmic schema that DJR & I devised).

We remove the Mac nameID 18 (openTypeFullCompatibleName) that RF generates.

The overwrite of Win nameID 4 to match Win nameID 6 (aka postscriptName) is an outdated requirement, but I don’t think FB is the only foundry that still does this just in case.

Michael Jarboe

Amazing Kent! I was really banging my head against the wall there and thinking I was losing my marbles.

Michael Jarboe

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.

Robofont:

Unique name
1.000;pyrs;Example-Regular
Version
Version 1.000;PS 1.0;hotconv 1.0.72;makeotf.lib2.5.5900

which isn't as clean as say in FontLab where it would be

Unique name
Foundry: Example Regular: 2015
Version
1.00

and my OCD makes me want to go in and change that info too! (any reason I should leave it as is the way it's generated from Robofont?)

attar

That's makeotf, not just robofont.

Kent Lew

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 "”.

Just saying.

attar

Kent Lew said:

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.

Thomas Phinney

But does it have overrides? That's the most important thing.

attar

Oh I think I didn't read Kent's last post properly so it seems we don't disagree, ufo2fdk doesn't alter makeotf output indeed (which is what I take Kent was saying, my bad).

LeMo aka PatternMan aka Frank E Blokland

But does it have overrides? That's the most important thing.

FYI: Naming in DTL FontMaster and GlyphMaster is stored in the ‘UFM’ (URW Font Meta data) file. 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 file.

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.

StartFontMetrics
TTName 0 1 0 0 "Copyright (c) Dutch Type Library, 2014. All rights reserved."; #Macintosh
TTName 0 3 1 0x409 "Copyright (c) Dutch Type Library, 2014. All rights reserved."; #Windows
TTName 1 1 0 0 "DTL Porta News DOT"; #Macintosh
TTName 1 3 1 0x409 "DTL Porta News DOT"; #Windows
TTName 2 1 0 0 "Regular"; #Macintosh
TTName 2 3 1 0x409 "Regular"; #Windows
TTName 4 1 0 0 "DTL Porta News DOT"; #Macintosh
TTName 4 3 1 0x409 "DTLPortaNewsDOT-Regular"; #Windows
TTName 6 1 0 0 "DTLPortaNewsDOT-Regular"; #Macintosh
TTName 6 3 1 0x409 "DTLPortaNewsDOT-Regular"; #Windows
TTName 7 1 0 0 "DTL Porta is a trademark of the Dutch Type Library."; #Macintosh
TTName 7 3 1 0x409 "DTL Porta is a trademark of the Dutch Type Library."; #Windows
TTName 8 1 0 0 "Dutch Type Library"; #Macintosh
TTName 8 3 1 0x409 "Dutch Type Library"; #Windows
TTName 9 3 1 0x409 "Nikola Djurek"; #Windows
TTName 9 1 0 0 "Nikola Djurek"; #Macintosh
TTName 10 1 0 0 "Standard retail edition"; #Macintosh
TTName 10 3 1 0x409 "Standard retail edition"; #Windows
TTName 11 3 1 0x409 "http://www.dutchtypelibrary.com"; #Windows
TTName 11 1 0 0 "http://www.dutchtypelibrary.com"; #Macintosh
TTName 13 1 0 0 "By downloading, unpacking and/or installing DTL Font Software you acknowledge […]"; #Macintosh
TTName 13 3 1 0x409 "By downloading, unpacking and/or installing DTL Font Software you acknowledge […]"; #Windows
TTName 14 3 1 0x409 "http://www.dutchtypelibrary.nl/PDF/Licenses/DTL_FS_License.pdf"; #Windows
TTName 14 1 0 0 "http://www.dutchtypelibrary.nl/PDF/Licenses/DTL_FS_License.pdf"; #Macintosh
TTName 19 1 0 0 "The quick brown fox jumps over the lazy dog. 1234567890"; #Macintosh
TTName 19 3 1 0x409 "The quick brown fox jumps over the lazy dog. 1234567890"; #Windows
Copyright (c) Dutch Type Library, 2014. All rights reserved.
Notice DTL Porta is a trademark of the Dutch Type Library.
Version 001.00
FamilyName DTL Porta News DOT
FontName DTLPortaNewsDOT-Regular
FullName DTL Porta News DOT Regular
UniqueID -1
Weight Regular

Kent Lew

Adrien — I think we’re on the same page.

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. ;-)

We’re not disagreeing. Just clarifying each other.