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.
Comments
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?
With all the default values selected except for the main General Identification page being:
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.
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.
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
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.
Robofont:
which isn't as clean as say in FontLab where it would be
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?)
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.
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) 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.
StartFontMetricsTTName 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
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.