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 05:51:21 +0000
To: John Daggett <jdaggett@mozilla.com>
CC: "public-houdini@w3.org" <public-houdini@w3.org>
Message-ID: <48322012-07C7-4CCA-B7DB-492015617F4E@adobe.com>
On 8/28/15, 3:36 AM, "John Daggett" <jdaggett@mozilla.com> wrote:

>Alan Stearns wrote:
>> >These proposals feel very SVG 1.2 Full-esque in their expansiveness.
>> >Effectively you're talking about creating some sort of intermediate
>> >object model for exposing the output of font selection, text shaping,
>> >and line breaking. Since it's hard to get this right
>> > and match all possible use cases, I think this is a poor approach.
>> I agree that coming up with a complete model that matches all possible
>> use cases would be hard, so I’m explicitly NOT looking for that right
>> now. I’m much more interested in adding useful bits of information
>> based on actually identified use cases. This should be done keeping
>> future extensions in mind, so I’m happy to discuss how these bits of
>> information are arrived at.
>Adding API's to access "useful bits of information" are useless unless
>you understand how they fit into the larger model of text layout and
>rendering. You first need to sketch out the heirarchy of primitives that
>exist in common practice, then decide how to expose parts in ways that
>are useful without burdening implementations with artificial models of
>how things work.
>For example, the "font metrics" API you're suggesting is a mishmash of
>font metrics and line metrics.

I don’t think anything I’ve proposed so far is a mishmash (see below), but I appreciate your vigilance to ensure we don’t arrive at one.

> And you should immediately give up the
>notion that this API will be of *any* use for mathemetical layout, which
>requires much more detailed information about both line metrics and
>metrics related to individual glyphs.

I’m assuming that we do find a way of addressing individual glyphs, so I’m not giving up on anything yet.

>> >Primitives needed for displaying text:
>> >
>> >  - text analysis and segmentation: Unicode operations on text
>> >  - font selection: mapping of text to set of <font, text subrange>'s
>> >  - text shaping: map <font, text subrange> ==> <font, glyph id's, positions>
>> >  - font data access: <font, table id> ==> binary table blob
>> >  - line placement: <font, glyph ids, positions> ==> set of lineboxes with adjusted positions
>> >  - path extraction: glyph ids ==> path data
>> >
>> >Breaking things down like this gives script an opportunity to futz
>> >with things along the way, doing line breaking a different way for
>> >example without having to implement text shaping in script. Direct
>> >access to font data means folks with knowledge of a given
>> > facet of the problem (e.g. OpenType layout, mathematical layout) can
>> > provide substitute solutions for any particular stage.
>> Having all of this information available and hooks provided for
>> substitute solutions would be awesome. But even with all of this in
>> place, I still think access to the results of these inputs (however
>> they’re futzed with) will be useful for scripts that merely want to
>> align baselines or draw something around the rendered content.
>You need to describe the primitives first and *then* decide which to
>expose and how. Having API's that expose a mixture of results from
>different phases are harmful in my mind. Likewise for API's that are
>some amalgamation of different underlying data (e.g. the concept of
>caps-height for a linebox).

I probably have not emphasized one particular point enough (I see I’ve only mentioned it in passing in a reply to Chris). I do want to “roll up” information from primitives we do not yet define to larger structures. Right now we have elements. We have been talking about defining deadfragments and deadranges. We might eventually get to exposing glyphs. But until we do and even after we do I still think we will want to provide glyph information at each level, properly and consistently defined.

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.



Received on Friday, 28 August 2015 05:51:53 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 August 2015 05:51:54 UTC