[mpeg-OTspec] CFR ascender and descender

[Levantovsky, Vladimir]

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