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

Re: [font-metrics-api] Zooming out on font metrics

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


John Daggett
Received on Thursday, 27 August 2015 07:28:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 August 2015 07:28:55 UTC