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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

r12a
http://www.w3.org/TR/css-ruby-1/#collapsed-ruby
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.

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.

Is there actually a requirement for group ruby that splits on line wrap?
I don't remember one – only that jukugo ruby does that. But
ruby-merge:collapse and ruby-merge:auto (which is supposedly there for
jukugo) are different settings.

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.

In private email, Fantasai said:
"The default is going to be mono ruby. If people want a switch
for jukugo, that's what ruby-merge is for. If we want to have
a value that is only for the particular jukugo algorithm in
JLREQ and if you can't do exactly that you don't do anything
with this property, then we can do that. Please send a comment
to that effect."

I am proposing that we remove the ruby-merge property and that, when we
are ready to spec support for jukugo ruby, we add a value for the
particular jukugo algorithm in JLREQ, and if the browser can't do that
it falls back to mono-ruby.

Note, btw, that this property is not supported by any major browser at
the moment (unlike the other properties).

ri

Reply | Threaded
Open this post in threaded view
|

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

fantasai
On 09/24/2015 12:51 PM, Richard Ishida wrote:
> http://www.w3.org/TR/css-ruby-1/#collapsed-ruby
> 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.

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

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

~fantasai

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Tue, Sep 29, 2015 at 6:02 PM, fantasai <[hidden email]> wrote:

> On 09/24/2015 12:51 PM, Richard Ishida wrote:
>>
>> http://www.w3.org/TR/css-ruby-1/#collapsed-ruby
>> 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
grouping/line-wrapping?

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Koji Ishii
I'm ok with deferring as Richard suggested, or limit to Jukugo only as Tab suggested.

One clarification about Jukugo-ruby; we can informatively reference JLREQ, but I'm not positive to make the logic in JLREQ normative. The concept of Jukugo-ruby is to look mono-ruby when possible, but when not, avoid additional spacing in base by allowing overhang to adjacent ruby text container.

As long as the concept is achieved, how it's actually implemented has several variations in the real world, and JLREQ summarizes often-seen methods picked by the editors. Implementing all of them can be overly complex, or methods not in JLREQ can be used.

It's like line breaking or justification -- as long as the goal is achieved, different algorithm should be allowed.

/koji

On Thu, Oct 1, 2015 at 9:06 AM, Tab Atkins Jr. <[hidden email]> wrote:
On Tue, Sep 29, 2015 at 6:02 PM, fantasai <[hidden email]> wrote:
> On 09/24/2015 12:51 PM, Richard Ishida wrote:
>>
>> http://www.w3.org/TR/css-ruby-1/#collapsed-ruby
>> 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
grouping/line-wrapping?

~TJ


Reply | Threaded
Open this post in threaded view
|

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

fantasai
In reply to this post by Tab Atkins Jr.
On 09/30/2015 08:06 PM, Tab Atkins Jr. wrote:

> On Tue, Sep 29, 2015 at 6:02 PM, fantasai <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Thu, Oct 1, 2015 at 10:36 AM, fantasai <[hidden email]> wrote:

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

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

I definitely see how the "word" mode is necessary for ruby usage in
any other language.  Different keywords would be good, then, because
"auto" doesn't suggest jukugo.  I'll think on this a bit.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

r12a
In reply to this post by fantasai
On Tue, Sep 29, 2015 at 6:02 PM, fantasai
<[hidden email]> 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.