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

Wed Jun 3 16:50:56 CEST 2015

Thank you Ken,

I agree and share your point of view but I also understand Behdad’s position and his desire to enable font tools make intelligent decisions that are not in any way limited by today’s prescriptions that might get outdated at some point in the near (or distant) future.

So considering both of these views – I’d propose that we should specifically mention the unique role that ‘name’ table plays in a font collection (serving as a unique identifier attached to a font component) and also explicitly mention that any other tables can be shared and the decision to do so is based solely on the design decisions applied to font components and font collections that include them.

Behdad, all – what do you think? Should the spec remain completely silent on any of these issues or should we clarify it as described above?

Thank you,
Vladimir

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde lunde at adobe.com [mpeg-OTspec]
Sent: Tuesday, June 02, 2015 6:36 PM
To: mpeg-OTspec at yahoogroups.com; opentype-list at indx.co.uk
Subject: Re: [mpeg-OTspec] Draft amendment of ISO/IEC 14496-22 OFF (3rd edition)

Vladimir,

Thank you for forwarding Behdad's email, which I apparently missed, perhaps due to Adobe's over-protective filters.

Anyway, I disagree with him only about a single point, specifically that at least one 'sfnt' table must be different for the fonts within the collection, and the obvious candidate is the 'name' table, as it provides the one string that makes a font unique, specifically referring to the name.ID=6 (PostScript font name) string.

Regards...

-- Ken

> On Jun 2, 2015, at 2:56 PM, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>> wrote:
>
> [Attachment(s) from Levantovsky, Vladimir included below]
> 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<mailto: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<mailto: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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20150603/03418c8b/attachment.html>