Re: Ruby proposal for XSL 2.0 (batch2)

Hi Tony,

I'm still working through the wiki text, but I figured it may help to send my comments in batches, rather than store them all up.  So here is another batch.


[3] "The XHTML Ruby Annotation module and the CSS3 Ruby Module both define ruby in terms of "simple ruby" and "complex ruby". Simple ruby is suitable for representing mono-ruby on single-kanji words and for representing group-ruby. Complex ruby is suitable for those and also for representing either mono-ruby on compound words or jukugo-ruby on compound words: it can't do both because there is no mechanism for specifying one behavior or the other."

I think the mention of words wrt mono-ruby slightly over-complicates things.  As I understand it, you can use mono-ruby anywhere, it's just that you are marking up a single kanji at a time.

I think complex ruby could also be used for group ruby, and in fact you would have to use it for group ruby if you wanted to display ruby both before and after the base text.

" it can't do both... " might be clearer as " it can't do jukugo ruby and another type of ruby within a single ruby element..."



[4] ruby-span

I'm wondering whether it's ok to express this only as a style property, rather than in markup.  I suppose the situation is potentially different for XSL-FO, since you don't normally convert that markup to something else, but it just feels like this ought to be in the markup, since it is essentially structural information, relating two items to each other.


[5] fo:ruby

What is the plan for dealing with XHTML's rp fallback? I'm assuming that there may be processors out there that can't handle correct ruby placement, and that there needs to be a fallback mechanism, or is it the case that you create your XSL-FO markup with a particular processing application in mind?


[6] ruby-position: right

There has been some confusion around this value for some considerable time, mainly because it was never properly clarified in the CSS3 spec, and the editing of the spec stopped around the time that it was being discussed.  This value (right) was introduced specifically for the Bopomofo case, which combines vertical annotations with horizontal base text as well as vertical base text.  The writing-mode approach was an attempt by Michel to specify how Bopomofo could be handled that was never fully convincing to other members of the i18n WG.  (See http://lists.w3.org/Archives/Member/w3c-css-wg/2001JanMar/0266.html )  

The location of the spec text about Bopomofo is another of the things that was changed in the 2006 version of the CSS3 Ruby draft, although the question of the writing-mode property had still not been fully resolved at that point.

Basically, the handling of Bopomofo still has to be clarified in the CSS3 spec. In my opinion, the assignment of a value of right to ruby-position should suffice (right meaning actually vertical-mono-ruby-to-the-right-of-the-base-character) and the application should take care of the arrangement of the Bopomofo from there.  (Note also that placement is slightly complicated, and Bopomofo specific, because the (spacing) tone mark is positioned in a separate column to the right of the  bopomofo text itself.)


[7] html5 ruby

I plan to send a request to the HTML WG to change their markup for ruby so that it supports markup as per the Ruby Annotation spec.  I'm guessing that this will be supported by the i18n WG.  Otherwise it leads to lack of backwards compatibility with existing ruby markup.

It may be that the markup as specified by HTML5 currently would provide a helpful way of extending the current XHTML/Ruby Annotation markup for simple ruby.  I need to think that through some more.


RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

Received on Thursday, 4 February 2010 11:21:29 UTC