[mpeg-OTspec] Re: Apple Spliced Font Format

[James Cloos]

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

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

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6