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

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, 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.

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 Wednesday, 29 July 2015 01:03:15 UTC