Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value

On Tue, Sep 29, 2015 at 6:02 PM, fantasai <> wrote:
> On 09/24/2015 12:51 PM, Richard Ishida wrote:
>> 4.2 Sharing Annotation Space: the ruby-merge property
>> I think the new ruby-merge property in the editor's draft is
>> overthinking the task. If people want to identify group ruby as
>> such let them mark it up appropriately, at least for Level 1.
> "Group ruby" is not the same -- it a term used for a ruby annotation
> which has multi-character base text, and there is no smaller mapping.
> E.g. mapping “San Francisco” to 旧金山 or “あした” to 明日. There is
> no smaller unit of correspondence that can be marked up, so the base
> text must "as a group" be placed into the base text box.
> Note: A lot of thinking and terminology around ruby is based on
> a per-character model of thinking, but HTML and CSS are based on
> a per-box model of thinking, where the boxes can have one or more
> characters as their contents.

Yeah, "mono" and "group" ruby are both covered under "ruby-merge:
separate", meaning "each base lays out with its individual ruby text".

>> I suspect this is an generalisation from an desire to support
>> jukugo ruby. But i think ruby-merge actually spoils things for
>> jukugo the way it's currently set up. Jukugo implies a specific
>> set of rules that i think people will want to apply explicitly
>> rather than possibly getting or possibly not getting what they
>> want via auto.
> I think it's fine to get rid of the 'auto' value if that seems to
> make sense.
>> Is there actually a requirement for group ruby that splits on
>> line wrap?
> I'm not sure about the line wrapping aspect, but I can imagine
> ruby-merge being used when the ruby consists of romanized phonetics:
> in that case, the markup should map each base character to its
> pronunciation, since that is the fundamental structural correspondence.
> But there's a stylistic choice between whether the ruby should be
> presented as mono ruby with the phonetics centered per character,
> or as word-based ruby where the phonetics are centered per word.

That seems to be well-handled by marking up each word as a separate
<ruby>, with 'ruby-merge' dictating whether the phonetics are
per-character or merged into a continuous word.

>> So, I'm not convinced that we really need ruby-merge for level 1,
>> and I think that we should have a simple property for turning on
>> jukugo.
> I don't mind deferring ruby-merge to level 2, or adding a value
> that enables specifically the JLREQ algorithm or JISX4051 algorithm.
> However I don't think we should have a separate property for jukugo
> compared to other annotation-merging effects.
> Given the draft is still in an early stage (not very stable, needs
> a lot of work), I'd prefer speccing the appropriate switch for
> jukugo, and dropping it only if there's still no implementation
> interest once we get closer to CR.

Based on an admittedly quick re-read of the spec, can we just make
"ruby-merge: collapse;" be the jukugo value?  With an explicit
reference to JLREQ to specify it.  I'm not sure I see the value in
specifying a third alternative to mono/jukugo, if those are the only
two real ruby layout modes in practice.  It sounds like the jukugo
algorithm is just a well-specified attractive form of


Received on Thursday, 1 October 2015 00:07:27 UTC