Re: [font-metrics-api] font data versus typographic layout results

Apologies for this self-response, but I wanted to bring up a couple of 
things I assumed people would call me out on.

On 7/28/15, 6:02 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>Hey all,
>
>I initially thought that exposing raw font data would be the right first
>step for finding a way to correctly polyfill initial-letter, line grid,
>etc. Conversations I’ve had since the last Houdini meeting have moved me
>towards John Daggett’s point of view, that exposing the typographic
>*results* of line boxes is a better stepping-stone. Getting those results
>and making small changes is better than trying to reverse-engineer what
>the browser is doing with the raw font data.
>
>The box tree API currently talks about DeadFragmentInformation

I’m assuming DeadFragmentInformation is a placeholder name. I went with 
DeadFontMetrics just for consistency. My understanding is that these 
interfaces will only provide read-only snapshots of layout results, so we 
need a name to describe these qualities. I’m hoping we come up with 
something better than Dead*

>, which
>gives you a basic geometry result. My current thinking is that there
>should be a way to get more fine-grained typographic information within
>that basic geometry. It might look like:
>
>interface DeadFontMetrics {
> readonly attribute double baseline;
> readonly attribute double alphabeticBaseline;
> readonly attribute double ideographicBaseline;
> readonly attribute double ascent;
> readonly attribute double descent;
> readonly attribute double xHeight;
> readonly attribute double capHeight;
>}
>
>
>partial interface DeadFragmentInformation {
> Promise<DeadFontMetrics> getFontMetrics();
>};
>
>
>Where the DeadFontMetrics attributes give you the relevant typographic
>position of the first in-flow line box in pixels from the top of the
>fragment.

I don’t know if it makes any sense to add a promise to a Dead* interface. 
Perhaps DeadFontMetrics would merely be a read-only attribute on a 
DeadFragmentInformation. I was thinking that there might be a performance 
benefit to only returning basic geometry for a fragment, with more detail 
available through the additional promise. But that assumes some storage of 
information where it might be better just to return everything once and 
throw it away. Perhaps that storage is already implied by the fragment 
tree traversal methods.


>
>An interesting idea is that we could work on the box tree and font metrics
>in parallel by adding getFontMetrics() to Element as well, which would
>give you the same typographic positions of the first in-flow line box from
>the element’s top. This might be sufficient to polyfill initial-letter and
>flexbox’s align-items:baseline. Something more complicated like line-grid
>would need to wait for more of the box tree to be exposed.
>
>Thanks,
>
>Alan
>
>

Received on Monday, 3 August 2015 18:32:31 UTC