[mpeg-OTspec] CFR ascender and descender

[Levantovsky, Vladimir]

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