• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

New GlyphOrderAndAliasDB?

New Here ,
Oct 16, 2002 Oct 16, 2002

Copy link to clipboard

Copied

It seems that Adobe has changed the scheme for glyph naming in the latest wave of fonts. E.g. the naming of SC where before Asmall etc., but is now A.sc and a.sc, right?

The GlyphOrderAndAliasDB file in the latest FDK has this changes implemented in a three column mapping instead of two columns used before. But in this file the naming is:

a.sc Asmall uniF761

Instead of:

a.sc A.sc uniF761

which is what Adobe seems to use in the latest wave of fonts.

The question: is there a later GOAADB file available?

Related: the useage of three columns in this file is not documented in the latest makeOTF.pdf as I can see.

Thanks,

/mårten
TOPICS
Open Type FDK

Views

1.1K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Oct 17, 2002 Oct 17, 2002

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Oct 17, 2002 Oct 17, 2002

Copy link to clipboard

Copied

Hallo Robert,

I have tested finding a word string in Acrobat 5 with no luke - so
Acrobat 5.1 will support glyhs like A.sc in the next release?

Its possible to name the glyph with my own extension like "one.tnum"
instead of "one.fitted"? Or will Acrobat only support the naming from
the AdobeGlyphlist?



Andreas

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Oct 18, 2002 Oct 18, 2002

Copy link to clipboard

Copied

LATEST
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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines