[css-ruby] Overhanging and auto-hiding

[upsuper]

Copy from my email to www-style:

The current spec says:

The ruby annotations related to a ruby base must never overhang another ruby base.

However, there are cases that a ruby base doesn't not actually have any annotation with it. One of the cases would be auto-hidden annotation. Also, if there is shortage of annotation, a ruby base could have no annotation to pair with.

I propose that we should relax the restriction here, and allow ruby annotation to overhang ruby base if the ruby base doesn't have effective related annotation. Ruby base with no visible annotation should just be treated as plain text.

[frivoal]

Neither JLREQ nor Simple Ruby seem to have much to say either about words like 振り仮名 with kana in the middle, or like 温あたためる which have a single kanji, possibly with a long ruby annotation, followed by hiragana.

I wonder if they're expected to get a jukugo-like treatment, with the annotations overhanging other bases within the same ruby container, or if maintaining strict isolation is preferred.

A strict reading of Simple ruby would lead you to think that maintaining strict isolation is desired, but all the examples of "don't overhang over neighboring text" have separate words as the neighboring text, and so it might be different when the neighboring kana are actually part of the same word.

[himorin]

Neither JLREQ nor Simple Ruby seem to have much to say either about words like 振り仮名 with kana in the middle, or like 温める which have a single kanji, possibly with a long ruby annotation, followed by hiragana.

Such two cases, like "ふりがな" for "振り仮名" (could happen?) or "あたためる" for "温める" (seems quite rare?), are not clearly listed in three types of purpose listed in JLReq https://www.w3.org/TR/jlreq/#id216 and we are better to bring this issue to relevant group(s). For a declensional kana endings case like "あたた" for "温" with endings "める", it should not be taken differently from other Kanji + Kana cases, but I also agree that it is better to have some example(s) or clarification text(s).

Personally I think these could be considered as Jukugo or Group cases by additional combination to second item (b.) which has a text:

When attaching katakana (cl-16) ruby text to a run of base text consisting of two or more characters in ideographic character (cl-19) and/or hiragana (cl-15), the ruby text needs to be positioned as if it corresponds to the annotated text itself, no matter how the ruby characters are distributed across each base character.

[frivoal]

Interesting cases, probably in the spirit of @upsuper 's original comment, would be words like <ruby><rb>働<rb>き<rb>手<rt>はたら<rt>き<rt>て</ruby> or <ruby><rb>考<rb>え<rb>方<rt>かんが<rt>え<rt>かた</ruby>. They are kind of like like 振り仮名 in the sense of having an unanotated base in the middle, but with 3 annotation characters for the first base, there's a question of overhang.

The ruby-merge:separate rendering currently requires adding a gap between the first and second bases in both those examples, to make sure the last character of the first annotation does not overhang the second base, but maybe we could allow that. However, if we do, we'd be at risk of running into the same kind of colliding annotations problem discussed in Figure 137 of JLREQ, and would need the sort of solutions illustrated in fig 138. Solving this properly is reasonably complicated, and factors in a lot of subjective opinions, so I don't think I really want to go into allowing one particular type of intra-ruby overhang, together with one particular mitigation strategy for the problematic cases.

Currently 'ruby-overhang: auto | none' only controls overhang of the ruby onto neighboring inlines. Maybe it could be expanded to control (possibly with the same value, possibly with a second one) whether intra-ruby overhang is allowable, leaving most of the details up to the UA, as we do for overhang onto neighboring inlines. I suppose this would have no effect under ruby-merge:auto, which already let internal overhang happen anyway. And it's not relevant for ruby-merge:merge either. The only difference would be for annotations with ruby-merge:separate.

I suppose the way I'd spec that is to say that if annotations where ruby-overhang-internal is auto are wider than the column they're in, the UA is allowed to overflow the ruby column, as long as that does not make them collide with a neighboring annotation on the same level. The UA should probably also not just stop at the point they'd touch, but keep a minumum (UA-defined) distance, and it would also be allowed to take other things into account (whether the neigboring base has any annotation, whether it's text is kanji or kana… anything it thinks is relevant). However, to keep ruby-merge:separate + overhang from becoming the same thing as ruby-merge: auto, it would not be allowed to change the alignement between the annotation and the base it is paired with.

Or something like that.

That said, while I think we could specify something like this, I am unconvinced it is worth it. We already have plenty of moving parts and a decently complicated model, and I'd rather we first got the basics down. So my preference would be to go on disallowing internal ruby overhang, at least for now. If we change our mind later, we can always add a second value to ruby-overhang, which defaults to none when omitted to explain the current behavior, but could be switched on.

[fantasai]

I suppose this would have no effect under ruby-merge:auto, which already let internal overhang happen anyway.

I think if we define internal overhang over annotationless bases to behave similarly to external overhang over adjacent text, it should behave the same under separate and auto. auto should only be only different in that it allows sharing space across adjacent bases.

That said, while I think we could specify something like this, I am unconvinced it is worth it. We already have plenty of moving parts and a decently complicated model, and I'd rather we first got the basics down.

If internal overhang is less common than external overhang, then we can defer it to L2. But if the general expectation is that internal overhang behaves like external overhang, then we should spec it as such now.

[himorin]

(I suppose 'internal overhang' is in ruby element and 'external overhang' is to before-/after- ruby element, like 'ら' as internal and 'は' as external for '働き手' example. if not please correct me...)

I suppose this would have no effect under ruby-merge:auto, which already let internal overhang happen anyway.

I think if we define internal overhang over annotationless bases to behave similarly to external overhang over adjacent text, it should behave the same under separate and auto. auto should only be only different in that it allows sharing space across adjacent bases.

From simple-ruby point of view, as the most important background is to define rules as simple as possible without considering complex edge cases (but interesting area, surely), and (I believe we) placed the same for internal and external.

That said, while I think we could specify something like this, I am unconvinced it is worth it. We already have plenty of moving parts and a decently complicated model, and I'd rather we first got the basics down.

If internal overhang is less common than external overhang, then we can defer it to L2. But if the general expectation is that internal overhang behaves like external overhang, then we should spec it as such now.

In conversation of JLReq (see item 3.), it was pointed as default rule that annotations (furigana in original meaning) which is longer than its base (Kanji) overhangs to following base character (okurigana, like 'え' or 'き' in Florian's examples) up to one annotation character (half size of the base character).

I suppose the question is whether to make following three pattern enabled by CSS ruby properties, but is it correct understanding?