Re: [css-priorities] Updated document on CSS priorities

Hi,

I've had an action item for a while to write something about use cases for
font metrics APIs from a math polyfilling perspective. I finally had some
some spare time and this thread seemed to fit.

Thoughts are below. I'm inexperienced at this and would be glad to get some
feedback to work more on it.

Best,
Peter.

For polyfilling complex layout such as mathematical or chemical equations,
the dimensions of glyph bounding boxes are necessary to calculate correct
placement of, e.g., surds, multiscripts, reaction arrows etc. Most
JavaScript libraries for math layout generate the relevant data for
specific fonts during development and then have to load this data (along
with webfonts if necessary).

An alternative approach (not used in math rendering) would be to use
opentype.js <https://nodebox.github.io/opentype.js/> to load webfonts and
extract the font metrics data on the fly; this does not work with local
fonts however.

Existing specs like canvas TextMetrics
<https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics> (seem
to?) only provide font-wide bounding box information, not character
specific information and would furthermore require the creation of canvas
elements to get such data; cf. also fontmetrics.js
<https://pomax.github.io/fontmetrics.js/> based on opentype.js.
Additionally, hacks using canvas rendering and pixel scanning can provide
some (but not all) information, cf. here
<https://mudcu.be/journal/2011/01/html5-typographic-metrics/>.

All of these approaches (pre-generated font data, opentype.js, canvas with
pixel scanning) are not very efficient and have significant drawbacks.
However, they demonstrate the need for a font metrics API that can provide
access to lower level font information. Such an API would make the desired
layout work easier and more performant; it would furthermore allow such
tools to support arbitrary (web or local) fonts.

On Tue, Jul 7, 2015 at 6:36 PM, Dave Cramer <dauwhe@gmail.com> wrote:

> On Tue, Jul 7, 2015 at 1:10 PM, Ivan Herman <ivan@w3.org> wrote:
>
> For the first category (and maybe even the second) there may be one more
>> column: whether polyfills exist for the specification, ie, if it is not
>> implemented by a browser, but if a reading system accepts polyfills, can
>> that be used. E.g., I have seen somewhere a polyfill for hyphenation to
>> have it working in chrome (I have not tested it, though).
>>
>
> I've added such a column, and started populating it. There's a yes or no
> (admittedly subjective!) in the table, which then links to a note on the
> available (or unavailable) polyfills.  Let the arguing commence!
>
> Dave
>