[Webkit-unassigned] [Bug 157629] Implement more of the canvas TextMetrics API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=157629

Justin Michaud <justin_michaud at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |justin_michaud at apple.com

--- Comment #4 from Justin Michaud <justin_michaud at apple.com> ---
https://github.com/whatwg/html/pull/3931 adds advances, and moves the baselines into a dictionary

https://github.com/whatwg/html/issues/3995 has some more discussion about Safari's existing implementation

https://github.com/whatwg/html/issues/4026 has some interesting discussion about a number of edge cases. 

This patch adds advances and moves the baselines. When multiple code points are shaped into one glyph, it outputs the same "advance" for both (note that "advances" in the spec are actually distances from the left of the text box to the left of the glyph). If one code point becomes multiple glyphs, it breaks completely. If a code point does not get shaped into a glyph, it will have the same "advance" as the previous character, but I think it will break if the first character in the text does not become a glyph. I am going to need some help to understand how implement these edge cases.

With this patch, it passes http://w3c-test.org/2dcontext/drawing-text-to-the-canvas/2d.text.measure.advances.html (although you need to run it locally. I think it has something to do with the fonts). This test isn't very thorough though.

Chromium has this feature behind a flag. To enable it, run 
```
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-blink-features=ExtendedTextMetrics
```

Note that Chromium's implementation is broken for rtl text. 

I have attached a manual test case to play around with. I also attached a screenshot of it in action ("Screenshot 1").

One of the advances is missing in this implementation compared to chrome, as seen in the image. I am not sure what the correct behavior is.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180913/5f512de3/attachment.html>