[font-metrics-api] Clarify Canvas Glyph Drawing Use Case

[sebmarkbage]

I noticed that the Font Metrics API mentions custom routines to draw on canvas as low-priority.

…people want direct access to font data to enable their own text layout routines to draw on a canvas or invoke in a custom paint routine. That's a fine use case, but I think it's probably a lower priority than allowing measurement of text laid out by the browser.

A) Does that mean that all custom layout of glyphs onto a canvas is not a prioritized use case?

or

B) Does that mean that just custom rasterization of the glyph paths/bitmaps is not a prioritized use case?

I would agree that access to individual glyph path data (B) could be deferred to the future.

However, I think it is a very important use case to be able to measure advance/offset/bounds for a run without first putting it into the DOM (A).

It is also important to be able to draw each glyph individually onto a canvas. E.g. a text shaping API could provide Glyph IDs and those IDs could be used to draw individual glyphs to a canvas. Since fillText doesn’t allow you to target an individual glyph for certain cases.

This unlocks use cases like drawing text along a custom path algorithm or complex text layouts for rich data visualizations. It allows rendering complex text layouts to be used by WebGL shaders for further processing. It allows drawing of UIs at high fidelity onto VR surfaces with distance map textured glyphs.

Many parts of CSS Houdini is about making integration with the existing platform neat. However, in practice some of the use cases can be worked around in user space, and in React we do. We can do multiple passes for integrating custom layout algorithms, we can use workers or cooperative scheduling to offload work from the main thread, and even line-breaks and bidi is possible to get right in user space.

Text shaping is not possible to get right in user space. You need access to the closed source platform specific shaping algorithms to get things like Core Text’s latest emojis right. You also need access to the platform’s font selection algorithm to comply with user internationalization requirements. Finally you need access to a large set of international font files which would be prohibitively large to download and cache if you do it in user space.

That’s why I think that this use case is important and should be prioritized. It unlocks capabilities that we can’t do any other way on the Web.

[kevinbarabash]

However, I think it is a very important use case to be able to measure advance/offset/bounds for a run without first putting it into the DOM (A).

I can't upvote this enough. https://github.com/khan/KaTeX makes extensive use of font metrics in order to layout math on the web. Unfortunately, we have to ship metrics for all of the characters we use which is a lot.

Also, one of the ways that KaTeX maintains its speed is by not measuring the DOM. If we had to do this, we'd end up having multiple cycles of measuring and updating the DOM which although it might improve the quality of the layout a bit, it would negatively impact the speed of the rendering significantly.

One of the things we've struggled with has been handling non-latin languages. There's a lot of languages and some of those languages have lots of characters. Right now we support some of those languages by providing approximate metrics for glyphs, but that reduces the quality.

Also, many users would look to be able to use different fonts such as STIX instead of Computer Modern. It would be nice to be able to just change the @font-face definition in the CSS and not have to run some script to extract font metrics from those font files.