Re: Ruby proposal for XSL 2.0

Hi Tony,

disclaimer: I work on an implementation of HTML5 ruby, but I'd still have
some remarks from a quick reading (acknowledging that this is following
CSS3/XHTML):


In "3.3 Types of Ruby", first table:

.) As for whether group and jukugo ruby applies to single characters, I'd
say no, because a single character is by definition not a group, nor
compound
.) Unless I misunderstand the meaning of the last column, jukugo ruby should
be indicated as breakable (cf. 3.3.2.1 breaking jukugo ruby)


In "3.4.1.6 Both Sides" I'd suggest to reverse the ordering of the Kana
characters, i.e., index the right as 'ka' to 'kd' (since they are logically
in the "before" position), and the ones to the left 'ke' to 'kg' (since they
are in the "after" position).


in "3.4.2 Interleaving Base- and Ruby Text": esp. here I'd have hoped for a
reference to the HTML5 ruby
spec<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element>,
since it is practically identical to the conventions in your examples, with
the only exception that it doesn't use a separate <rb> or <ruby-base> tag.

Also, the examples for "Mono ruby, compound word" and "Jukugo-ruby" seem to
be identical? In that notation (and indeed in HTML5, IMHO) I would expect
the former - and indeed group ruby - to simply look like:


 <ruby><ruby-base>K1K2</ruby-base><ruby-text>kakbkc</ruby-text></ruby>...


about "3.6 Treat ruby-align as short hand?": FWIW, I agree that ruby-align
should really be split.


chapter 4 in general: To be honest, given that CSS3 ruby spec is on hold,
I'm not sure enshrining complex ruby further at this early stage is a good
idea. Esp. for "ruby-span" it would IMHO require additional details on error
handling: ruby-span value too large, how ruby-span is supposed to be handled
without <rbc>/<rtc>, line-breaking within complex ruby, etc. I would also
imagine that "ruby-overhang" raises some detail questions about the box
model and adjacent glyph heights (?).


ad "4.3.10 ruby-mode": if the ruby markup follows 3.4.2, then I don't
believe this attribute is necessary, since if the user doesn't want ruby
texts to intrude on each other, s/he can just put them in separate <ruby>
elements.


I hope all this was a bit helpful (and not too much off the mark),


Cheers,

Roland


On Tue, Jan 19, 2010 at 6:47 PM, Tony Graham <
Tony.Graham@menteithconsulting.com> wrote:

> FYI, the XSL FO SG is developing a proposal for handling ruby in XSL 2.0
> at http://www.w3.org/Style/XSL/Group/FO/wiki/Ruby
>
> Any comments would be very welcome, and feedback on the identified
> issues would be appreciated.
>
> The proposal is based on the ruby details in JLReq [1] while trying to
> remain compatible with the CSS3 Ruby Module [2] (which is on hold [3]).
>
> Please note that while JLReq defines three types of ruby, the XHTML Ruby
> Annotation module and the CSS3 Ruby Module do not distinguish between
> mono-ruby and jukugo-ruby. The CSS3 Ruby Module refers to JIS X
> 4051:1995, not to JIS X 4051:2004, where Jukugo-ruby is in JIS X
> 2051:2004 but not in JIS X 4051:1995.
>
> Regards,
>
>
> Tony Graham                         Tony.Graham@MenteithConsulting.com
> Director                                  W3C XSL FO SG Invited Expert
> Menteith Consulting Ltd                               XML Guild member
> XML, XSL and XSLT consulting, programming and training
> Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
> Registered in Ireland - No. 428599   http://www.menteithconsulting.com
>  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
> xmlroff XSL Formatter                               http://xmlroff.org
> xslide Emacs mode                  http://www.menteith.com/wiki/xslide
> Unicode: A Primer                               urn:isbn:0-7645-4625-2
>
>
> [1] http://www.w3.org/TR/2009/NOTE-jlreq-20090604/
> [2] http://www.w3.org/TR/2003/CR-css3-ruby-20030514
> [3] http://lists.w3.org/Archives/Public/www-style/2009Jun/0341.html
>
>