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

Ruby: questions about fallback

From: Richard Ishida <ishida@w3.org>
Date: Wed, 06 Mar 2013 10:43:56 +0000
Message-ID: <51371DEC.10702@w3.org>
To: "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>, "KOBAYASHI Tatsuo(FAMILY Given)" <tlk@kobysh.com>, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
I have been working through the ruby use cases document again, and I 
have the following questions:

[1] compound nouns and bopomofo ruby

We have been assuming that in japanese a compound noun such as 法華経 
would look better if the fallback produced 法華経(ほけきょう), rather 
than 法(ほ)華(け)経(きょう).

I think that there are far fewer compound nouns in Chinese than in 
Japanese, but my question is whether, where compound nouns do appear, 
there is any requirement to group the ruby text after the ideographic 
characters in the same way.  My assumption is that this is not needed - 
ie. that  bopomofo ruby fallback will always be B(a)B(a)...

Is that correct?

[2] hiragana base characters

What is the expectation for fallback in a word like 振り仮名?

Would one expect to see 振(ふ)り仮(が名な) or 振り仮名(ふりがな)?

If the latter, I'm not sure how one would do it.

[3] API ruby support detector

The problem with fallback is that you can't provide characters such as 
parentheses to clarify the repetition of base and ruby text for the 
reader unless you provide rp elements around all your ruby text. It is a 
tall order to expect that everyone will do that religiously. Not only 
does it significantly increase the amount of effort required to create 
ruby markup, but it makes the source text more difficult to read, and 
adds complexity when it comes to searching text.

For inline ruby text, styling can provide the needed delimiters, using 
:before and :after, but this approach can't be used for general fallback 
because such an approach would also produce delimiters around ruby text 
if the browser is capable of displaying ruby text above or below the 
base text.

A possible solution might be to test whether the browser supports ruby 
using scripting. For this to work, it would be necessary for the DOM API 
to indicate whether ruby is supported by the browser. Browers would set 
this to true when they add ruby support.

With that in place, you could write your ruby elements without rp 
elements, then test whether ruby is supported, and if not activate a 
line of JavaScript to set styling for rt elements that produces parens 
(or whatever you want) before and after.

It's not foolproof, since you need scripting to be available, but it 
might be better than nothing.

Does that make any sense?

Richard Ishida, W3C
Received on Wednesday, 6 March 2013 10:44:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:10:24 UTC