Canvas fillText is incorrectly affected by CSS unicode-bidi property
Reported by
jfkth...@gmail.com,
Jan 2 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0 Steps to reproduce the problem: Load the testcase. Observe the Arabic text within the sample lines. What is the expected behavior? The Arabic text should appear the same on both lines 1 and 2 (i.e. line 2 should be unaffected by setting the unicode-bidi property); only line 3 should have reversed Arabic text. What went wrong? In Chrome, the Arabic is reversed (forced to LTR directionality) on line 2. (Compare Firefox, where lines 1 and 2 are the same, and only line 3 is different. This matches what the HTML spec requires.) Did this work before? N/A Does this work in other browsers? Yes Chrome version: Version 55.0.2883.95 (64-bit) Channel: stable OS Version: OS X 10.12 Flash Version: Shockwave Flash 23.0 r0 AFAICS, the HTML spec does *not* allow canvas text to take account of the unicode-bidi:bidi-override property. See step 5 of the Text Preparation Algorithm, which is where the text is converted from a string of Unicode characters to an array of glyphs in an inline-box: > Form a hypothetical infinitely-wide CSS line box containing a single inline box > containing the text _text_, with all the properties at their initial values except > the 'font' property of the inline box set to _font_, the 'direction' property of the > inline box set to _direction_, and the 'white-space' property set to 'pre'.[1] So unicode-bidi should retain its initial value of 'normal' for the line of text rendered by canvas. (A canvas-based site that wants forced-LTR behavior can achieve it, I think, by filtering out any Unicode bidi overrides within the text, and then prefixing it with an explicit Left-to-right Override character (U+202d).) [1] https://html.spec.whatwg.org/multipage/scripting.html#text-preparation-algorithm
,
Jan 17 2017
junov@, could you or someone from the paint team take a look at this one, please?
,
Jan 17 2017
,
Jan 17 2017
Unless I am mistaken, Chrome's behavior is correct. In the excerpt of the spec that is quoted in the description, we need a bit more context: The previopus step (step 4 of the text preparation algorithm) explains how the value the direction variable is set. This is a variable that is local to the text preparation algorithm. It does not refer to the direction attribute of the 2d rendering context (a bit confusing IMHO). Step 4 basically says that when the value of the direction *attribute* is neither "ltr" or "rtl", then the direction *variable* is set to the directionality of the canvas element or of the Document (whichever of the two is the font style source for the context) The attached example does not touch the direction attribute of the 2d context. Its default value is "inherrit". Which means that the directionality of the canvas element gets applied. Closing issue. To be re-open if this interpretation of the spec is incorrect.
,
Jan 28 2017
The issue here is not about the element's directionality, but whether the Unicode directionality of the characters in the text should be overridden (as would happen for HTML text with this CSS property). And the answer must be "no" because for the hypothetical infinitely-wide CSS line box we create to lay out the glyphs, we're told to use "all the properties at their initial values" except for a few specific properties, NOT including unicode-bidi.
What the testcase demonstrates is that Blink is forcing LTR character directionality onto the Arabic text when unicode-bidi:bidi-override is specified in the canvas element's style. And that is wrong because in the text preparation algorithm, unicode-bidi should remain at its initial ('normal') value.
So I think this should be re-opened.
,
Jan 31 2017
,
Feb 15 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 15 2018
,
Feb 21 2018
+fserb, because it might be relevant to your interests
,
Jul 25
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by kkaluri@chromium.org
, Jan 3 2017Labels: M-57 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
400 KB
400 KB View Download