[makeotfexe] nameIDs 1, 4, 16 without FontMenuNameDB?

[frankrolf]

In the planning phase of a new family, I have been building all instances without creating a FontMenuNameDB file, and I am running into the following problem:

If a FontMenuNameDB file is not used, the OTF name table for IDs 1, 4, 16 looks like this:

nameID1 FamilyName
nameID4 FamilyName
nameID16 <None>

If a FontMenuNameDB file is present, this is the result:

nameID1 FamilyName StyleName
nameID4 FamilyName StyleName
nameID16 FamilyName

My questions:

• is it possible to specify name IDs 1 or 4 anywhere in the UFO file?
  (my research indicates it might not be)
• is the above result expected?
  Since a PS name needs to be present in order to build with makeotf, it would be possible to extract a “correct” (not necessarily styie-linked) subfamily name.
• the OT spec at https://docs.microsoft.com/en-us/typography/opentype/spec/name indicates the following about nameID 4:

The full font name is generally a combination of name IDs 1 and 2, or of name IDs 16 and 17, or a similar human-readable variant.

Since the build result for nameID 4 does not include the style name, I assume it to be incorrect.

• why is nameID 16 not written when building without FontMenuNameDB? nameID 17 exists in the final fonts.

[frankrolf]

Attached is a test case with a simple UFO file, built once with, once without FontMenuNameDB.
As expected, the differences are exactly as above:

In the OTF built without FontMenuNameDB, the nameIDs look as follows:

nameID1 Family Name
nameID4 Family Name
nameID16 <None>

In the OTF built with FontMenuNameDB, the nameIDs look as follows:

nameID1 Family Name Style Name
nameID4 Family Name Style Name
nameID16 Family Name

I understand it’s difficult to predict style linking, which is why nameID1 may resort to the actual family name only (instead of subfamily name), but some of the other differences leave me confused. A TTX dump of the name tables is provided.

FontMenuNameDB test case.zip

[frankrolf]

Coming back to this, after running into the problem again today.
To summarize:
Currently, it is only possible to write nameID 16 by using the FontMenuNameDB’s l= field:

For example,

[Filicudi-Solid]
    f=Filicudi
    s=Solid
    l=Filicudi Solid

will write “Filicudi” for nameID 16, “Solid” for nameID 17.

This example

[Filicudi-Solid]
    f=Filicudi
    s=Solid

will result in no nameID 16, and “Solid” for nameID 17.

---

Interesting observation today – if I add nameID 16 to the name table manually:

table name {
	nameid 16 "Filicudi";
} name;

I will get a warning:

WARNING: [line    16 char  13] [name] Overwriting existing nameid 16 Filicudi with Filicudi

but still no nameID 16 in the final fonts.