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

Levantovsky, Vladimir vladimir.levantovsky at monotype.com
Mon Apr 6 17:11:27 CEST 2015

[Adding the MPEG-OTspec email list back to the recipients' list where this discussion belongs]

-----Original Message-----
On Saturday, April 04, 2015 7:14 PM Richard Wordingham wrote:

> On Fri, 3 Apr 2015 16:18:03 +0000
> "Ken Lunde " <lunde at adobe.com> 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.

Regarding the checkSumAdjustment for the entire font - yes, the current spec talks only about fonts, but it is not clear whether the entire font includes the table directory and table offsets. If it does, then the checkSumAdjustment value calculated for the entire font will never be the same once that font is wrapped into a font collection (as John Jenkins mentioned earlier), and there is no way to correct the issues unless the font is 'unwrapped' from the collection (which never happens, should not happen by design, and even then the original table order would remain a big unknown).

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

I don’t believe that overlapping tables are allowed in any font spec, and it is definitely a security risk. Webfont compressors (both WOFF and WOFF2) will invalidate a font with overlapping tables, and this is currently a mandatory step for any compliant WOFF/WOFF2 decoder.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20150406/45e83c40/attachment.html>

More information about the mpeg-otspec mailing list