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

[Ken Lunde]

Vladimir,

This brings up another thing that probably should be explicitly mentioned in the specification, which is the number of fonts in a Font Collection. Well, the specification states that the size of the numFonts field is ULONG (32-bit unsigned integer), which implicitly states that the maximum is 4,294,967,296 fonts, but there are obviously implementation limits that bring the number down to the double or triple digits.

As an example of experience with this, when we released the Source Han Sans and Noto Sans CJK "Super OTC" last September, which include 28 fonts, it broke OTMaster, which had assumed that a maximum of 10 fonts would be in a Font Collection.

The point here is that it'd be a good idea to have a common implementation limit, if mentioning it in the specification is deemed necessary, which will improve the cross-platform experience.

Regards...

-- Ken

> On Apr 6, 2015, at 8:20 AM, Levantovsky, Vladimir <vladimir.levantovsky at monotype.com> wrote:
> 
> John,
>  
> Thank you for providing additional info, but it raises new questions:
> 1)      When a font / SFNT resource is treated as a file for the purpose of calculating the checkSumAdjustment – does that include the table directory with all the offsets? If yes, then wrapping that font in a font collection will invalidate  checkSumAdjustment values since the combined table directory for a collection will have different table offsets (and I doubt it would be ever possible to recreate the ‘old’ offsets to check font data integrity using checkSumsAdjustments for each individual font in the collection.
> 2)      How do you treat checkSumAdjustment values for font collection entries in the current implementation? Are they ever checked or do you ignore them completely? If latter is the case (and this is consistent with what other implementations do today) – given the current practices we should probably modify the spec and explicitly mention that checksums do not apply to font collections and must be ignored. Would you agree?
>  
> Thank you,
> Vladimir
>  
>  
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of 'John H. Jenkins' jenkins at apple.com [mpeg-OTspec]
> Sent: Friday, April 03, 2015 1:46 PM
> To: Ken Lunde
> Cc: OTspec (mpeg-OTspec at yahoogroups.com); opentype-list at indx.co.uk
> Subject: Re: [mpeg-OTspec] ISO/IEC 14496-22 Amendment for Font Collections
>  
> 
> 
> I don't know that we've ever thought of this is really being for a file, because for a long time the primary delivery mechanism for TrueType fonts at Apple was the 'sfnt' resource. At the moment, when we calculate the checksum adjustment, we treat the font as if it were a file (that is, as a contiguous block of data). The folding of the fonts into a collection happens later.
>  
> On 3 Apr 2015, at 10:18, Ken Lunde lunde at adobe.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.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.
>  
> 
> 
> 
> 
>