Hi. I need some help. Is this a bug of Glyphs.app, or a problem caused by my OS?
I wanted to give my font family a localized Japanese family name and Japanese style names. So I added a custom parameter localizedFamilyName to the font tab, and added localizedStyleName to every instance in the instances tab, then exported them. When I double-clicked the resulting OTFs to install them, the Font Book app only recognizes localized family/style names of an instance whose base name is “Regular”. Other instances behave as if they have a separate (unlocalized) family name, and they don’t seem to bear localized style names.
Plus, if I just set localizedFamilyName and not localizedStyleName, the family name doesn’t have effect to any of the instances.
In the attached Glyphs file, I created a font family whose base family name is “Example”, and added a localizedFamilyName of “Japanese;例”. This family has three instances, whose base style names are “Regular”, “Regular1” and “Regular2” each. Then I gave them localizedStyleName of “Japanese;標準”, “Japanese;標準1” and “Japanese;標準2” respectively.
The attached image shows that the Font Book app only recognizes localized family/style names of “Regular” (標準). Here, Regular is treated as a member of the “例” family, but the other two belong to the “Example” family.
I am using Glyphs ver. 2.5.1 (1141) on OS X 10.11.6 (El Capitan).
I updated Glyphs app to the latest cutting edge version according to your instruction,
restarted my iMac in safe mode to clear font cache by holding down the shift key while booting, then
created a new font with another family name (“ExampleAgain”, localized “例再び”).
But the problem persists.
When I reopen the exported font files with Glyphs, only “Regular” retains the localized family/style names (“例”/“標準”), just like the way Font Book treats them. (By the way, the localized names show up as unlocalized base names, so this seems odd in its own way, but that is not the point.)
When I change the localized name parameters so that they don’t contain Japanese characters (Japanese;TAMESHI rather than Japanese;例), that doesn’t make any difference.
The compressed file “Example.zip” attached to my first post of this thread contains a Glyphs file and three exported OTF files displaying this problem. Are they not enough? I will provide additional files if specified.
And no, I have not examined the exported files with different softwares, except Font Book. I was not aware of them. I will try them later.
Edit: Using FontTableViewer, I noticed something. All OTFs seem to have appropriate entries for localized Japanese names. The difference is that the style “Regular”, which shows localized names as expected, lacks two entries: 16 Win Unicode BMP En and 17 Win Unicode BMP En. On the other hand “Regular1”, which doesn’t behave as having Japanese name, has those two entries, bearing unlocalized names. I don’t exactly know what they mean, but it is puzzling for me that the absence of English names prevents Japanese names from showing up. Moreover they are called Win but they seem to affect how Apple softwares treats them.
If you want to dig deeper in the matter, read the Naming tutorial. IDs 16 & 17 do different things. The name ‘Win’ is just for historical reasons. I’ll have a look at the files.
Thank you for looking into it. So what is wrong here is the behavior of Font Book (and reopening of OTFs with Glyphs)? I will see if I can somehow make the Apple apps recognize the localized names properly.
Hmm, not perfect but looking better. If I install the OTFs using the Font Book GUI anyway (ignoring the odd separation of font family specimen windows), the family is listed split into two just like the specimen (localized “Regular” and unlocalized “Regular1”/“Regular2”). But after I restarted the app, they combined into one localized family. So this is okay in the end.
One problem remaining is that the system-wide font panel treats the family oddly. It lists the family name twice, localized identically. Both contain all the styles, and their style names are properly localized. So this is usable but looks strange, not great for distribution. Clearing font cache by safe-booting did not help.
My guess is that the small discrepancy in their name tables mentioned above (the presence of localized English family name) somehow messes with El Capitan’s font identification process and causes it to fail. Is that unlikely? Can I make the family name information completely identical by using Glyphs? Perhaps the newer version of macOS has already fixed the problem; I cannot test that myself now. If further improvement is not possible, I will be okay with this.
What’s causing the irregularity is the name “Regular”, so I decided to avoid it and instead use “Reg”. This way the behaviour is uniform across the instances. Not a fundamental solution but a good workaround, I think. Thank you.
Hmm, it seems the behaviour has changed on the version 1181, but it is not completely fixed. I tried exporting again from the same Glyphs file attached to the first post. The following is what I observed.
When installing, the Font Book app doesn’t recognize either the localized family name or the localized style names.
When I restart the Font Book app, the font family is split into two: the unlocalized “Example” which contains an unlocalized style “Regular”, and the localized family “例” whose members are localized “標準1” and “標準2”.
When I open the standard font selection palette on TextEdit, the family is unified with the unlocalized name “Example”. It contains all three styles but they are localized differently. “標準1” and “標準2” are localized properly. “Regular” is localized as “レギュラー”, which is a phonetic transcription Apple uses when no appropriate localization is offered by the font, so essentially the localized string is not recognized for this one.
And I tried the same thing on the version 1184, too. The behaviour seems to have been reverted back to how it was on 1141.
