Re: Ruby proposal for XSL 2.0

On Fri, Jan 29 2010 07:52:16 +0000, rolandsteiner@google.com wrote:
...
> 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)

Felix Sasaki also picked up on that in his comments at
http://lists.w3.org/Archives/Member/member-i18n-core/2010Jan/0009.html,
too.

Fixed, thank you.

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

Why is it important?  It does reflect my left-to-right thinking when I
made the diagram, but the numbering is just an aid for people who can't
read the kanji and kana, and the order isn't important in the markup as
currently proposed.

If the example were from an educational text, for example, then ruby in
the "after" position could be both more common and more important than
an occasional ruby in the "before" position, so I don't know that there
is or should be any inherent precedence of "before" vs "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, since it is practically identical to the

Ignorance on my part, sorry.

> conventions in your examples, with the only exception that it doesn't use a
> separate <rb> or <ruby-base> tag.

I don't see how HTML5 ruby would handle the "both sides" case.  Would it
be through using nested <ruby> and using styles to put one in the
"after" position?

FWIW, there is some text from figures in JLReq at
http://www.w3.org/Style/XSL/Group/FO/wiki/JLReq_Figure_Text and my
attempt at XHTML markup for the figures at
http://www.w3.org/Style/XSL/Group/FO/wiki/JLReq_Figure_Text_XHTML.  You,
or anyone, would be welcome to try marking up the figure text using
HTML5 ruby markup.

> 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

They are identical.  The jukugo ruby case requires something more, such
as the proposed "ruby-mode" property, to distinguish it from the
mono-ruby case.  In truth, the example is an exercise is seeing what
would work and what wouldn't.  I've added a note that it needs an
additional property to distinguish it from the mono-ruby case.

> former - and indeed group ruby - to simply look like: 
>
>       <ruby><ruby-base>K1K2</ruby-base><ruby-text>kakbkc</ruby-text></ruby>...

That would work for group-ruby, but not really for mono-ruby.  How does
that provide enough information to have 'ka' centered over 'K1' and
'kbkc' wholly over 'K2'?

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

Thanks for saying so.

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

It would be nice to be persuaded against using complex ruby markup, but
I keep thinking that it's necessary for distinguishing jukugo-ruby from
mono-ruby on a compound word.

> 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 (?).

The consequences of ruby on line building and inline building are more
than a little underdefined at present.  We still don't know if we have
defined all the properties that we need to define for handling ruby, so
it's not too much of a problem so far.

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

You may be onto something there.  I'll have to think about it.

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

Your feedback is appreciated.

Regards,


Tony.

Received on Tuesday, 2 February 2010 15:09:44 UTC