[mpeg-OTspec] Re: Apple Spliced Font Format

[Ken Lunde]

Tony,

You wrote:

> CID is a defunct encoding that only Adobe uses. Here we are concentrating on Unicode coverage thus I have unicode (character) to glyph mapping to override the cmap. The main idea is to be able to using a posing font specific cmap for the component. CID instead of glyphs sounds like a bit off, but may be an optionl override independent of the cmap-override.

As daan pointed out, the use of CIDs to identify glyphs is far from being defunct, and among the CJK fonts available today, a non-trivial number of them are CID-keyed OpenType/CFF fonts. Morisawa alone has nearly 1,000 such fonts.

My point would be that while for a large number of fonts, CID equals GID. Among the Hiragino fonts that are bundled with Mac OS X, some of them are actually in the "CID does not equal GID" category, specifically the StdN and ProN fonts. Using HiraginoKakuProN-W3 as an example, it includes the following CIDs:

  0-20316
  21072-21074
  21371
  21558
  21722
  21933
  22920

If you dump the GID range, which *must* be contiguous, it is as follows:

  0-20324

So, up until CID+20316, the CIDs are equal to GIDs. After that, they are not, and it is useful to be able to specify CID or GID, depending on the intent of the creator of the CFS object. Of course, CIDs can be specified only if the component font is CID-keyed.

> PS: There was a talk of the name types being a number rather than the name, this was simply in the merits of the name table specification of TrueType (OpenType) fonts, the enum value are identical to the id's in the name table. I meant to make a list of aliases but didn't quite get arround for that. It may be good to spell out the name type.

I am glad that you agree that specifying the Name attributes by name is a good thing.

Regards...

-- Ken