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

It seems to me that there are several separate sets of information that we can provide from fonts themselves and typographic layout results, each working towards satisfying different use cases.

The results can be broken into two sets - which I’m calling ink bounds and metrics. Both of these sets should be provided at multiple levels: element, line box or fragment, range (including narrowing down to single glyphs).

A. Ink bounds would give geometric information about what’s actually being drawn. If this is merely a rectangle, this could be used to draw adornments around content, including the square-root symbol use case Peter pointed out. If the ink geometry was described in more detail, it could be used for those cases *and* for initial-letter-wrap [1]. I don’t think the use cases for ink bounds really care what particular font is being used, just how the content is drawn.

B. Metrics would give more abstract lines that correspond to font data (baseline, ascent, etc.) but as they are actually rendered in a particular line box. This could be used for initial-letter alignment, baseline grids, and any alignment to typographic measures that should be stable over content changes. In these use cases it’s the rendered measure that’s the target for alignment, so again I’m not sure whether the particular font (and it’s underlying data) is relevant.

I’m not sure whether character advances fit best into A or B - perhaps it’s both.

Then there’s the font data itself. In order to make use of font data directly, the used font (and possibly the first available font) would need to be provided at each level (element, fragment, range).

C. Font data has a few use cases I’ve heard identified. What glyph ranges are available could allow more control over font selection. Showing what OT features are supported could allow fallback transformations (small caps to actual caps or title caps as needed). I’m not sure that exposing font baselines, etc. at this level makes sense as that raw font data would usually need to be translated into A and B above which can result in a lot of reverse-engineering of particular UA code.

Does this classification make sense? Does anyone have additional use cases and/or requirements for any of these categories?

Thanks,

Alan

[1] https://drafts.csswg.org/css-inline/#initial-letter-wrapping

Received on Wednesday, 26 August 2015 11:03:11 UTC