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

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. <jackalmage@gmail.com> 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:
> >>
> >> 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
>
>