advance is measured as distance up to left side of character
r12a opened this issue · comments
https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-advances
advances attribute
Returns a frozen array containing advances for each character in the measured text\. Each advance is measured as the distance from the beginning of the string \(starting at 0\) up to the left side of the character\.
Does that work the same way for text in right-to-left scripts, such as Arabic, Hebrew, etc?
Oh, and also how does it work for vertically set text?
cc @whatwg/canvas
On RTL text, the advances will be decreasing and always pointing to the left side of the character, the same as on LTR.
I'm not sure we have vertically set text on canvas, nor I really understand how kerning works on these situations (do we have vertical kerning?)
There's commented out methods for vertical text on canvas, so I guess that's not supported yet.
Should we add a clarifying note that it's from the left side even in RTL text? (Assuming that's the right metric.)
I apologise that i don't know much about canvas, or what the offset information will be used for,, but i have a couple of additional questions.
I guess that it is important to decide where is the position of the 'start of the string', in order to know whether to use positive or negative advances. Presumably that is indicated by the base direction in force for the context in which the string is being used? How will that be detected?
I'm also guessing that in bidi text such as
the offsets will still be negative even for the LTR text, based on the fact that the string is in an overall RTL base direction?
Thank you @annevk for adding a link, I wasn't aware this issue was already raised.
In #4026, @litherum and I agree that this should be in the visual order, and that advances are always from left to right (though there are cases where they are negative, such as combining marks.) It makes, however, knowing the advance of, say the 3rd character in the source text harder, because index of advances no longer matches to the index of the source text.
At this point, I don't know how to solve it, nor whether it is needed to be solved. I hope we can find solution if we learn the needs better, so I'm leaning to take the visual order for now, and keep listening to web authors what they want in addition. Opinion on this point is greatly appreciated.
What happens if multiple code points get rendered as a single glyph? Would a web developer need to know that too? If so, it seems this API is broken and would need to return something more informative.
Per #4026 (comment) by @jfkthame this is indeed fundamentally broken. @fserb I think the best way forward is to remove this feature for now.
Commenting on the other bug.