Bug 65082 – Presentational forms for full-width punctuation unused and erroneously rendered in vertical writing mode

• Component: Text
• Status: UNCONFIRMED

[Xiaodi Wu]

Created attachment 101829 [details]
HTML file demonstrating bug

A. When -webkit-writing-mode is set to vertical-rl, some punctuation marks such as parentheses, etc., are correctly displayed using the vertical presentation form without changes in markup (i.e. the source contains a horizontal full-width open parenthesis and it is correctly displayed as a vertical full-width open parenthesis), but other punctuation marks such as periods, commas, colons, etc. are not--even when the font used contains glyphs for the corresponding vertical presentation form.

B. Furthermore, when the markup is manually altered so that these full-width punctuation marks are replaced by their vertical counterparts, these characters are not recognized as vertical forms and are incorrectly rotated 90 degrees when -webkit-text-orientation is left at its default value (vertical-right).

Attached is an HTML file demonstrating these two bugs (surrounded by <article> tags styled to be outlined in red (for bug A) and yellow (for bug B)), along with the workarounds to produce the expected rendering (green border; expected rendering should be identical for both bugs).

[Xiaodi Wu]

Created attachment 101838 [details]
HTML file demonstrating bug (corrected for errant character)

[Koji Ishii]

You didn't specify the platform you're using, but the file looks good on Mac.

If you're using Windows, this is probably dup of bug 48459. There are other bugs for other platforms; bug 50619 for GTK and bug 51584 for Qt.

[Xiaodi Wu]

(In reply to comment #2)
> You didn't specify the platform you're using, but the file looks good on Mac.
> 
> If you're using Windows, this is probably dup of bug 48459. There are other bugs for other platforms; bug 50619 for GTK and bug 51584 for Qt.

Nope, using a Mac. I still see the same problem in Safari 5.1.3 on Lion as well as in the WebKit nightly build from yesterday (r107978). In each case the expected punctuation rendering should be identical to the leftmost version in green, but as you can see with the colon, for example, it's either using the wrong form, or when the correct form is explicitly called for, it's incorrectly rotated.

[Xiaodi Wu]

Created attachment 127634 [details]
HTML example as rendered in Safari 5.1.3 (OS X Lion)

[Xiaodi Wu]

Created attachment 127635 [details]
HTML example as rendered in WebKit r107978 (OS X Lion)

[Xiaodi Wu]

Created attachment 127640 [details]
Annotation of screen shot to explain bug

[Koji Ishii]

Ah, okay, thank you, setting Platform field helps me to see what the problem is.

Now I opened the file on Mac OS X 10.6, and I understand punctuation on the right most example is incorrect.

I then opened up Inspector and unchecked
body {
  font: 19px/27px STKaiti, SimKai, serif;
}
and the right most example becomes in good shape.

That means, I suspect the problem is not in webkit, but in one of these fonts not having the correct vertical glyphs.

In short term, you should avoid using these fonts in vertical flow.

In long run, you should contact font vendors to fix the problem. Are they Mac OS X standard fonts? If so, it'd be Apple.

[Xiaodi Wu]

That's interesting. What is the default font you have displayed when you disable the CSS? I still have the problem when I uncheck that rule in the Inspector. I can also tell you that these fonts do have the correct vertical glyphs, as that's what's displayed in the middle and leftmost cases when I manually put them into the markup (it's not using a fallback font). Unfortunately, WebKit doesn't recognize these glyphs as vertical presentation forms of full-width punctuation even when I manually insert them, as you can see in the middle case, and rotates them 90 degrees as though they're Roman letters.


(In reply to comment #7)
> Ah, okay, thank you, setting Platform field helps me to see what the problem is.
> 
> Now I opened the file on Mac OS X 10.6, and I understand punctuation on the right most example is incorrect.
> 
> I then opened up Inspector and unchecked
> body {
>   font: 19px/27px STKaiti, SimKai, serif;
> }
> and the right most example becomes in good shape.
> 
> That means, I suspect the problem is not in webkit, but in one of these fonts not having the correct vertical glyphs.
> 
> In short term, you should avoid using these fonts in vertical flow.
> 
> In long run, you should contact font vendors to fix the problem. Are they Mac OS X standard fonts? If so, it'd be Apple.

[Koji Ishii]

Inspector allows you to edit, so you could try each font at:
http://www.yale.edu/chinesemac/pages/fonts.html#Apple

As far as I quickly checked on Mac OS X 10.6, bad ones:
Heiti TC
Heiti SC
Hei
Kai

Good ones:
Hiragino Sans GB
Song
Fang Song
Beijing
Lihei Pro
BiauKai
Apple LiGothic

When you say "manually entered", I guess you mean by using Unicode vertical presentations code points. They don't work very well.

Right now, as far as I understand, fonts need to support glyph substitution feature called 'vert' or 'vrt2' to work in Mac webkit. I guess they don't work well in TextEdit either.

I'm not Apple guy nor webkit guy, so I'm not in a position to talk if webkit is going to support fonts without 'vert' nor 'vrt2'. You may want to wait for other people's comment, or contact Apple, if you want to use these fonts.

[Xiaodi Wu]

That's interesting. Of these fonts that seem OK, all but one (Hiragino Sans GB) are acceptable only because the full-width punctuation marks are writing-direction-agnostic (you'll notice that in horizontal mode the glyphs are identical. In that sense, I guess, the rightmost case reduces to a font issue. Nothing to be done in WebKit I suppose.

That said, the middle case, with what I called (clumsily) manually entered glyphs--which is, yes, using Unicode vertical presentation forms code points--is still a bug. WebKit recognizes the vertical quotation marks inserted using these code points and correctly leaves them unrotated, but treats the commas, periods, and colons inserted using these code points differently and rotates them.