W3C home > Mailing lists > Public > public-houdini@w3.org > August 2015

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

From: Alan Stearns <stearns@adobe.com>
Date: Fri, 28 Aug 2015 08:02:27 +0000
To: John Daggett <jdaggett@mozilla.com>
CC: "public-houdini@w3.org" <public-houdini@w3.org>
Message-ID: <827F1AC5-D1A7-4E70-86BA-2899FA85EEC1@adobe.com>
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?


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

This archive was generated by hypermail 2.3.1 : Friday, 28 August 2015 08:03:05 UTC