NEW 275197
Certain characters are not correctly rotated when using vertical writing mode 
https://bugs.webkit.org/show_bug.cgi?id=275197
Summary Certain characters are not correctly rotated when using vertical writing mode
Xidorn Quan
Reported 2024-06-05 22:46:25 PDT
Created attachment 471601 [details] font with the issue I have the following HTML: ``` <!DOCTYPE html> <html lang="ja"> <meta charset="UTF-8"> <style> @font-face { src: url('a.woff2'); font-family: a; } </style> <p style="writing-mode: vertical-rl; font-family: a">シート</p> ``` with the attached font. When looking in Safari, the "ー" character is not correctly rotated as expected. It works as expected in both Firefox and Chrome.
Attachments
font with the issue (4.24 MB, font/woff)
2024-06-05 22:46 PDT, Xidorn Quan 		no flags
Details
Comparison between browsers (46.44 KB, image/png)
2024-06-05 22:50 PDT, Xidorn Quan 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Xidorn Quan
Comment 1 2024-06-05 22:50:56 PDT
Created attachment 471602 [details] Comparison between browsers In the attached screenshot, from left to right: Firefox, Chrome, Safari It can be seen that only Safari treat it differently, and the behavior from Firefox and Chrome is expected.
Xidorn Quan
Comment 2 2024-06-05 22:54:35 PDT
From a read of CSS Writing Modes spec, it seems that > the UA must determine the orientation of each typographic character unit by its Vertical_Orientation property: typesetting it upright if its orientation property is U, Tu, or Tr; or typesetting it sideways (90° clockwise from horizontal) if its orientation property is R. and the character in question "ー" has Tr, so it does feel that WebKit is not doing it wrong. However, UAX #50 says > Tr: Same as Tu except that, as a fallback, the character can be displayed with the code chart glyph rotated 90 degrees clockwise. and Tu is: > Characters which are not just upright or sideways, but generally require a different glyph than in the code charts when used in vertical texts. In addition, as a fallback, the character can be displayed with the code chart glyph upright. so I suppose the CSS spec is talking about when such different glyph exists, one should render that upright. But when such glyph doesn't exist in the font (as likely this case), browser should probably rotate as if it's an R character.
Karl Dubost
Comment 3 2024-06-06 22:14:50 PDT
So I confirmed in Japanese, this is expected to be written: シ | <- using a pipe here instead of U+30FC to show the way it should look like. ト
Radar WebKit Bug Importer
Comment 4 2024-06-06 22:15:16 PDT
<rdar://problem/129381640>
Xidorn Quan
Comment 5 2024-06-07 06:54:12 PDT
FWIW, what Firefox does is that, for Tr characters, it checks whether the font has 'vert' feature, and whether that feature applies to the character in the current script. If not, it treats the character as R, otherwise keep it upright. I think this is a more sensible algorithm for handling this kind of cases. It's unclear to me, though, whether such algorithm should be documented into CSS Writing Modes spec.
Note You need to log in before you can comment on or make changes to this bug.