Re: Ruby proposal for XSL 2.0 (batch2)

Richard,

On Thu, February 4, 2010 12:20 pm, Richard Ishida wrote:
> 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.

I'm getting back to looking at ruby after a long time away from it.

> [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.

Yes, but "simple ruby" markup can do more than one base kanji.

> 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..."

The change has been made.

> [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.

I'm not sure that I understand the issue: the 'ruby-span' value would have
come from the original markup.  XSL FO can leave it to XSLT to get the
span value from the original markup, unlike having to specify an attribute
name as in CSS3-ruby.

> [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?

There's now a 'fo:ruby-parenthesis' formatting object, though we'll see
how long that names remains, since it's rather longer than its likely
content.

My original assumption was that XSL FO 2.0 processors would all support
ruby, but that is probably too optimistic.

> [6] ruby-position: right
...
> 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.)

The text now uses a 'bopomofo' value based on your current Editor's Draft
of CSS3-ruby at http://dev.w3.org/csswg/css3-ruby/

> [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.

I'll leave that to you.

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

Received on Friday, 8 October 2010 00:21:39 UTC