I’ve been reading up on and troubleshooting a family of 30 fonts where I’ve had problems with style-linking on OSX, which seems to be related to menu order. I’ve spent this afternoon digging into the issue and I think I have isolated the problem. If possible I’d like to email files over to someone at Glyphs to see if they can verify what I’ve found. Or perhaps it is a known issue. I’ve tested on two different Macs, clearing the font cache etc.
I’ve have two stripped down Glyphs files, containing two masters and three instances. If you use MergeGlyphs to compare the files, the only difference is the Style Name in the Instances panel. One file uses standard names (Light, Regular, Light Italic) and the other one uses custom names (Light Extrawide, Regular Extrawide, Light Italic Extrawide). Note that I’ve placed the custom text after the weight names, so that alphabetical order isn’t affected – I tested this and it didn’t make a difference.
To recreate:
Open the two files in Glyphs 2.6.1 (I can share these via email)
Export both as OTF (Remove Overlap, Autohint are the settings I used)
You should have 6 OTF files.
Select all 6 and drag into Font Book.
Locate the fonts in Font Book and click the arrow to see the individual fonts.
Note that the display order is different between the two fonts.
The reason that Font Book’s menu order matters, is that in Pages it is related to the default weight that is used when you select a font in the font menu. The Menu order is the same for Pages and Text Edit as it is for Font Book.
Open Text Edit.
Choosing both fonts results in the Light version being selected.
Open Pages.
Choosing the Regular Named font (correctly) selects the Regular version of the font. Choosing the Custom Named font selects the Light variation of the font. The reason for this seems to be that Pages is choosing whichever font appears first in the menu as the base version of the font.
I can send the Glyphs files over by email. Thanks.
The thing is that macOS tries to parse and interpret the style names. It even attempts to translate them if you have the system language set to something other than English.
The Mac style name order is very buggy, and is something that changes frequently between system updates. That may be a reason why Apple also refuses to publish specs on how to control menu order. I have asked multiple times.
In short, do not rely on a certain menu order. It may change in the next system update.
It even tries to translate? Urgh… Nothing worse than a system that tries to be smart and fails.
I’ve got a family of 30 fonts that can be split into 5 sub families but this one file refuses to work, despite the fact that they all use the same naming (Regular, Italic, Bold, Bold, Bold Italic). Are you sure this is an OSX issue?
The fonts generate correctly, so nothing fails. I have a family of 30 fonts with inconsistent menu order. As part of my troubleshooting, I have stripped it down to 3 fonts and can demonstrate how deleting a single character in one Style Name changes the menu order. I’ve purposefully deleted a character at the end of the name, so alphabetical order isn’t changed. Also neither Style Name is a standard name, like Bold or Regular, which OSX might have its own ideas about.
I can imagine it has the capability to screw a lot of things up, due to trying to be ‘smart’. But would it really change menu order based on the difference between “Extra” and “Extr”?
I’ve been using FontLab 4.5 and opentype.js to look at the Naming table.
One thing that comes up is that one of the two instances in the Glyphs file is generating an entry for compatibleFullName. This isn’t something that I have added as a Custom Parameter, and nothing appears in the Glyphs instance page.
Here is the Glyphs file. It contains 2 Masters and 2 Instances. Exporting as OTF creates two OTF files, one with NID18 compatibleFullName and one without. The Glyphs file shows no Custom Parameters at all, so compatibleFullName should not be generated.
