[mpeg-OTspec] Re: Apple Spliced Font Format

[Daniel Strebe]

Tony:

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 do not understand how CID relates to consistency across platforms. Why would CID or its mappings to and from glyph ID or Unicode differ by platform?

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.

Some glyphs have no Unicode representation. Some Unicode code points map to multiple glyphs. CID-to-glyph is a one-to-one mapping. I do not follow your reasoning.

Regards,

- daan Strebe
Senior Computer Scientist
Adobe Systems Incorporated


On 4/9/10 9:14 AM, "Tony Tseung" <tseung at apple.com> 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.






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