[mpeg-OTspec] Draft amendment of ISO/IEC 14496-22 OFF (3rd edition)

[Ken Lunde]

Vladimir,

Based on where the head.checkSumAdjustment discussions are heading, and based on all of the usage scenarios that I can think of (as someone who has implemented various flavors of collections), my opinion is that any table can be shared except for one, which is the 'name' table. For all other tables, it is possible for two or more fonts in a collection to share a single instance of a table.

Regards...

-- Ken

> On May 20, 2015, at 9:03 AM, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote:
> 
> 
> Dear AHG members,
> 
>  
> 
> I would like to make an attempt to summarize the discussion we had to date, and to compile the “to do” list for the issues we still need address.
> 
> Just as a reminder, at the last WG11 meeting we had liaison statement submitted by the W3C outlining certain aspects related to OFF font collections, among them:
> 
> 1)      OFF spec is silent about what tables can or cannot be shared in a font collection – should we address this (either as a normative part of the spec or as part of Recommendations section)?
> 
> 2)      The scope of fonts collections has been extended in the 3rd edition document to allow both TrueType and CFF outlines be shared among different font in a collection. At the same time, we also added support for SVG outlines, which raised a number of questions still to be answered – should any mixed type of outlines be allowed/shared in a font collection? Are there any possible limitations that need to be considered?
> 
> 3)      There are certain tables that contain information specific to a single font – these tables are likely to not be shared. Should we explicitly list the tables that are not allowed to be shared in a font collection?
> 
> Font header table ('head') is one example of such table, which contains various data fields such as flags, time stamps, bounding box size and other data that represent unique parameters and values for one particular font. Among these values there is a "checkSumAdjustment" value that in a single font file represents the global checksum adjustment for the whole file. It was unclear how this field should be computed when a font collection file includes a number of different 'head' tables and where some tables are shared between multiple fonts – what the implementations should do to validate the file using checksums?
> 
> 4)      The updates to OpenType spec version 1.7 (keeping it in sync with the ISO 3rdedition document) has recently been published on the Microsoft website (http://www.microsoft.com/typography/otspec/default.htm?fname=%20&fsize=). As a result of the public review of the spec – there were few mistakes reported that need corrections in the ISO document. Among them, the descriptions of sTypoLineGap, usWinAscent and usWinDescent fields refer to unsigned values of "usTypoLineGap", "usTypoAscender" and "usTypoDescender" (note that these are in fact defined as signed values) that should be referenced as "sTypoLineGap", "sTypoAscender" and "sTypoDescender", as they are referenced everywhere else.
> 
>  
> 
> I believe that issue 4) is a simple matter requiring only an editorial fix, if I hear no objections I will add these to the future draft amendment proposal.
> 
> 
> One aspect of issue 3) related to calculating global checkSumAdjustment value in font header table has been discussed on the list and I believe that the prevailing opinion is that this value should only be calculated for an individual font files. For fonts included as components of a font collection file – the specification should state that the checkSumAdjustment values do not apply to font collection entries and should be ignored by implementations. Again, if this is the case and I do not see any objections – I will add this proposed change to the draft amendment.
> 
>  
> 
> However, the remaining items (namely - providing the guidance on tables that can / cannot be shared and how to deal with font collections containing mixed types of TTF/CFF/SVG outlines) still need to be addressed – your contributions and opinions on what is the best way to do it is very much appreciated. We have three weeks left to prepare the draft amendment, which can also address any other changes and clarifications you want to see in the ISO spec – please provide your comments/suggestions on this list and (pending consensus approval) I will incorporate them in the draft amendment.
> 
>  
> 
> Thank you,
> 
> Vladimir
> 
>  
> 
> 
>