[mpeg-OTspec] Re: Apple Spliced Font Format

[Ken Lunde]

Tony,

The mapping between CID and GID is maintained in the 'CFF' table. And, because only CID-keyed OpenType/CFF fonts are CID-keyed, this mapping needs to be maintained only for such fonts. (As I stated before, such fonts represent a non-trivial number of Japanese fonts in use today.)

Below are examples of CID versus GID, first showing how three Unicode code points map to three Adobe-Japan1-6 CIDs (note that any use of CID is closely tied to its ROS, which is Adobe-Japan1-6 for this example):

  U+8B7F -> Adobe-Japan1-6 CID+21074
  U+FA20 -> Adobe-Japan1-6 CID+21073
  U+FA40 -> Adobe-Japan1-6 CID+21072

The following are the GID mappings for the same glyphs in any of our Pr6N fonts, such as KozMinPr6N-Regular:

  U+8B7F -> GID+21074
  U+FA20 -> GID+21073
  U+FA40 -> GID+21072

The mappings appear to be the same, because CIDs equal GIDs in this font, which is because all Adobe-Japan1-6 CIDs, 0 through 23057, are included.

The following are the GID mappings for Apple's HiraKakuProN-W3, which includes eight glyphs beyond Adobe-Japan1-5 (CIDs 0 through 20316), and for which GIDs become not equal to CIDs from GID+20317:

  U+8B7F -> GID+20319
  U+FA20 -> GID+20318
  U+FA40 -> GID+20317

The following is the same information from one of our PlusN (equivalent to StdN) fonts, which includes Adobe-Japan1-3 (CIDs 0 through 9353) plus 144 additional glyphs:

  U+8B7F -> GID+9497
  U+FA20 -> GID+9496
  U+FA40 -> GID+9495

For this font, GIDs become not equal to CIDs from GID+9355.

My point is that for all three of these differing glyph complements, because the fonts are CID-keyed and thus include the CID<->GID mapping in their 'CFF' tables, I can refer to the same glyphs by specifying their CIDs. This seems mighty convenient to me. If Apple hasn't leveraged this yet, you should. We certainly do.

Regards...

-- Ken

On 2010/04/09, at 9:14, Tony Tseung wrote:

> Ken,
> 
> I don't disagree with the CID overwrite table as it is useful for some clients. From my perspective, the unicode-glyph mapping table is of more importance.  One of the problems with the CID table is that we now have to deal multiple parallel mapping tables, so the consistency for cross platform is compromised.  I would argue it is a convenience, not a necessity.  In my view, the native component font should always provide the CID-GID mapping somehow. Given that there is a unicode to glyph mapping, one can derive the CID.
> 
> Also the cmap-override-table is of specific use when the unicode to glyph mapping (cmap) in the native component font is to be ignored from the spliced font. Otherwise a unicode range can be more effective to limit the character ranges used from a component - the effect of "subsetted" font.
> 
> Tony
> 
> On Apr 7, 2010, at 11:57 AM, Ken Lunde wrote:
> 
>> 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.
>> 
>> 
>