Re: [font-metrics-api] Zooming out on font metrics

On 8/28/15, 9:50 AM, "John Daggett" <jdaggett@mozilla.com> wrote:

>
>Alan Stearns wrote:
>
>> So the capHeight measure for a deadrange, deadfragment and element
>> would always be the capHeight measure of the first glyph of the first
>> in-flow linebox (with any other qualifications we might need to
>> stipulate, particularly for deadranges that might start in the middle
>> of a glyph). We should arrive at a consistent definition that gets to
>> the actual source of the data, and we can quibble over whether these
>> things should be made available in a single interface or several, but
>> I definitely think it’s sane and useful to talk about the capHeight of
>> an element.
>
>This is *precisely* what I was talking about. 
>
>The 'capHeight' of the first glyph in a line is a font metric, it's not
>a linebox metric.

I don’t think it’s a font metric - it’s a glyph metric. The font metric is an input, but it’s been futzed with by font size, transforms, etc. to result in a pixel position that’s relevant in the typographic layout results.

> There may be metrics for the line that boil down to
>the max capHeight of all the inline boxes within a given linebox but we
>should keep the two separate.

Defining a capHeight for a fragment or element as the max of the first in-flow linebox is another possibility, but I don’t think it’s as useful as getting the result for the first glyph. With finer-grained access to ranges and/or glyphs the max could be calculated from the per-glyph measure.

> While spec'ing things this way may help
>your dropcaps example I don't think it's a good thing for a more general
>set of use cases.

Can you describe any of these more general use cases, so we can better evaluate our options?

Thanks,

Alan

Received on Friday, 28 August 2015 08:03:05 UTC