[mpeg-OTspec] Re: Apple Spliced Font Format

[Ken Lunde]

Jim,

You wrote:

>>>>>> "KL" == Ken Lunde <lunde at adobe.com> writes:
> 
> KL> In any case, this brings up a good point in that when mapping from
> KL> code points to glyphs, such as when the cmapOverride is invoked, there
> KL> should be a distinction between GID and CID. Of course, CIDs matter
> KL> only to CID-keyed fonts, which are typically CJK, and are
> KL> PostScript-based. For CID-keyed fonts, as long as all of the CIDs are
> KL> contiguous, GID equals CID. If even one CID is excluded, making the
> KL> CIDs no longer contiguous, there is a GID/CID mismatch that starts
> KL> from the first CID that is excluded.
> 
> Yes, I should have thought of CID, too. For component fonts which are
> CID keyed, it seems clear that any cmap override should use them rather
> that use GIDs. Just for robustness' sake.

I can go along with this. The main reason I suggested a separate attribute for CID, such as characterRefID, is because it is possible to query a CID-keyed OpenType/CFF font using GIDs or CIDs, and getting different results if the GIDs are not equal to CIDs. Making this distinction more explicit may have some merit.

> KL> the use of glyphRefID may make specifying the version of the
> KL> ComponentDef font a required thing.
> 
> I occurs to me that there isn't even any guarantee of GID consistancy
> between different compiles of a given version of a font.  That may
> matter less for customers of commercial foundries and for customers/
> users of binary distributions than for users of source distributions,
> but it could still become an issue.
> 
> And then there is the issue that fonts are occasionally updates without
> chaning their version field.
> 
> I have no idea how significant of an issue it will be in practice.  It
> may well compare to a cryto break which works in 2^110 time and/or space;
> better than the 2^127 time a brute-force attach will average, but still
> well beyond practical.
> 
> Or it may lead to hordes of support calls.
> 
> Probably somewhere in between. :)

What David wrote echoes my feelings about this matter, specifically that version-control is very important, and fonts that use the same version number across multiple and differing instances of the same font can be considered malformed or otherwise defective.

I can confidently state that all of the OpenType CJK fonts I have built thus far have unique version numbers, as expressed in the head.fontRevision field. Of course, I cannot speak for other type foundries.

Simply making the version of the corresponding ComponentDef font resource a required attribute is the best that can probably be done, short of fingerprinting font resources outside the context of a version number.

Regards

-- Ken