[mpeg-OTspec] CFR ascender and descender

[Levantovsky, Vladimir]

Hi Ken,

Please see below the actual proposed text I put in the draft ballot comments (the text is also the same for both descender and linegap arguments):

ascender = "string"
Optional. When provided, this value of ascender will be used by the host rendering system implementations and will override the default value of each component font - it is the CFR author's responsibility to make sure that the value is suitable for all component fonts on various host rendering systems.
If the value of ascender is not defined, the host rendering system will use the first, highest priority component font to determine the ascender value according to the algorithm defined in the ISO/IEC 14496-22 (in the "Baseline to Baseline Distances" section of the "Recommendations" clause.)

I think this covers the use case you described. I understand that we can't really make authors do the right things, but we at least should make them aware of consequences of the choices they make, and this was the intent of my proposed text.

Comments?

Thank you,
Vlad


> -----Original Message-----
> From: Ken Lunde [mailto:lunde at adobe.com]
> Sent: Thursday, December 05, 2013 3:48 PM
> To: Levantovsky, Vladimir
> Cc: OTspec (mpeg-OTspec at yahoogroups.com)
> Subject: Re: [mpeg-OTspec] CFR ascender and descender
> 
> Vladimir,
> 
> I have only the following comment:
> 
> > I think it would be useful to add a language in the spec saying that
> > it is CFR author responsibility to ensure that the provided set of
> > values for ascender / descender / linegap metrics (as part of the CFR
> > <Font
> > Metrics> element) is usable on multiple different platforms. Ideally,
> > this is what authors would want to happen anyway, so a simple
> reminder
> > may be sufficient.
> 
> Because CFR object authors may care about only specific platforms,
> perhaps change "multiple different platforms" to "platforms that the
> CFR object author cares about or those platforms in which the CFR
> object is expected to be deployed." For example, if an OS developer
> creates a series of CFR objects to handle font fallback, they probably
> care about only their OS. Of course, your paragraph is not the exact
> wording that you were going to use, but I think you get the meaning.
> 
> Regards...
> 
> -- Ken
> 
> On Dec 5, 2013, at 7:39 AM, Levantovsky, Vladimir
> <vladimir.levantovsky at monotype.com> wrote:
> 
> > Dear all,
> >
> > I haven't received any additional feedback on the proposed
> clarifications (see below). In absence of the negative feedback, your
> silence will be treated as approval of the proposed changes. Speak up
> if you disagree!
> > I am in the process of preparing the draft response to the ISO ballot
> (it needs to be registered today but can be modified and updated before
> Jan. 10 submission date).
> >
> > Thank you,
> > Vladimir
> >
> >
> >> -----Original Message-----
> >> From: mpeg-OTspec at yahoogroups.com
> >> [mailto:mpeg-OTspec at yahoogroups.com]
> >> On Behalf Of Levantovsky, Vladimir
> >> Sent: Wednesday, November 20, 2013 12:03 PM
> >> To: John Hudson
> >> Cc: OTspec (mpeg-OTspec at yahoogroups.com)
> >> Subject: RE: [mpeg-OTspec] CFR ascender and descender
> >>
> >> Hi John,
> >>
> >> On Tuesday, November 19, 2013 2:02 PM John Hudson wrote:
> >>>
> >>> Vladimir wrote:
> >>>
> >>>> In particular, I would suggest to at least consider the following
> >>> strategy:
> >>>> - if the CFR <FontMetrics> element defines ascender and descender
> >>>> values
> >>>> - the implementation will use the values defined by a CFR author;
> >>>
> >>> Perhaps we also need to look more closely at what it means to 'use'
> >>> those metrics, in terms of the distinction that OS/2 metrics have
> at
> >>> least tried to make between linespacing metrics and bounding box
> >>> metrics (even if in practice the two have been conflated most of
> the
> >>> time).
> >>>
> >>
> >> I think it would be useful to add a language in the spec saying that
> >> it is CFR author responsibility to ensure that the provided set of
> >> values for ascender / descender / linegap metrics (as part of the
> CFR
> >> <Font
> >> Metrics> element) is usable on multiple different platforms.
> Ideally,
> >> this is what authors would want to happen anyway, so a simple
> >> reminder may be sufficient.
> >>
> >>>> - if the ascender and descender values are not explicitly defined,
> >>> the
> >>>> implementation will use the first, highest-priority component font
> >>>> to determine the ascender and descender values according to the
> >>> algorithm
> >>>> defined in the "Baseline to Baseline Distances" section of the
> >>>> OT/OFF "Recommendations" clause.
> >>>
> >>> This seems like a step in the right direction. Will need to review
> >>> those recommendations again, though.
> >>>
> >>> I understand that Google did a lot of cross-browser testing of
> >>> linespacing behaviour, and as a result came up with recommendations
> >>> for their webfonts that differ from the recommendations we've
> worked
> >>> with on Microsoft fonts for the past decade.
> >>
> >> What I would like to avoid is the discrepancy in font behavior when
> >> e.g. the font used as a standalone resource on a given platform
> >> produces different results compared to the same font used as part of
> >> the CFR recipe (on the same platform). Following the recommendations
> >> that have been in use for years and widely implemented seems like a
> >> reasonable approach - doesn't guarantee that things always be
> ideally
> >> spaced but at least the spacing behavior will be consistent (when
> >> comparing standalone font resource vs. the same as a primary
> >> component font).
> >>
> >> Thank you,
> >> Vlad
> >>
> >>
> >>
> >> ------------------------------------
> >>
> >> Yahoo Groups Links
> >>
> >>
> >>