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

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

From: Richard Ishida <ishida@w3.org>
Date: Fri, 2 Oct 2015 17:01:59 +0100
To: fantasai.lists@inkedblade.net, ishida@w3.org, www-style@w3.org, www-international@w3.org
Message-ID: <560EAA77.8060606@w3.org>
On Tue, Sep 29, 2015 at 6:02 PM, fantasai 
<fantasai.lists@inkedblade.net> wrote:
 > 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.

presumably this would only work if you considered that eventuality in 
advance, though, because you'd need to separate non-CJK words, when 
merged, with spaces, so you'd need to ensure that they were present to 
start with? (I'm not sure about what the browser does with external 
spaces on ruby text - does it keep them or discard them?)  The 
usefulness of this approach seems to rely on a starting point where the 
markup is done on a 'separated' basis, where you are unlikely to 
systematically supply spaces around the annotation text.

i tend to agree with Tab that if you want word-based annotations it 
would be better to do that in the markup.


 > However I don't think we should have a separate property for jukugo 
compared to other annotation-merging effects.

that seems sensible, actually, since we'd presumably want the ability to 
undo the merging in some cases, ie. we'd need the separate value.

On 09/30/2015 08:06 PM, Tab Atkins Jr. wrote:
 > 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.

this seems reasonable to me.  I agree with Koji that we shouldn't define 
to the nth degree how jukugo should work, but rather point to jlreq.


On  Thu, 1 Oct 2015 18:38:14 -0700 Tab Atkins Jr. wrote:
 > Hmm, I see. I was under the impression that jukugo was the "word" 
mode; I didn't realize it was actually "mono, but allow overlap if 
necessary".

well described!  Most people refer to it as a cross between mono- and 
group-ruby, but it's not. It's mono-ruby that allows a certain amount of 
adjacent overlap for ruby text (potentially resulting, per the jlreq 
rules, in gaps between the ruby text when displayed on a single line - 
see http://rishida.net/blog/?p=469, esp. the diagram at the bottom)


On Thu, 1 Oct 2015 13:36:34 -0400 fantasai wrote:
 > 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)

mm, to be pernickety, 'syllable' is still not the right word, since a 
run of base characters per group ruby is more than a syllable.

but more importantly, i'm still not convinced that there's a real use 
case for the 3rd item.  I can see the theory behind it, but would people 
actually use it to switch between different display options, or would 
they just use the markup to group multi-word annotations above the base 
characters with spaces between when compounds are involved?

so i'm currently thinking:

ruby-merge: separate
ruby-merge: jukugo

may be what we need, for level 1 at least.
Received on Friday, 2 October 2015 16:02:11 UTC

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