Bug 75244 – Implement ruby-align

• Status: NEW
• Component: CSS

Overview:
When the CSS property "ruby-align: center" is set, glyphs in the base of a ruby element should be right next to each other, without any space between them. Currently, this is being rendered properly with *some* ruby elements, but not with others.

Steps to Reproduce:
Go to http://www.chinesetools.net/ruby/Mandarin-Expressions.html

Actual Results:
There is space between some of the Chinese characters in the bases of the ruby expressions, even though there are no spaces between those Chinese characters in the source code. E.g., in the expression "help | bāngzhù | 幫助", there is a space between "幫" and "助", even though there is no space between them in the source code.

Expected Results:
There should be no space between the Chinese characters in the bases of the ruby expressions when there are no spaces between those Chinese characters in the source code. E.g., in the expression "help | bāngzhù | 幫助", there should be no space between "幫" and "助", since there is no space between them in the source code.

Note that at http://www.w3.org/TR/css3-ruby/#rubyalign, the illustrations for "ruby-align: center" depict the glyphs in the bases of the ruby elements being directly adjacent to one another with no space between them beyond what normal font rendering requires.

Build & Platform:
Version 5.1.2 (6534.52.7, r103700) on Intel Mac OS X 10.6.8

I think the reason for this problem is that Webkit does not yet support the CSS3 ruby-align property.  They implemented ruby-align's default behaviour before they implemented ruby-align itself.

I'm not sure which version of Webkit this was introduced in, but I don't remember it being there a while ago.  It is present on 534.57.2 and 536.5.

One kludge I found is, if you put a CENTER or DIV tag inside the RB (i.e. <RB><CENTER>stuff</CENTER></RB>) then it will be centred.  Must be the actual tag though, not a CSS text style option.  (The tag is probably best added by browser-specific Javascript just in case.)  Problem with this is, in 534.5 (but not in 536.5) the CENTER or DIV tag also results in the entire ruby stack having an additional horizontal margin, which doesn't do word spacing any good; the only way to undo this seems to be to set a negative margin (about -1ex) on the RUBY tag (setting anything on the DIV won't work) and it is highly version specific so you'd have to check which other Webkit versions are affected and decide where to put your version thresholds or you'll end up with words overprinting each other on unaffected browsers. Also, in both 534.5 and 536.5, the presence of a CENTER tag results in a reduced vertical spacing between the RT and the RB, but this isn't so much of a problem if you use DIV instead of CENTER.

Or you could re-style RUBY using "display" CSS to display it as table-header-group and table-row-group like you have to do for browsers that don't support ruby at all.  However there are a number of other bugs you hit when you do that.  For example, if you have that sort of ruby inside a "text-align: center" passage, a line break will appear after every stack.

It helps a tiny bit to put U+200B (#8203) zero-width space either side of the Chinese characters in an RB.  The zero-width space is treated as an extra character by the spacing algorithm, which then at least puts SOME of the extra space between the characters and the U+200Bs, resulting in the characters not being spaced out quite so much. It's not a complete solution though, and you can add only two zero-width spaces (one each side); adding more does not help. Unless you separate them with real spaces, but then you run the risk of making the RB row too wide. Even just one U+200B each side may result in short words taking up a bit too much horizontal space on 534.57 which seems to want to put at least a minimum amount of space between each character, but 536.5 seems OK in this respect.

It sounds like what’s needed is for support to be implemented for "ruby-align", including "ruby-align: center", so that it just works without kludges and workarounds that don’t always work and that would require an inordinate amount of debugging and maintaining.

[fantasai]

rdar://problem/98330990

[fantasai]

*** Bug 115149 has been marked as a duplicate of this bug. ***