Is there an easy to implement way of exporting fonts (OTF) that have fully AGL-compatible glyph names (or, at least “as compatible as possible”, of course)?
Example: I have a glyph named twosuperior with Unicode 00B2, which gets exported as uni00B2. This creates problems in use cases that rely on AGL naming. Can this be changed easily on export? Or, am I missing something and there is a benefit in naming it uni00B2?
Change the production name to twosuperior with Edit > Info for Selection:
Checking back with the Adobe Glyph List, I believe this is an error in the default GlyphData.xml. Because for the production names, we fall back to the AGL wherever possible. I vaguely remember we made a change once for a very specific reason, but I don’t think this was it. Need to check.
There is a difference bewteen AGL and AGLFN (new fonts). Only the later is recommend to use.
Ah, Georg beat me to it. Yes, it is Adobe Glyph List For New Fonts does not list a special name for superior two:
Which exact compatibility problem did you run into?
Well, Adobe recommends to use only the latter. I want my fonts to work in as many contexts as possible.
Can I ask again, what is the benefit of using uni00B2 instead of twosuperior?
Thanks, Rainer. I was secretly hoping there would be an easier solution that doesn’t require me to check all glyphs individually, identify the AGL-incompatible ones, then set up the correction for each of them manually, and eventually go through this again for new projects I work on.
[I know this can be scripted. Working on something right now but it still feels unelegant.]
I’d ask in reverse. The official recommendation is the former. I would only pick the latter if there is a good reason to do so, like a client who needs to support old software. That is why I asked which specific issue you ran into.
My expectation is that you are more likely to run into a compatibility issue when you’re deviating from AGLFN. But really it should not matter at all.
The only thing I can remember (but I would test it) is that macOS 10.4 Tiger would try to access glyphs by their names, an obvious bug that was fixed in 10.5 for good. IIRC (ugh it has been 20 years) it would accept both uniXXXX and nice name schemes. AGLFN was first released in 2003 and predates 10.4 Tiger (the version on GitHub has a version history), so I assume it was supported because Adobe had implemented AGLFN already in their fonts.
What setup would even care about the specific AGL names and doesn’t know who to interpret uni-names?
My customer is using a service that fails with glyphs that don’t adhere to the AGL. It’s a real-world scenario from a large company. I am not much interested in who’s to blame here but as a matter of fact, the font would work properly in that context if it had AGL-compatible names. “Tell them to get up to date” is one possible reaction, simply using AGL names is the other possibility. I’d prefer the latter. Customer is king, and they are not even to blame directly.
Can you explain?
I think that was a typo?
I am not asking to deviate from AGLFN, I am asking to stick to AGL.
Just had a look at a number of Adobe fonts (.otf) I could find, and none of them uses uni00B2. Including families that were not released before the 2010s, such as Source Sans, Source Serif and Trajan 3.
Can I ask again, what is the benefit of using uni00B2 instead of twosuperior?
It’s Adobe’s recommendation, so adopting it is a benefit in terms of following recommendations. You found a situation where the old list works best and you can adjust your project to match the old list. If there are more reports in this regard, it might be interesting investing whether adopting the old list by default would be better or if that causes other unforeseen issues with different software that expects the new list.
Adobe is very clear that fonts are not invalid if they are not using the uni prefix. And even Adobe is deviating from the recommendation. Why is this recommendation so important then, more important than getting stuff to work? Strange but seems like I won’t be able to convince the team.
Your report is a valuable input, but it’s just not enough information to make informed changes. Maybe when you changed the glyph names you also changed something else and that make the font work with the client’s software. Or the software does not expect the old AGL and instead another naming scheme that happens to overlap with the old AGL in some cases. Or there might be another bit that could be flipped to make the software work with the new list. Without more details it’s not clear whether we should change the default production names, or offer a setting, or make a script, or change the compiler, or some other action. There is not a single thing yet to be convinced about.
Is there any chance to know more about the clients software and why it relies on the names?
Just had a look myself. It is called two.u in Source Sans, which is AGLFN compliant (yes, it does not need to be uni00B2, any OT variant of another glyph can use the original glyph’s name with a suffix), and contradicts AGL (where there is an established 1:1 relation between name and Unicode value):
Why is this recommendation so important then, more important than getting stuff to work? Strange but seems like I won’t be able to convince the team.
Convince the team? Why? If it works for that specific use case (circumventing an apparent bug in an unnamed third-party software), nobody is stopping you from changing the production names. It is easy to script, just set GSGlyph.productionName. What exactly is the issue?
I just have not read a convincing argument for making an apparently exceptional use case the default for everyone. It is like saying to not use GPOS because Word on Windows 98 does not support it. I can show you how to switch to an old-style kern table alright, and it is OK to support that specific use case if the client must use that software, but I would not recommend it as a default for modern OpenType production in general.
