On export, in the font binaries, these all have the name “.notdef” - should they be named like uni1f150 and so on by Glyphs convention?
just confirmed this is for variable fonts only. it’s happening to all glyphs with more than 4 characters in the code point like 1f150.
It looks like for static fonts it uses “u” instead of “uni” eg u1f150 so maybe thats the right convention?
According to Adobe Glyph List Specification, the uni prefix is used only for 4-digit codepoints (or sequences of such). Anything with 5 or 6 digits must use the u prefix.
1 Like
Thanks for clarifying, Bob!
Just to follow up on this, it’s a lot of valid codepoints that are being renamed .notdef in variable fonts, not just black circles or those with 5 characters. Seems fine with static fonts.
For example the glyph ya_acutecomb-cy has the correct production name of uni044F0301 but is ending up .notdef in the generated VF. In the source file I cannot change the Unicode tag to 044F0301 because it only accepts input of 4-5 characters.
What do you mean by that?
This glyph should not be encoded at all. It would be accessed by a ccmp feature. You type ya-cy+acutecomb and the feature is substituting this to the desired glyph:
sub ya-cy acutecomb by ya_acutecomb-cy;
ah, I am using the wrong terminology - not the encoding, just the name of the glyph. the issue was that many glyphs were being renamed to .notdef and my understanding is that you should only use a glyph name once per font. but it seems as though this was fixed in 3099? I was behind - thank you!
Actually, glyph names shouldn’t matter at all in TTFs. Only the GIDs are used for identifying glyphs. There are some unfortunate (and outdated) PDF implementations that actually do read out and process the glyph names though.
1 Like
Where do you see the renamed glyph?
I am no longer seeing them, I think this must have been a bug in 3097 or 3098? They appeared in the generated VF binaries
This looks like a bug again in 3108. glyph names for .blackCircled glyphs are all .notdef
In which app are you checking for the glyph names of the exported OT font? And how is it an issue?
I am looking on FontGauntlet; maybe that is where the issue is? What is the best way to check what works, FontGoggles?
I want to call things by glyph name in other scripts and it will add some complexity to look up by unicode rather than by name
Can you send me the .glyphs and the .otf file?
Generally a bad idea for a compiled OT font.
Glyphs are made for being accessed through Unicode and OT features. Beyond that, you can use the unique GID (e.g. for displaying a complete grid of all glyphs).
If you really want to verify glyph names, probably best to take a look with ttx or OTM. But again, in compiled fonts, glyph names are redundant.
thank you, that’s helpful; I overcompilcated a script trying to rely on names. unicode will be more straight-forward.
I can see now that this is an issue I’m having with web technologies and not the font binaries themselves. apologies for bumping the thread!
1 Like