[mpeg-OTspec] Re: Apple Spliced Font Format

[Tony Tseung]

Ken,

My response are below.

Tony

On Apr 4, 2010, at 9:22 AM, Ken Lunde wrote:

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

CID is a defunct encoding that only Adobe uses. Here we are concentrating on Unicode coverage thus I have unicode (character) to glyph mapping to override the cmap. The main idea is to be able to using a posing font specific cmap for the component. CID instead of glyphs sounds like a bit off, but may be an optionl override independent of the cmap-override.

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

Ken, the key here is to NOT require the extra attributes.

If the designer of the splice font is require to be specific version, a version attribute should be added to the component description along with other attributes such as DSIG, checksum, finger-print, DNA-code-sequence..., the implementer can deal with the rest. 

To the implementer, the art is in how to make the best result with less specifics. We should not mandate anything. One example I had in the past is people ask to just display some alphabets instead of boxes if you don't have the font (or any font?).


> 
> Regards
> 
> -- Ken
> 
> 
> 


PS: There was a talk of the name types being a number rather than the name, this was simply in the merits of the name table specification of TrueType (OpenType) fonts, the enum value are identical to the id's in the name table. I meant to make a list of aliases but didn't quite get arround for that. It may be good to spell out the name type. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100407/93082df8/attachment.html>