W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2013

Re: HTML Ruby Extension

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 13 Feb 2013 17:30:08 -0800
Message-ID: <511C3E20.10001@inkedblade.net>
To: public-i18n-cjk@w3.org
On 02/12/2013 10:17 AM, Richard Ishida wrote:
> Robin Berjon wrote:
>> Hi,
>>
>> you've all expressed some degree of interest in this work. Please find my first stab at:
>>
>>     http://darobin.github.com/html-ruby/
>>
>> You can find a playground that matches the algorithm at:
>>
>>     http://berjon.com/tmp/inception/playground/render-ruby/
>>
>> I've just finished tweaking it. I plan to send it to the HTML WG for review
>> tomorrow (after I sleep on my changes a bit). In the meantime, if there's
>> anything you wish to scream about, feel free to do so :)
...
> [2] a more significant issue:
>
> I think the markup proposed for jukugo ruby is too complicated for the general case
>
> <ruby><rb>上<rb>手<rt>じよう<rt>ず</ruby>
>
> should just be
>
> <ruby>上<rt>じよう</rt>手<rt>ず</ruby>
>
> jukugo ruby is just mono-ruby - it's the styling that makes the difference,
> by allowing slightly more complicated overlapping than you would for mono-ruby.

While it is true that jukugo ruby and mono ruby are stylistic variants
of each other when applied to a single word, my understanding is that
in the case where ruby can be combined into a jukugo rendering, you
also want the annotations combined when rendered inline.

> At the very least you should state this, and not leave people thinking that they
> have to use a tabular approach for jukugo base text.

This would mean having two different CSS models (one column-based,
one row-based) for ruby. Is it necessary to allow both variants?
Can you give me an example where jukugo ruby is appropriate but
split inlining is preferable?

> But if you mark it up like that you won't get what you want at all, surely. You'll get 東京とうきょう with no parens.

If you assume that a renderer will either:
   - handle ruby markup intrinsically or
   - support CSS2.1 generated content
then you can deal with the parens that way rather than adding them
explicitly to the markup. The necessary information is there in the
markup already.

Unfortunately because of limitations in Selectors (they completely
ignore text nodes), you'll have to use <rb> to get the parens
generated correctly via CSS2.1. :/

> [5] for double-sided ruby, it is sometimes the case that the rtc text relates
> to only, say, 2 out of the three characters with annotations above. Is that
> possible? (maybe i need to read a bit further to find the answer)

Can you give an example where this is the case *and* the three annotations
above are a single word (i.e. should be rendered as jukugo)?

> Also, is it possible to have the group ruby on the top and the non-group below?

Don't see why not.

> What about when you have text above spanning two base characters as group ruby
> then one mono ruby, while below you have either a single group-ruby for all
> three base characters or three individual ruby annotations, one for each base
> character?

Group ruby is just mono ruby with more than one base character, so the first
case is easy. :)

The second case I think is not possible (assuming you want jukugo rendering
across all three bases) without some kind of extension to this markup model.
IIRC it wasn't considered important when I last talked with either the EPUB3
EGLS or i18nwg, although it is part of XHTML Ruby. I don't think HTML5's
model can fully handle that either, though. (It can do jukugo either across
the three bases OR across the group + mono, but not both.) This model can
at least accept the extensions in XHTML Ruby if we want to go that way.

If jukugo rendering or combined inlining of the second case isn't needed,
then you can mark it up as

<ruby><rb>A<rb>B<rtc>grp</rtc><rtc><rt>a<rt>b<rb>C<rt>c'<rtc>c</ruby>

This corresponds to two "ruby words", the first with a group ruby on
one side and two mono ruby on the other, and the second with a mono
annotation on either side.

~fantasai
Received on Thursday, 14 February 2013 01:30:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 February 2013 01:30:37 GMT