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

Alan Stearns 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.

Adding API's to access "useful bits of information" are useless unless
you understand how they fit into the larger model of text layout and
rendering. You first need to sketch out the heirarchy of primitives that
exist in common practice, then decide how to expose parts in ways that
are useful without burdening implementations with artificial models of
how things work.

For example, the "font metrics" API you're suggesting is a mishmash of
font metrics and line metrics. And you should immediately give up the
notion that this API will be of *any* use for mathemetical layout, which
requires much more detailed information about both line metrics and
metrics related to individual glyphs.

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

You need to describe the primitives first and *then* decide which to
expose and how. Having API's that expose a mixture of results from
different phases are harmful in my mind. Likewise for API's that are
some amalgamation of different underlying data (e.g. the concept of
caps-height for a linebox).

Consider an old "useful" feature of SVG, the ability to position
characters along a line:

<text x="300 350 400 450 500 550 600 650" y="100">fidelity</text>

The list of x-coordinates indicates the placement of glyphs along a
line. However, implicit here is the simplification that one character
becomes one glyph. Because the model here doesn't distinguish between
the two, this exposes a really poor model to the author, one that runs
into problems when that simplification doesn't hold, such as in the case
of ligatures. The model here shouldn't be exposing glyph operations that
operate on characters.

The A/B/C classification you made in your original message is mixing
data from different primitives. I think you need to describe the
primitives first, then see which use cases are satisfied by exposing a
particular set of primitives.

Emil Eklund wrote:

> Agreed, the majority of use cases we've heard about would be satisfied
> by exposing an API for accessing the result of text
> analysis/segmentation, shaping, and line placement. With the ability
> to customize placement.

The resulting output of these steps is a set of glyphs with positions.
For this to be useful you'll probably need some concept of a glyph and
some idea of how to tie this back to the original text content. And
customizing placement means have a model for positioning lineboxs and
glyphs within lineboxes.

The primitives need to be flushed out first for this to make any sense.


​