New GlyphOrderAndAliasDB?

Andreas,

You're right. Current versions of Acrobat do not recognize all aspects of Adobe's glyph naming conventions, just the AGL. We hope to have the Acrobat team remedy this in a future release of Acrobat.

T

I see that you are correct that we did not document the changes to the GOAADB in MakeOTF.pdf My apologies - we will fix this in the next release. I also see that we didn't document this anywhere else, either.

There are two changes to the GOAADB file. The first is that we added a third column. The third column is used to assign a glyph name to a specific Unicode Value. This done so that we could assign Unicode values to glyph names that are not in the Adobe Glyph List, and without using a name in the form of "u0041". This was done in order to permit us to make the second change.

The second change is that we have revised the suggested final glyph names. We now use the unicode name form (e.g uniXXXX or uXXXX) only for glyphs where the name has no semantic content.. In particular, if a glyph is a variant of a base glyph that is in Unicode, we name the new glyph with the base glyph name plus a suffix. - for example, "a.sc" rather than Asmall, or "A.titling" rather than "Atitling". This practice permits some applications, in particular, Acrobat, to usefully search text set in such glyph variants. For the same reason, we no longer double-map a single glyph to more than one Unicode value; we instead duplicate the glyph, so that there is one glyph per UV value, and one UV value per glyph in the font. Yo will sson see these notes posted as a revision to the AGL. This revision has been summarized by Eric Muller in e-mails to the opentype@topica.com list.

The final item you noticed is not related to the GOAADB changes, and is a practice that some font developers may disagree with. The change is that in some cases, we have made duplicate glyphs, in order to provide a clear round-trip fro a base glyph to a variant back to a base glyph. This is becuase some applications, such as InDesign, are smart enought to import a pdf file, and to ntoice that a glyph like a.sc is a variant of a base glyph, and to use the feature file to figure out how to represent the glyph as a base glyph + a feature. However, in the case of a.sc, there can be two features which get you to a.sc: The feature 'c2sc' will map 'A' to 'a.sc', and the feature 'smcp' will map 'a' to 'a.sc'. In order to avoid this confusion, we duplicated all the small cap glyphs under an upper and lower case base name form, e.g. 'a.sc' and "A.sc'. The feature c2sc maps 'A' to 'A.sc', and the feature smcp maps the glyph 'a' to 'a.sc' . An application can then deduce the correct base glyph from either the name, or by reversing the feature substitutions.
You will not see a mapping from any glyph to 'A.sc' in the GOAADB, becuase they are generated on the fly, as the font is being built - I wrote a script to duplicate the small cap glyphs under names like 'A.sc' during the build process. It would be easy enough to do this with FontLab or RoboFog, and I will be doing so when we move from our antiquated Unix build tools next year.

Remember that the GOAADB is not a fixed specification - it is an example file for you to edit as you see fit.