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

Fwd: Re: HTML Ruby Extension

From: Richard Ishida <ishida@w3.org>
Date: Thu, 14 Feb 2013 06:27:18 +0000
Message-ID: <511C83C6.2030306@w3.org>
To: "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>
Email from Fantasai, forwarded with permission.

-------- Original Message --------
Subject: Re: HTML Ruby Extension
Date: Tue, 12 Feb 2013 23:28:28 -0800

On 02/12/2013 10:17 AM, Richard Ishida wrote:
...
> [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 06:34:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 February 2013 06:34:52 GMT