WebKit doesn't honor MVO and SVO properties
https://bugs.webkit.org/show_bug.cgi?id=95743
Summary WebKit doesn't honor MVO and SVO properties
Johnny(Jianning) Ding
Reported 2012-09-04 06:41:59 PDT
In Unicode spec, the Stacked Vertical Orientation (short name SVO) property is intended to be used for vertical lines in those parts of the world where characters are mostly upright. The Mixed Vertical Orientation (short name MVO) property is intended to be used for vertical lines in East Asia, and more specifically in Japan, China and Korea. (See http://unicode.org/reports/tr50/) In the section 5.1.1. Vertical Orientations, it says: If the orientation value is ‘R’ then the simple value is ‘R’. If the orientation value is ‘U’, ‘T’, ‘Tu’, or ‘Tr’ then the simple value is ‘U’. The UA must render a character upright if the value is ‘U’, or sideways (90° clockwise from horizontal) if ‘R’. However seems current webkit implementation doesn't completely honor MVO and SVO properties. For example, see the following HTML code (You can also try the attached test case) <span style="-webkit-writing-mode:vertical-lr;">①汉②字③</span> The default text-orientation is mixed-right, which applies MVO rule, that means all five characters (two CJK Unified Ideographs and 3 circled digits) inside <span> should be all upright. But in current webkit implementation, the 3 circled digits are showed with sideways orientation.
Attachments
Johnny(Jianning) Ding
Comment 1 2012-09-04 06:43:30 PDT
Forgot to mention the section 5.1.1. Vertical Orientations is a part of CSS Writing Modes Module Level 3 Draft.(Please see http://dev.w3.org/csswg/css3-writing-modes/#text-orientation)
Glenn Adams
Comment 2 2012-09-04 18:57:48 PDT
(In reply to comment #1) > Forgot to mention the section 5.1.1. Vertical Orientations is a part of CSS Writing Modes Module Level 3 Draft.(Please see http://dev.w3.org/csswg/css3-writing-modes/#text-orientation) Yes, please refer to the CSS3 WM spec for any action on this bug. There has been considerable discussion of this matter in the CSS WG in recent months. See the detailed minutes from the recent F2F [1]. Also, keep in mind that UTR50 is in flux, so any early action addressing this bug will need to track the status of these discussions and make changes accordingly. [1] http://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html
Johnny(Jianning) Ding
Comment 3 2012-09-05 00:05:55 PDT
(In reply to comment #2) > Yes, please refer to the CSS3 WM spec for any action on this bug. There has been considerable discussion of this matter in the CSS WG in recent months. See the detailed minutes from the recent F2F [1]. Also, keep in mind that UTR50 is in flux, so any early action addressing this bug will need to track the status of these discussions and make changes accordingly. > > [1] http://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html Thanks for quick and detailed reply, Glenn. Yes, I understand that it will take times to stabilize the specs (both CSS3 WM and UTR50) before having final implementation among WebKit and other layout engines. This bug is just for a track record and I think current workaround to let circled digits show in right orientation in WebKit is to manually specify the -webkit-text-orientation for the characters we want to change.
Koji Ishii
Comment 4 2013-01-16 21:52:54 PST
SVO is now gone, and CSS WM spec uses forced-upright (all glyphs rendered upright regardless it's right to do so or not) for upright now. For MVO, current UTR#50 proposed draft 6 http://www.unicode.org/reports/tr50/tr50-6.html is referred from CSS WM spec. On Unicode site, there're proposed draft 7 and 8, but data do not change since 6. Unicode expects it to change in future drafts, but that will be only data change, and there are good amount of existing contents that assume proposed draft 6. Some guidelines from Japan also recommends proposed draft 6 for now. I think it's good to go to implement proposed draft #6, and then update the table when the UTR#50 is finalized.
Radar WebKit Bug Importer
Comment 5 2022-07-13 10:57:32 PDT
Note You need to log in before you can comment on or make changes to this bug.