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: Thu, 27 Aug 2015 10:54:23 +0000
To: "public-houdini@w3.org" <public-houdini@w3.org>
CC: John Daggett <jdaggett@mozilla.com>
Message-ID: <9FAB10EE-2E3D-4ECF-BD97-1B05E14BEAD8@adobe.com>
On 8/27/15, 9:28 AM, "John Daggett" <jdaggett@mozilla.com> 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. 

>Instead, I think you need to focus first on what the core primitives are in text rendering and then expose some of these as primitive services so that script can be used to provide the higher-level functionality you're dreaming about.
>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.


Received on Thursday, 27 August 2015 10:54:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 August 2015 10:54:58 UTC