W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > July to September 2010

Thoughts on ruby

From: Richard Ishida <ishida@w3.org>
Date: Fri, 24 Sep 2010 14:26:02 +0100
To: <public-i18n-cjk@w3.org>
Cc: <eb2m-mrt@asahi-net.or.jp>
Message-ID: <051201cb5bec$09043030$1b0c9090$@org>
Here are some thoughts on ruby that I hope will help discussions. I'm
frustrated that I haven't had the time to work through these issues in depth
with examples and tests, so I'm open to counter-arguments, but I hope that
these pointers may provide useful input for discussion nonetheless.

[1] I've heard people say that complex ruby has never been implemented, but
actually there is a Firefox add-on (XHTML Ruby Support
https://addons.mozilla.org/en-US/firefox/addon/1935/ ) that does a good job,
so it's not impossible. Amaya also supports complex ruby with XHTML 1.1

[2] At least 90% of the markup I've seen out in the wild uses <rb>.  I'm
inclined to favour the use of a markup model that aligns with the HTML5
approach, ie. with multiple ruby bases in one ruby elements, but that allows
optional use of <rb> tags if desired.  That would mean that all the existing
markup is not suddenly non-conforming.  (I am trying to get around to
writing an HTML5 bug report to propose that.) It needs to be made clear,
however, that it is possible to wrap a line at the boundary of ruby pairs,
ie. after <rt> elements, but not anywhere else.  Otherwise, you'll get a
mess.  The CSS3 Ruby module needs to address the new HTML5 approach to

[3] As far as I'm aware HTML5 doesn't currently allow  you to associate more
than one ruby text with base text. It may be possible to change the spec to
allow multiple <rt> elements in the HTML5 markup, as long as there is no
intervening text, but we'd need to investigate how that pans out. However,
multiple ruby is where the XHTML complex ruby model really comes into play,
as far as I can tell - since the spans of the ruby text are not usually the
same when you have multiple ruby texts associated with a single base
character - one is typically phonetic, the other typically semantic - so one
associates ruby text with specific base characters, while the other
associates it with the whole word or at least a sequence of characters. I
worry that nesting ruby would create horribly complicated markup.  It would
be good to create some examples - I have seen plenty in my son's manga
books. It may also be difficult to use nested markup to replicate the full
power of the complex ruby model, where arbitrary spanning is possible. The
arbitrary spanning of the XHTML model may be overly complicated for what is
generally needed in Japanese, but it may prove very useful for other types
of annotation, such as linguistic glosses of Arabic etc. (which I have seen
in the wild). 

[4] One of the problems for support of jukugo ruby is that the CSS3 Ruby
Annotation spec says that "ruby text is never allowed to overhang glyphs
belonging to another ruby base"
[http://dev.w3.org/csswg/css3-ruby/#rubyover].  This prohibits the
overlapping behaviour which characterises jukugo ruby.  (By jukugo ruby I
mean a special type of ruby behaviour, not just ruby associated with jukugo
words (which could be done with mono or even group ruby) See What’s so
difficult about jukugo ruby? at http://rishida.net/blog/?p=469 for
explanation).  I suspect that we may need an additional ruby overhand
property to identify jukugo ruby.  Even with that, we may need to rely on
implementations to implement the various rules about how ruby text overlaps
in jukugo ruby, since the ruby text can only overlap in certain
circumstances to a certain extent.  (Those rules are in the JLREQ document.)

[5] A number of people have suggested that implementations should activate
different behaviour when they find bopomofo characters being used as ruby
text, either by examining the characters or by looking at the language. I
disagree, since I've seen examples of ruby where the author wanted the
bopomofo to appear over the base text, like Japanese furigana, rather than
in the typical location. I think users need the power to make that choice,
and that's why we need a bopomofo property value in CSS3.  I suspect that we
will still need to rely on the implementation to apply the necessary details
to position bopomofo phones and tones correctly to the right of the
character, since it's a little tricky (for more details about how that
works, see
-posn.gif .  For a few real examples of bopomofo ruby see

[6] I welcome (specific) feedback on http://dev.w3.org/csswg/css3-ruby/ and


Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

Received on Friday, 24 September 2010 13:26:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:59:14 UTC