[OpenType] ISO/IEC 14496-22 Amendment for Font Collections

[Ken Lunde]

Richard,

You wrote:

>> With regard to the "checkSumAdjustment" field of the 'head' table,
>> long-time implementers of TrueType Collections, meaning Apple and
>> Microsoft, are the ones who should weigh in on this particular issue.
>> Given that the definition of this field is for a file, and because a
>> Font Collection is merely a bucket of multiple 'sfnt' tables, and
>> contains two or more "virtual" font files, my guess is that this field
>> is ignored in the context of Font Collections. But again, Apple and
>> Microsoft should weigh in for clarity and guidance.
> 
> The 'calculating checksums' section of
> www.microsoft.com/typography/otspec/otff.htm talks only in terms of
> tables and fonts; it does not talk of files.

Hence the need for clarity, in terms of how this pertains to Font Collections. What John Jenkins wrote suggests that the head.checkSumAdjustment value is calculated for the component fonts prior to stitching them together in a Font Collection, and are not adjusted after the fact.

It'd be good for the font folks at Microsoft to chime in here, and I'd argue that we cannot make progress on this particular issue until someone from Microsoft does so.

>> About which tables can and cannot be shared, my view is that the
>> general principle should be that all tables can be shared, but to
>> specify exceptions. The most obvious exception is the 'name' table,
>> because it defines the name space for each font in the Font
>> Collection, and thus must be unique.
> 
> Is there any prohibition on the tables of different fonts overlapping?
> If there is not, then different name tables could effectively share a
> common string area, e.g. a layout such as:
> 
> Font 1 indices
> Font 2 indices
> Common string area
> 
> For Font 1, the name table would start at the Font 1 indices, while for
> Font 2, the name table would start at the Font 2 indices.  A possible
> complication is that the Font 2 indices might have to be declared to be
> part of the Font 1 string storage.
> 
> A similar trick might be applied to sharing common elements of GSUB or
> GPOS tables.  I have in mind sharing glyphs between fonts with
> different layout policies - like Vietnamese v. the rest of the Latin
> world, but without the ability to select by language.  I already need
> extension lookups if I don't disperse the lookup tables.

My understanding of how Font Collections work is that table sharing is done on a "whole table" basis, and I think that there is greater robustness and predictability in keeping it that way.

Regards...

-- Ken