How to set compatible name ID1 and ID2?

Glyphs 2.6.6 (1352)

I am helping a colleague troubleshoot problems with font style mapping in Powerpoint. The issue is that styled text in Powerpoint are falling back to other styles of the family. I have examined the fonts output from Glyphs, and my thinking is that the problem is due to the Mac platform name ID1 and ID2 setting, which are contrary to the OT name table spec recommendation that these IDs should be used for four-style ‘RIBBI’ families on all platforms for greatest compatibility. There seems to be an assumption in how Glyphs writes the name table that the platform IDs actually correspond reliably to what apps on particular platforms use. This is not a safe assumption, especially in the case of ported apps.

So I want to export fonts in which either

a) the content of name table platform entries is the same for both Mac and Microsoft, i.e. for both to use ID1 and ID2 to identify four-style families and subfamilies; or

b) the name table contains entries only one platform (Microsoft), since these are all exporting correctly with my current Instances settings. [A lot of modern build processes omit the Mac platform name entries altogether: Mac OS can parse the Microsoft platform IDs perfectly well.]

How can I achieve either of these solutions in Glyphs? I am guessing there may be some magic combination of Instance name parameters to achieve (1) but I have not found it yet. What I have managed to do at the moment, bizarrely, is end up with some double entries of style as part of the family name, even though this doesn’t reflect what is in the Instance parameters.

This is a redacted set of the Instance name parameters for one instance of the font family:

[The compatibleFullName entry was inherited from someone who worked on the source previously; I doubt it is necessary, but also think it should not be messing anything up.]

What these settings output to the name table is this:

Note the weird duplication of Thin Thin in the Microsoft platform ID1 and elsewhere.

You can use the Name Table Entry custom parameter. The content uses this format: <nameID> <platformID> <encID> <langID>; <nameString> (You can omit all but the first ID.)

So in your case, you can use:

Name Table Entry = 1 1; XXX Sans Condensed Thin
Name Table Entry = 2 1; Regular

And some history:

The way Glyphs 2 writes the name table is 10 years old. Back then there were several apps (e.g. Quark and FontExplorerX) that would use the Mac name ID1/2 for the UI and thous those needed to match ID16/17. And I don’t remember if the spec said anything about the platform strings need to match back then. And, if I remember correctly, makeOTF would write it that way, too.
The behavior is changed in Glyphs 3 to match the spec.

Thanks, Georg! That is super helpful.

If I specify custom Name Table Entry parameters for the Mac platform that differ from what Glyphs 2 would auto-generate, will IDs 16 and 17 be automatically added for that platform, or should I explicitly define those too?

Those Name Table Entry entries do only this one thing. Some to the named parameters might have side effects for other names.

Have confirmed that explicitly setting

Name Table Entry = 1 1; XXX Sans Condensed Thin
Name Table Entry = 2 1; Regular

does automatically add appropriate ID 16 and 17 entries.

Now I just need to figure out why two instances are suddenly throwing up PS error messages and not exporting, even though I have not touched anything except name parameters.

Hmm. And ID 3, ID 6, and ID 18 are now getting incorrectly written and are missing the width reference part of the name:

Such a strange guessing game.

Well, that issue just disappeared as inexplicably as it appeared, so, um, Yay! :grin:


I figured I could probably fix the ID 18 names by entering explicit compatibleFullName parameters for each instance. And in a sense, I succeeded, because the effect of this is that no ID 18 entries are now being written to the fonts. Which is fine by me.

I was hoping I might be able to fix the buggy ID 6 PostScript names with an explicit Name Table Entry like this:

but that has no effect. So now stuck with incorrect ID 6 names (also, of course, in CFF top dict).

MakeOTF doesn’t allow setting nameID 6 manually:

makeotfGlyphs [WARNING] <NewFont-Black> name id 6 cannot be set from the feature file. ignoring record [features.fea 30]

Hmm. So the issue here seems to be that my colleague is using a single .glyphs source but wants to output three separate (ID16+17) families from it: he wants the regular width, narrow width, and condensed width to function as separate families. I am able to add parameters to the 18 instances (6 in each family) that now correctly set the family names for both ID16+17 and ID1+2. But the ID6 Postscript name seems to be picking up the top level ‘Family Name’ in the Font section of the Glyphs metadata, rather than the ID16 family name in the Instance parameters.


I split the three instance families into separate Glyphs sources, and changed the family name entry in the Font info panel. This name was then picked up for the ID6 Postscript name field in the fonts.

I’m still not 100% what you trying to do but that seems close?

This is how I set it up:

We are trying to define the following, and trying to pick the right Glyphs info to get the right names in the right parts of the name table.

  1. The 4-style compatible family (ID1, the same in both Mac and Windows platform), e.g. ‘Some Name Condensed Black’ (styles ID2 Regular and Italic).

  2. The preferred, typographic family (ID16), e.g. ‘Some Name Condensed’ (styles ID17 including Black and Black Italic, and a bunch of others).

There are three distinct preferred, typographic families to be output from the one Glyphs source.

I am able to get the ID1 ID2 ID16 and ID17 working correctly.

The problem we are hitting is that the ID6 Postscript name (and hence ID3 unique identifier) are being written using the family name setting in the Font info panel. If I add a familyName parameter to the Instances, will this override the one in the Font info panel for purposes of the left-side of the ID6 name? Will it do so without interfering with the other name entries that are working correctly?

Confirmed fix: adding explicit familyName in the Instances parameters, alongside previous changes, gets everything working as intended:

Thanks, Georg!

1 Like

I have the sense that this could be avoided if, by default, the ID6 name were always based on the ID16 and ID17 names if present in the Instance parametets.

Thanks for the recommendation. I’ll have a look.