Name table of VF are built in a confusing way

rosalie · February 5, 2024, 4:10pm

We would expect/understand from the UI:

Name = style name = ID17
Localized family name = family name = ID16

But even when specifying “Regular” as a style name, the default master is used to build the name table. For example, if the origin is “Book” then name ID17 = Book. I personally think it makes sense to have the style name reflecting the font origin. But why is that field even there then?

So instead of having “Regular” in the VF name field, I put the font origin (let’s say “Book”) for consistency. But now Book is appended to the family name in the entire name table, creating a complete mess, especially in the Italic:

<name>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Name VF Book
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Italic
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
      1.101;205;NameVFBookItalic-BookItalic
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
      Name VF Book Italic
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-BookItalic
    </namerecord>
    <namerecord nameID="16" platformID="3" platEncID="1" langID="0x409">
      Name VF
    </namerecord>
    <namerecord nameID="17" platformID="3" platEncID="1" langID="0x409">
      Book Italic
    </namerecord>
    <namerecord nameID="25" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic
    </namerecord>
    <namerecord nameID="256" platformID="3" platEncID="1" langID="0x409">
      Weight
    </namerecord>
    <namerecord nameID="257" platformID="3" platEncID="1" langID="0x409">
      Thin Italic
    </namerecord>
    <namerecord nameID="258" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-ThinItalic
    </namerecord>
    <namerecord nameID="259" platformID="3" platEncID="1" langID="0x409">
      ExtraLight Italic
    </namerecord>
    <namerecord nameID="260" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-ExtraLightItalic
    </namerecord>
    <namerecord nameID="261" platformID="3" platEncID="1" langID="0x409">
      Light Italic
    </namerecord>
    <namerecord nameID="262" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-LightItalic
    </namerecord>
    <namerecord nameID="263" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-Italic
    </namerecord>
    <namerecord nameID="264" platformID="3" platEncID="1" langID="0x409">
      Medium Italic
    </namerecord>
    <namerecord nameID="265" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-MediumItalic
    </namerecord>
    <namerecord nameID="266" platformID="3" platEncID="1" langID="0x409">
      SemiBold Italic
    </namerecord>
    <namerecord nameID="267" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-SemiBoldItalic
    </namerecord>
    <namerecord nameID="268" platformID="3" platEncID="1" langID="0x409">
      Bold Italic
    </namerecord>
    <namerecord nameID="269" platformID="3" platEncID="1" langID="0x409">
      NameVFBookItalic-BoldItalic
    </namerecord>
    <namerecord nameID="270" platformID="3" platEncID="1" langID="0x409">
      Thin
    </namerecord>
    <namerecord nameID="271" platformID="3" platEncID="1" langID="0x409">
      ExtraLight
    </namerecord>
    <namerecord nameID="272" platformID="3" platEncID="1" langID="0x409">
      Light
    </namerecord>
    <namerecord nameID="273" platformID="3" platEncID="1" langID="0x409">
      Book
    </namerecord>
    <namerecord nameID="274" platformID="3" platEncID="1" langID="0x409">
      Medium
    </namerecord>
    <namerecord nameID="275" platformID="3" platEncID="1" langID="0x409">
      SemiBold
    </namerecord>
    <namerecord nameID="276" platformID="3" platEncID="1" langID="0x409">
      Bold
    </namerecord>
  </name>

When “Regular” is used, I guess it is elided and so it doesn’t create such a mess.

So I guess my main question is:
Is the VF name field standing for the postscript VF name ID25, the style name, or a specific suffix to append to the family name?

If the name field is for nameID25: it shouldn’t be used to build the other name IDs, especially for the non-postscript names.
If this field is for the VF style name: all PS names are usually limited in the number of characters (even for the PS names linked to the FVAR table), so this duplication is annoying.

This is what I would expect for the variable font name table:

Input in the UI:

Name = Style Name (origin or Regular or else to override the default style name)
Localized Family Name = Family Name

Output in the name table:

ID 1 = Family Name + (non-RIBBI) Style Name
ID 2 = RIBBI Style Name
ID 3 = version;vendorID;FamilyNameStyleName
ID 4 = Family Name Style Name
ID 6 = FamilyName-StyleName
ID 16 = Family Name
ID 17 = Style Name
ID 25 = Family Name (for romain) or Family Name Italic (for italic)
ID 2** (FVAR instance's style name) = Instance Style Name
ID 2** (FVAR instance's postscript name) = nameID25-InstanceStyleName

Following the OT spec, the name ID25 should be used to build the FVAR instance’s postscript name only (name IDs 2**).
So there is no incentive for the ID25 to influence non-postscript names such as ID4 and ID3, they should be built like a normal static font would be.
ID25 shouldn’t be influenced by the VF name field in the UI either to avoid conflicts or confusion is the name table. The “name table entry” custom parameter could be used to override it (to abbreviate it for eg.).
To avoid bugs in Indesign: as default it should be the Family Name for upright styles, and Family Name Italic should be appended to that name for the italic style.

What do you think?

GeorgSeifert · February 5, 2024, 7:18pm

The VF name field basically only has two useful values. Either “Regular” or “Italic” (for a font that only contains italic shapes).

The default nameID 1, 2, 16 and 17 should always reflect the appearance of the Origin. So that if you would remove all variable tables, you get a valid font. So almost all name entries need to be taken form the static instance that sits on the same spot as the origin master. Use the Family name in the variable instance settings only to make it different from the static instances.

rosalie · February 6, 2024, 8:03am

Dear Georg, I gonna copy-paste what I wrote because it seems that you explained to me something I already know without answering my question nor taking any of my remarks into consideration:

I personally think it makes sense to have the style name reflecting the font origin. But why is that field even there then?

You confirmed that “The VF name field basically only has two useful values. Either Regular or Italic.”, making the VF name field unrelevant — a “is italic” flag to enable would be a stronger, less confusing statement for the user.

But you didn’t really answer:

Is the VF name field standing for the postscript VF name ID25, the style name, or a specific suffix to append to the family name?

Meaning: where does that field go and how does it influence the other name IDs? The different tests I made don’t give a consistent result.

Now, can you please look at the name table of the italic font, because even following your recommendation of using only Italic, this is what we get:

ID3: 1.000;VendorID;MyfontnameVFItalic-BookItalic
ID6: MyfontnameVFItalic-BookItalic

As I noted earlier:

all PS names are usually limited in the number of characters (even for the PS names linked to the FVAR table), so this duplication is annoying.

And name ID 3 is built from the ID6 so the duplication is spreading.

Following the spec, the name ID25 should be used to abbreviate the FVAR instance’s postscript names when they are too long. But also thanks to Adobe, we are kinda force to append “Italic” to it for italic VF to avoid bugs.

So, the file shows right now:
ID 25 : MyfontnameVFItalic

And so all the postscript ID2**, are annoyingly but also “correctly” built this way:

MyfontnameVFItalic-ExtraLightItalic
MyfontnameVFItalic-LightItalic
MyfontnameVFItalic-Italic
etc

But as I noted:

The “name table entry” custom parameter could be used to override it (to abbreviate it for eg.).

I just tried to add a custom parameter to have a shorter ID25 in hope that it would abbreviate it, and it didn’t change the ID25 nor any of the ID2**.

I tried 25; FonNa Italic, (and also 25 3; FonNa Italic and 25 3 1 0x409; FonNa Italic). Did I set the custom parameter wrong?

mekkablue · February 6, 2024, 10:05am

A checkbox would make the UI incompatible with the underlying data structure. Plus, there’s at least one scenario where you may want an unelidable name, namely a font without a Regular style.

A combo box may be a better solution.

Will try and answer the other points later.

mekkablue · February 6, 2024, 10:13am

ID 25 cannot have spaces since it is supposed to become part of the family font name.

The double italics are a PITA, I know. Technically, the fvar.postscriptName entries just have to be unique, so it’s not illegal to have double italics. Plus, they are never visible to the user, so it is probably not a biggie.

Since ID 25 needs to be unique (and thus distinguishable from the Roman), the Italic part needs to stay in ID 25, and be removed from the part after the dash in the fvar.postscriptName entries. This is hard to reliably derive with the current underlying data structure.

Currently I postprocess the italic fvar.postscriptName entries with the Fix Italic script in Script > mekkablue > Post Production. In the same folder, there is also a Terminal command that does the same thing (for post processing outside of Glyphs).

rosalie · February 6, 2024, 10:32am

Yes sorry, I got that wrong in the message. The point remains the same that I can’t override it though.

We thought so too. But there was a lot of testing at GF with the Playwright project, and evidence were found that long FVAR instance names was creating issues with complex shaping in text editors (I don’t know where these test are at now). On my own testing, I suspect that it might be the reason why some printers can only print some instances and not other with VF fonts. In any case, the user might want more control over these name IDs.

I didn’t know, thank you so much I gonna try this.

EDIT: Works great! And you also made one to fix the italic STAT table, which I had no idea how to approach this problem in a very simple way <3

mekkablue · February 6, 2024, 1:20pm

One thing I forgot to mention: the latest builds of 3.2 offer a variablePostscriptFontName entry in the instances of Font Info > Exports. It will appear as ‘Variable Font Name’. So you can override the calculation of fvar.postscriptName.

This is big news. Can you give more details please? We did extensive testing and found no issues as long as you stay within the 127-character limit prescribed by Adobe’s TechNote.

Where do fvar.postscriptName entries make a difference besides PDFs, Adobe apps and PS-based environments (like Apple’s PS-to-PDF conversion)?

rosalie · February 6, 2024, 3:23pm

Ah I think I am talking of several problems to show that there might be more complicated stuff at stake, and so more reasons for more user control.

After re-reading the github issues, I remember they didn’t test the fvar instances’ postscript name (they were not generated with gftools builder) but the combined length of family name + fvar style name for each instance, which led to revise this check:

https://font-bakery.readthedocs.io/en/stable/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/family_and_style_max_length

Discussion about this happen in this issue from that comment: com.google.fonts/check/name/family_and_style_max_length is overly-strict · Issue #2179 · fonttools/fontbakery · GitHub

So indeed the shaping issue is probably not linked to the problem I am exposing now. But before I left for my sabbatical, it was question to re-introduce the fvar instances’ postscript name to see if they could somehow fix the problem. All of this is quite mysterious, but indeed for the fvar postscript names the official limit is 127, so it might not play a role at all. So I agree with you, the double italic in the fvar poscript names is probably not a biggie (until proven otherwise).

My priorities are: a good nameID6, a clean name table, and the possiblity to override the fvar postcript names. Thanks to the scripts you provided and this new custom entry in version 3.2, this is now the case, so I am happy

mekkablue · February 6, 2024, 3:37pm

Phew