<HTML>
<HEAD>
<TITLE>Re: [mpeg-OTspec] Re: Apple Spliced Font Format</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Tony:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
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?<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
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.<BR>
<BR>
Regards,<BR>
<BR>
— daan Strebe<BR>
Senior Computer Scientist<BR>
Adobe Systems Incorporated<BR>
<BR>
<BR>
On 4/9/10 9:14 AM, "Tony Tseung" <<a href="tseung@apple.com">tseung@apple.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
<BR>
<BR>
<BR>
<BR>
Ken,<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
Tony<BR>
<BR>
On Apr 7, 2010, at 11:57 AM, Ken Lunde! wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
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.<BR>
<BR>
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:<BR>
<BR>
0-20316<BR>
21072-21074<BR>
21371<BR>
21558<BR>
21722<BR>
21933<BR>
22920<BR>
<BR>
If you dump the GID range, which *must* be contiguous, it is as follows:<BR>
<BR>
0-20324<BR>
<BR>
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.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>