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.

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

  • 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)


  • You don't need to specify OpenType/Postscript names, they'll be inferred at compile-time.
  • Kent LewKent Lew Posts: 486
    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 JarboeMichael Jarboe Posts: 198
    edited October 2015
    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.
  • 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 LewKent Lew Posts: 486
    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.

  • Amazing Kent! I was really banging my head against the wall there and thinking I was losing my marbles.
  • 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?)

  • That's makeotf, not just robofont.
  • Kent LewKent Lew Posts: 486
    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.



  • 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.
  • But does it have overrides? That's the most important thing.
  • 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).
  • 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 LewKent Lew Posts: 486
    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.
Sign In or Register to comment.