- From: John Daggett <jdaggett@mozilla.com>
- Date: Thu, 27 Aug 2015 16:28:26 +0900
- To: Alan Stearns <stearns@adobe.com>
- Cc: "public-houdini@w3.org" <public-houdini@w3.org>
- Message-ID: <CALYZoVPi1TKTSUFP-AiTNkVzgs6Dveuu==KPsMvKe42dmTDdYA@mail.gmail.com>
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. 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. Cheers, John Daggett
Received on Thursday, 27 August 2015 07:28:54 UTC