"Omega" vs. "uni03A9" glyph naming controversy

[Adam Twardoch (FontLab)]

There is a controversy in Unicode vs. glyphname issues which we would like to get an opinion of the font developers:

1. Apple defines the decimal 189 entry in the codepage MacOS Roman [1] as follows: "0xBD 0x03A9 # GREEK CAPITAL LETTER OMEGA", so it references the Greek Omega sign rather than the Ohm sign in the codepage (which is not really what they actually meant).

2. Adobe in their Glyph List for New Fonts (AGLFN) [2] recommends that the glyphname "Omega" maps to Unicode: "2126;Omega;OHM SIGN" -- which means that the Greek Omega sign should have the glyph name "uni03A9".

3. Most older Type 1 fonts used the glyph name "Omega" for the Ohm sign, and Adobe Type Manager on Mac OS 9 did indeed map the the glyph named "Omega" to MacOS Roman decimal position 189.

4. According to the current normative documents ([1] and [2]), if a Type 1 font includes the glyph named "Omega", it should these days be mapped to Unicode U+2126 which is not part of the current MacOS Roman codepage as defined by Apple. Apple expects the Unicode U+03A9 to be there in order for it to map to decimal 189 in MacOS Roman. And according to Adobe, such glyph should be named "uni03A9". Yet a glyph "uni03A9" on older codepage-based Mac software will not be recognized as mapping to decimal 189.

5. So the problem is due to a mismatch between older and newer notions both by Adobe and Apple on how to glyph names map to Unicodes and how the glyph names or Unicodes map to codepage decimal slots. I'm not sure how this can be resolved reasonably.

6. The MacOS Roman *encoding* used in FOG and in FontLab Studio [3], which uses glyphnames, has the mapping "Omega 189" because of the legacy reasons outlined in item 4 above. This is, from today's perspective, incorrect -- the mapping should be "uni03A9 189".

7. The FontLab Studio codepage [4] is based on Unicode and includes the contemporary mapping i.e. "0xBD 0x03A9 % GREEK CAPITAL LETTER OMEGA".

For these reasons, the MacOS Roman *encoding* and the MacOS Roman *codepage* are not compatible with each other.

So the question to the community is:
<strong>Should Fontlab Ltd. modify the MacOS Roman encoding file (mac_roman.enc) so that the mapping "Omega 189" is replaced with "uni03A9 189", which would meet all current recommendations by both Apple and Adobe?</strong>

Please reply by participating in the poll!

Thanks,
Adam Twardoch

[1] http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT
[2] http://sourceforge.net/projects/aglfn.adobe/files/aglfn.txt/download
[3] /Library/Application Support/FontLab/Encoding/T1 Roman-Western/mac_roman.enc
[4] /Library/Application Support/FontLab/Codepage/apple/mac_roman.cpg

[Evertype]

I recommend making the change as recommended by Apple and Adobe.

[graphity]

The endless swapping and changing to glyph names (like Omega) is getting quite tiresome and I doubt whether it actually really matters. I changed all my name files to 03A9=Omega back in 2005 when AGLFN 1.5 made this change and that's how I've left it ever since – and that's where I intend to leave it irrespective of what Adobe, Apple, FontLab or anyone else recommends. The situation regarding Omega (and some other glyph names) is quite absurd and is the very antithesis of the golden rule of stability. The process that has led to this mess has no credibility whatsoever – thank goodness the Unicode Standard doesn't work this way. No matter what the "powers that be" decide, there will be millions of non-conforming fonts around for many, many years to come. I'm sure there are reasonable historical and technical arguments for either side but, for what it's worth, it makes more sense to me that if uni03C9 is omega then uni03A9 should be Omega. All that being said, in these days of Unicode mapping why does it matter at all? Surely there are far more important issues to deal with.  Kevin

[Evertype]

Pretty much every time I open a font I have to deal with this. Isn't settling on Apple and Adobe's own recommendations reasonable?

[Niels Poppe]

Looks like the world gets tired from AGL or what name was that changed to again…

But, IMHO:
- Apple encodings describe what glyphs should be rendered. Not which unicodes they must have.
- Adobe naming conventions describe a way to map names to unicodes. Not which glyphs go in MacOS Roman encoding.
- The MacOS roman encoding has just few symbols encoded and cannot be used to type greek
- Most of these symbols have unicodes assigned that have nothing to do with either Apple, Adobe, or Greek.

So if there is a unicode in the math symbol range for any of those, it is the best choice. It is what Apple intended back when unicode was not yet invented.

And yes, the result of that will be that if you fire up you Macintosh LC with OS 6.3 and type away in greek, you will actually by typing wild formula’s. But you’ll have to find a floppy to install your new font first, so it will not happen that much.

[Evertype]

Adam, have you discussed this with Adobe and Apple and the UTC?

[Dezcom]

All the Greek glyphs which are also math glyphs have been a problem for me for years.  Don't stop at Omega.

[Adam Twardoch (FontLab)]

Niels,

> Apple encodings describe what glyphs should be rendered. Not which unicodes they must have

Unfortunately, this is now how it works. Apple, Microsoft and others define "codepages" as a way to convert text from 8-bit encodings to Unicode and back. These codepages are deposited at the Unicode consortium:
http://www.unicode.org/Public/MAPPINGS/VENDORS/

The MacOS Roman codepage as defined by Apple is used by operating systems and applications to convert between Unicode text and 8-bit MacOS Roman-encoded text. If you make a small text file in TextEdit that contains two characters: \u2126\u03A9 (given here with a backslash notation), save it as plain-text MacOS Roman-encoded, you'll get two characters: \BD\BD. But if you open that file again in TextEdit and save it as Unicode, you'll get a file that contains two Unicode characters: \u03A9\u03A9

This means that Apple holds a fallback mapping for MacOS Roman: \u2126 -> \BD and \u03A9 -> \BD, but the primary mapping is the second one, as it also works the other way: \BD (dec 189) always gets converted to \u03A9. Which is consistent with the MacOS Roman codepage definition deposited at Unicode.org.

With codepages, text mappings are of primary importance. Therefore, the same mappings should be used in fonts and font-related tools. In case of OpenType and TrueType fonts, new Mac OS X applications as well as Unicode-based Windows applications use the cmap 3.1 mapping of Unicodes to glyphs. For text encoded in MacOS Roman to be displayed properly with a given font, Mac OS X will first convert the MacOS Roman code 0xBD to U+03A9, and then it will look up the font's cmap 3.1 table for the mapping of U+03A9 to a glyph. (Old Mac OS applications use the direct mapping from cmap 1.0 to glyphs, so in cmap 1.0, 0xBD should map to the same glyph).

In case of Type 1 fonts, Mac OS X will parse the glyph names and map those to Unicodes using an internal list, and the will display the glyph with the appropriate name. Also, in case of OpenType PS (.otf) and Type 1 fonts, Adobe Acrobat and other PDF parsers will retrieve the original Unicode codepoint by parsing the glyph name.

Theoretically, Mac OS X should do it by using the Adobe Glyph List (AGL) plus the "uniXXXX"/"uXXXX" glyph naming convention. However, in Mac OS X 10.6.8, it does not to seem be doing it. It does understand AGL but not the uniXXXX naming.

I've just tested a Mac Type 1 font which has two glyphs: one named "Omega", the other named "uni03A9". As one would expect, the "Omega" glyph was mapped to U+2126, so Apple implements the Adobe Glyph List mappings. But it seems that Mac OS X still does not understand the "uniXXXX" convention as the U+03A9 character is not displayed using the uni03A9 glyph. But at least Adobe InDesign does that correctly (and so does Adobe Acrobat).

I also tested another variant of this font which, instead of "uni03A9" uses "Omegagreek", which is the old AGL name. Then Mac OS X (TextEdit) will display the glyph. (Reminder: "Omega" is part of both Adobe Glyph List and Adobe Glyph List for New Fonts, "Omegagreek" is only part of Adobe Glyph List).

In any case, even though Mac OS X does not "understand" uni03A9, it will still map "Omega" to U+2126, not to U+03A9. This means that in any case, the mac_roman.enc should be changed.

The 189 mapping there should point to the glyph for which the Unicode is U+03A9. The new name for that glyph is "uni03A9". The old name for that glyph is "Omegagreek". Mac OS X will not understand the new name, only the old name.

For that reason, I believe that we'll need to do some more changes: produce an branch of encodings ("obsolete") which are strictly compatible with AGL (the old naming), and change the "proper" branch of encodings which are compatible with the new naming.

Sigh.

[Luc[as]]

The poll states:
YES, change it to "uni03A9" (this will remove ambiguities but old Type 1 fonts may become incompatible)
Which is not correct, old Type 1 fonts will not change or become incompatible because of a change in an encoding file. *New* Type 1 fonts could have problems :-)
Because encoding files are production relevant only for Type 1 fonts, I would not change the old .enc files. The last time I used an encoding for T1 production is really very long ago, and I used an old FontLab with old encoding files anyhow. Who cares, go make a new FontLab!