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

[Levantovsky, Vladimir]

Dear all,

Thank you very much for your input on these issues. Please see attached the draft proposal for the amendment where I made an attempt to summarize both the new proposals and corrections we discussed and agreed on to date. If there is anything I missed, or if there are any additional items you would like to see introduced as part of the amendment - please respond to this email with your proposals.

Thank you,
Vlad


-----Original Message-----
From: Behdad Esfahbod [mailto:behdad.esfahbod at gmail.com] 
Sent: Friday, May 22, 2015 2:17 AM
To: Levantovsky, Vladimir; mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Draft amendment of ISO/IEC 14496-22 OFF (3rd edition)

On 15-05-20 09:03 AM, 'Levantovsky, Vladimir'
vladimir.levantovsky at monotype.com [mpeg-OTspec] 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)?

No!  The sharing should be an automatic byte-saving feature of the compiler.
Whether tables are shared or not does not, and should not, have any semantic meaning.  Only recommendation possible would be "share tables when possible".


> 2)      The scope of fonts collections has been extended in the 3^rd 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?

IMO collections are a container mechanism and shouldn't care what tables are inside the font.  So I'm all for relaxing things as much as possible here.


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

No.


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

I suggest we deprecate checkSumAdjustment completely (for collections and non-collections).


Cheers,

behdad

> 4)      The updates to OpenType spec version 1.7 (keeping it in sync with the
> ISO 3^rd edition document) has recently been published on the 
> Microsoft website 
> (http://www.microsoft.com/typography/otspec/default.htm?fname=%20&fsiz
> e=). 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
> 
>  
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 368 bytes
Desc: m3xxxx-ProposedAmendmentItems_OFF.doc
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20150602/3416bc62/attachment.bin>