Re: [w3ctag/design-reviews] Canvas Text Metrics for Editing, Art and Design (Issue #1095)

schenney-chromium left a comment (w3ctag/design-reviews#1095)

Ah, taking elements and rendering them in canvas. That's exactly what we're working on with [HTML-in-Canvas](https://github.com/WICG/html-in-canvas) in an effort to improve accessibility for content best representing by DOM. It raises it's own set of a11y concerns, but in general should make it easier for authors to match their canvas content with their fallback content as you suggest.

In this case we're building on existing canvas text features, and don't want to mess with the API too much due to existing web content.

My collaborator in this work, @fmalita, is looking into the functional questions you raised. I take the point about ligatures and writing modes.

For `getIndexFromOffset()` (Point 2), canvas has the notion of LTR and RTL but nothing beyond that. The assumption is that an author will use transforms to align text vertically. There is also the problem of mimicking  `sideways-*` which IIRC needs to rotate individual characters in some situations, which I think you would need this proposal to do correctly. Regardless, to get the correct position to use for `getIndexFromOffset` I believe an author would need to transform the point into the coordinate system of the text string to correctly compute the offset along the string's rendered orientation.

Ligature breaking is possible and I agree should happen, so we will define the correct behavior in any spec text and update the explainer if necessary. For italics and the like we would behave the same as the DOM `caretPositionFromPoint` method which does not take into account italics. The underlying implementation in browsers uses the editing code paths (also for selection) so the behavior would match what those systems do. In Chromium, at least, the selection rect does not cover italic characters in all cases.

The copying of `align` and `baseline` (Point 4) is done to simplify the rendering when measurement and creation of the glyph clusters is done in a different code location. That is, if you create in one function then pass around to another or store for later. It captures the alignment and baseline at measurement time so they can be re-applied at rendering time. I believe this came out of the [spec PR discussion](https://github.com/whatwg/html/pull/11000). Note Florin and myself have taken over this work from @AndresRPerez12.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1095#issuecomment-2984934509
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1095/2984934509@github.com>