[mpeg-OTspec] Re: Apple Spliced Font Format

[Ken Lunde]

Jim,

You wrote:

> Looking at the DTD, I see that it is quite verbose -- as shown by elements such as:
> 
> <language language="en"/>
> 
> but the Name element's type attribute is numeric (based on ids in OFF). It seems like it would be more consistant to use something like:
> 
> <Name type="FullName" string="Symbol" language="en"/>
> 
> or, in keeping with <language/>, even:
> 
> <Name type="FullName" name="Symbol" language="en"/>
> 
> than:
> 
> <Name type="4" string="Symbol" language="en"/>
> 
> Using the type's name rather than a number will help make the files self-documenting. It would also help make an RNG schema both self-documenting and more able to fully validate an instance.

I like this idea. Verbose is good.

> AFAICT, the member fonts are specified only by the name attribute of the ComponentDef element. But the cmapOverride maps characters to glyph IDs. The problem with that is that glyph ids can change between different versions of a font. Either the cmap overrides need to be done in a way which supports that, or the xml needs to be able to document for which version(s) of the component fonts that version of the xml file is designed.

One of the attributes that we would add to the ComponentDef element, which would be optional, is the ability to specify a version. Another optional attribute for this element is specifying the location.

In any case, this brings up a good point in that when mapping from code points to glyphs, such as when the cmapOverride is invoked, there should be a distinction between GID and CID. Of course, CIDs matter only to CID-keyed fonts, which are typically CJK, and are PostScript-based. For CID-keyed fonts, as long as all of the CIDs are contiguous, GID equals CID. If even one CID is excluded, making the CIDs no longer contiguous, there is a GID/CID mismatch that starts from the first CID that is excluded.

Anyway, this may lead to adding characterRefID that can be specified in lieu of glyphRefID if the ComponentDef font is CID-keyed. In the case of characterRefID, the mappings can be considered stable across all versions of the specified ComponentDef font. You are correct that it is not the case when using glyphRefID. In fact, the use of glyphRefID may make specifying the version of the ComponentDef font a required thing.

Regards...

-- Ken