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

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

From: Alan Stearns <stearns@adobe.com>
Date: Fri, 14 Aug 2015 14:18:29 +0000
To: Chris Lilley <chris@w3.org>, "public-houdini@w3.org" <public-houdini@w3.org>
CC: John Daggett <jdaggett@mozilla.com>
Message-ID: <D1F33DE9.2C137%stearns@adobe.com>
On 8/14/15, 2:48 AM, "Chris Lilley" <chris@w3.org> wrote:

>Hello Alan,
>(apologies for late reply, I have been on travel).
>Wednesday, July 29, 2015, 3:02:42 AM, you 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.
>Better for all uses of the font metrics API, or better for the specific
>ones that involve constructing new line boxes?

Definitely not all uses, but it’s better for the use cases I’ve been
considering. They include aligning content using these results (initial
letter, line grid, align-items:baseline for flex items), drawing
adornments based on glyph positions, and eventually math layout (with
extensions for finer-grained access to more results).

>It doesn't seem to me that forcing users to indirectly intuit font
>metrics based on effect on line boxes is a win, in general.

I think providing actual font metrics could also be useful, but for the
uses above the actual font metrics are an indirect and incomplete way to
approach the solution.
> It seems
>that the developer would end up making a bunch of temporary elements
>and fiddle with them to get enough data that they would have preferred
>to access directly in most cases.

I assume developers would take their actual elements, lay them out and
find the results, then make adjustments to achieve the desired effect.

>On the other hand, maybe people more familiar with CSS would prefer to
>get the data in terms of things they are familiar with (whilst
>typographers would, equally, prefer the font metrics with a close 1:1
>relationship to the underlying OpenType data).
>But I haven't heard John's arguments. This would be a very good topic
>for the Houdini f2f, with a whiteboard.
>>  Getting those results
>> and making small changes is better than trying to reverse-engineer what
>> the browser is doing with the raw font data.
>If the developer is indeed recalculating something the browser has
>already done, I agree. But I don't see an argument for making this the
>sole method. If people want detailed linebox information - which I am
>sure they will - we should provide that. And if people want font
>metric information, we should provide that. It seems likely that any
>typographic polyfill would want access to both types of information.

I agree we should pursue both, but I think they have separate
applications. An initial letter polyfill really only needs to adjust
layout results and doesn’t need to have access to OpenType data. When we
looked at using actual OpenType data in our script we found it wasn’t
sufficient because different browsers used the OpenType data in slightly
different ways, so we still had to measure the layout result.

But some polyfills (like one that could suppress small cap synthesis)
would want to look into the actual font without needing any layout results.

>It also seems that metrics are just one set of properties a Font
>object might expose, and other non-metric information could also be of
>interest. Indeed there was an example on this week's call, how can you
>know if the current font supports true (non-synthesized) small caps?
>Or in general, what features does the current font support?
>For those situations where a more complex conditional set of property
>assignments are desired, which cannot be readily achieved with just
>fallback via the cascade, giving stylesheet authors an API to directly
>query the font capabilities and execute logic depending on that
>information seems like a key extensibility win.
>In my mind, font metrics is just the first step here towards a richer
>font-querying API.
>> 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;
>> }
>What would that expose, for a fragment where different characters in
>the text content had different metrics? It seems that the metrics info
>in OpenType GPOS (as opposed to the simpler OS2 table info for
>TrueType) can be quite complex, with the BASE table allowing
>per-script, per-language and even per-character baseline metrics [1].

Both elements and fragments can have a mix of content within them, so the
metrics would need to be a well-defined useful sample of the typographic
layout results. Defining it as returning the results of the first in-flow
line box is a start. We’d probably need to say that we’re measuring the
result for the first glyph within that line box as well.

We talked in Sydney of creating a new DeadRange API, which I assume would
also return some DeadFontMetrics based on the same well-defined useful
sampling. So if per-character metrics were needed, you would set up some
ranges to get finer-grained typographic layout results. If we added
information about advances or widths at this level, my hope is we’d get
closer to what math layout needs.

>> 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.
>[1] http://www.microsoft.com/typography/otspec/base.htm

>Best regards,
> Chris  Lilley
> Technical Director, W3C Interaction Domain

Received on Friday, 14 August 2015 14:19:04 UTC

This archive was generated by hypermail 2.3.1 : Friday, 14 August 2015 14:19:06 UTC