[mpeg-OTspec] Re: Apple Spliced Font Format

[Tony Tseung]

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.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100409/3dc039d5/attachment.html>