W3C home > Mailing lists > Public > www-international@w3.org > October to December 2015

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 1 Oct 2015 13:36:34 -0400
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Richard Ishida <ishida@w3.org>, W3C Style <www-style@w3.org>, www International <www-international@w3.org>
Message-ID: <560D6F22.7020306@inkedblade.net>
On 09/30/2015 08:06 PM, Tab Atkins Jr. wrote:
> On Tue, Sep 29, 2015 at 6:02 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> On 09/24/2015 12:51 PM, Richard Ishida wrote:
>>>
>>> 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
> grouping/line-wrapping?

It's not, see Koji's reply. Jukugo and the sort of collapsing I'm
describing for Latin phonetics are not the same.

We basically need three values, in order of priority, for ruby-merge:

   1. syllable ruby (don't overlap adjacent bases)
   2. jukugo ruby (separate if space, allow overlap within word if not)
   3. word ruby (collapse annotations within a word)

The mapping in the spec is currently

   1. ruby-merge: separate
   2. ruby-merge: auto
   3. ruby-merge: collapse

We could use different words to describe these values, and/or rename
the property, but we have all the definitions needed currently, afaict.

~fantasai
Received on Thursday, 1 October 2015 17:37:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:09 UTC