I noticed a problem with glyph names when exporting.
When you define glyphs, that do not have UNI support, and you use custom names, GlyphsApp will export all instances of a type family, but applications such as Illustrator will have issues when trying to change font families/styles/weights.
For example - you design a custom glyph, give it your custom name (without unicode) and export the font. Than you take some text (in Ai for ex.), include your custom glyph in it, and put it into the font you exported from GlyphsApp. This works fine, but when you select the text again and try to change it to a different font family/weight/style, the glyph that has no unicode and has a custom name will not change - this happens when you are trying to switch to a font that has the same glyph with the same def., so it is not a missing glyph issue.
From this I think that this could be some kind of a character recognition issue? The application does not have a definition that would let it know what character it really is …
This would need to be addressed, as there are many situations that custom glyphs are needed.
In my case I renamed the glyphs into the right names and it all worked fine. I had issues with slashed zeroes and some other glyphs.
The only way to reliable access a glyph in a font is by Unicode. This is what is saved in the text field in Illustrator. To acces glyphs without Unicode is by applying a feature to a character with Unicode. If there is no Unicode and no feature pointing to a glyphs some apps can access the glyph by the glyph ID. But since the glyph ID for a certain glyph is different in each font you get a completely different glyph if you change the font. So Illustrator prevents you from changing the font.
One thing is missing from the hole exlenation. The glyph names. They do not play any role in the hole thing.
So you have to either use a standard name with a Unicode or add a feature to access the glyph. What feature depends on the glyph.
And if both possibilities are not working assign a Private Use Area code. Use uni+ a Unicode from the range E000-F000.
Well as I saw glyph names do have a role.
When I had slashed zeroes defined as “zero.slash” and if I manually selected this glyph from the glyphs panel in illustrator I could change the weight.
When I renamed the glyph to “zeroslash” (no period in between) and reexported the fonts this started to work … but still without UNI as slashed zero does not have a UNI definition.
Maybe it could just be a glitch? Or I just don’t understand something
That this did work was pure luck. Call it zero.zero, go to Font Info > Features and click the small circular button in the lower left. This will produce the feature to access the glyph properly.
Unicode is supposed to be a character encoding, not a glyph encoding. Since there is no semantic difference between a zero and a slashed zero, there are no separate codes for them.
I know, I wrote the OT definition myself, no problem.
I also know there is no UNI for the slashed zero.
It’s just weird that I couldn’t change the weight of the character when using the fonts. This was what I tried to discuss here.
Sometimes this could be a problem as somebody would input the character without using OT (directly from the glyphs panel), and maybe change the font weight of the text (which includes the character) with a style definition and not notice the problem.
Changing weights works fine if the default zero is encoded normally and all the others have their appropriate OT feature code, which can be generated automatically if the proper naming scheme is used, e.g. "zero.zero". For that to take effect, you may need to force the automatic feature code to update, by clicking the circled arrow button in File > Font Info > Features.
