Glyph names for new fonts
Igor Freiberger
Posts: 273
Which is the best practice for glyph names in a new font?
I was following the Adobe Glyph List (AGL). When a glyph does not have a name there, it should be named as uniXXXX, where XXXX is the Unicode identification. Variations from the main glyph receives suffixes like .sc, .pc, .hs, etc.
But now I noticed that Adobe Glyph List for New Fonts (AGLNF) brings a quite smaller list of names and, as its text says, this is the recommended option for a new font. Although the text in GitHub says that AGLNF is the AGL without PUA entries, it also does not have the "commaaccent" itens besides several other characters like "Dafrican".
The specification placed in GitHub directory says to apply AGL when mapping a font, but I believe this is a instruction for already existing fonts.
So, it seems that a character previously named in AGL (like Dafrican) but with no entry in AGLNF should receive a uniXXXX name. Is this the best option? Or should we begin to use uniXXXX for all glyphs and drop those descriptive names as they could be also removed from AGLNF in a near future?
Side note: In FontLab 5.x, names following AGL are identified as glyphs with an Unicode available and the application can automatically fill it. But if I use the uniXXXX schema, FontLab does not points to a Unicode. Probably, this small limitation is due to aging of FL.
There is a previous discussion similar here in TD, but the best option between AGLFN x AGL x uniXXXX was not directly answered – at least for my understanding.
[Edited to add URLs.]
I was following the Adobe Glyph List (AGL). When a glyph does not have a name there, it should be named as uniXXXX, where XXXX is the Unicode identification. Variations from the main glyph receives suffixes like .sc, .pc, .hs, etc.
But now I noticed that Adobe Glyph List for New Fonts (AGLNF) brings a quite smaller list of names and, as its text says, this is the recommended option for a new font. Although the text in GitHub says that AGLNF is the AGL without PUA entries, it also does not have the "commaaccent" itens besides several other characters like "Dafrican".
The specification placed in GitHub directory says to apply AGL when mapping a font, but I believe this is a instruction for already existing fonts.
So, it seems that a character previously named in AGL (like Dafrican) but with no entry in AGLNF should receive a uniXXXX name. Is this the best option? Or should we begin to use uniXXXX for all glyphs and drop those descriptive names as they could be also removed from AGLNF in a near future?
Side note: In FontLab 5.x, names following AGL are identified as glyphs with an Unicode available and the application can automatically fill it. But if I use the uniXXXX schema, FontLab does not points to a Unicode. Probably, this small limitation is due to aging of FL.
There is a previous discussion similar here in TD, but the best option between AGLFN x AGL x uniXXXX was not directly answered – at least for my understanding.
[Edited to add URLs.]
Tagged:
0
Comments
-
Personally, I prefer to generate fonts with no glyph names at all (since the way I build my fonts makes glyph name → to Unicode value mapping rather useless).
But to answer your question, AGL is the old glyph names list from the times Adobe was trying to name all glyphs, and font consumers e.g. PDF readers, are encouraged to support it so that mapping keeps working for old fonts. AGLNF is a cleaned up list with PUA and other controversial names removed, new fonts are encouraged to use it. But if one wants simplicity, then uniXXXX (and uXXXXXX for higher Unicode values) should work for any glyph, whether it has an entry in AGL[NF] or not.
Bot AGL and AGLNF are frozen AFAIK, and no entries will be added or deleted any more.
P.S. If one wants to use friendly names during development, most font editor now support this and allow renaming glyph to “production names” during font generation.
3 -
There is another big difference between AGL and AGLNF: certain names in AGL map to the same unicode value. Whereas in AGLNF each name maps to a unique unicode value only.
The AGL was compiled by Adobe to have a scheme for automatically assigning unicode values to glyph names in a time when they were converting their (huge) library of legacy PostScript fonts to OpenType format. These PS fonts did not contain any unicode mapping at all, and could have different naming schemes.
The AGLFN was subsequently compiled to have one preferred way of naming glyphs in new fonts. According to this scheme every glyph that has a unicode value and is not listed in the AGLFN should have a uniXXXX name.
The AGLFN is used by many font editors as the default naming scheme. Since it deals mainly with the Latin script, it means that these glyphs have relatively user-friendly names (such as "Adieresis") whereas the majority of non-Latin glyphs are stuck with generic uniXXXX names.
That is why certain font editors offer two naming schemes now: "friendly names" versus "production names". Earlier this year a number of people contributed to a new initiative to make an open standard for friendly names. It was presented as "gnufl" at Typo Labs in Berlin. More details here: https://github.com/LettError/glyphNameFormatter/1 -
“ The AGL was compiled by Adobe to have a scheme for automatically assigning unicode values to glyph names in a time when they were converting their (huge) library of legacy PostScript fonts to OpenType format.”
That bit is not correct. The AGL was compiled by Adobe as a record of glyph names (and correct corresponding Unicode values) that had been used by a range of vendors in fonts over the years. We are talking especially 80s and early to mid-90s.
Adobe’s own OpenType fonts followed AGLFN from the beginning.
FontLab VI follows a dual-name scheme like you describe, where it can display and use friendly names but generates fonts using external production names.2 -
That bit is not correct. The AGL was compiled by Adobe as a record of glyph names (and correct corresponding Unicode values) that had been used by a range of vendors in fonts over the years. We are talking especially 80s and early to mid-90s.Adobe’s own OpenType fonts followed AGLFN from the beginning.Are you sure about that? Because I still have OpenType fonts here from around 2003 (Adobe Garamond, Adobe Jenson) that contain glyphs such as /Asmall, /zerooldstyle, etc. mapped to PUA values...0
-
Ouch, darn, you're right. AGLFN was only published in January 2003, and I would not assume all fonts in development at that time would have switched over instantly. My recollection was wrong.
Also, Adobe had just finished converting their entire library at that point. I don't know that said conversion used the new schema. (It wasn't published yet, but could have been used internally.)
I'm pretty sure that all such "old" fonts have gone through subsequent revisions, and likely seen glyph name updates.1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports