Re: [svgwg] How to lay out ruby-annotations in SVG 2? (#870)

Ok, I managed to get parsing of most of the typical cases done:
[ruby_in_svg_basic_parsing.zip](https://github.com/w3c/svgwg/files/7699182/ruby_in_svg_basic_parsing.zip)

Some problems:

1. While parsing the display property went fine, positioning them with x, dx, dy and y, while keeping the DOM-order was very tricky, and I gave up with the interleaved case. I wouldn't want to wish this on anyone, and I hope we can use these display values so the positioning is something that's only of concern to the renderer and text-selection mechanism.
2. That said, there's [no ruby-parenthesis value](https://www.w3.org/TR/css-ruby-1/#ruby-display), because the ruby working group decided [that 'display:none' (item 3) ](https://www.w3.org/TR/css-ruby-1/#changes-20110630)would be sufficient, probably thinking of a case where it's combined with specific xml elements. Problem is, an SVG renderer might know 'display:none', but not all of these 'display:ruby-' properties, making this useless for marking up fallback parentheses. Related, SVG doesn't have [content, ::before and ::after selectors](https://www.w3.org/TR/SVG2/text.html#TextProperties), so dynamically generating parentheses for certain situations, as suggested by the [ruby spec](https://www.w3.org/TR/css-ruby-1/#default-parens) doesn't work either. -- The lack of ruby-parentheses display value could be solved by either requesting this property value or by defining ruby xml elements for SVG.
3. [Rule 2 of the anonymous box generation](https://www.w3.org/TR/css-ruby-1/#anon-gen-anon-ruby) is kinda scary. It would mean that a span with  'ruby-base' parented by a span with 'ruby-text-container' would result in the 'ruby-base' span being wrapped in a 'ruby' container, leading to nested Ruby. Acceptable in HTML right now, but for SVG I'd much rather interpret unexpected display values as 'inline' to prevent having to puzzle out the mysteries of nested-tables.
4. This one's kinda minor, but there's [no way to offset Ruby from their base](https://github.com/w3c/csswg-drafts/issues/4932). It seems the spec authors decided that using margin/padding would be best used for this, but this cannot be used in SVG: It doesn't have the CSS-box-model.
 
Other notes:

1. Similar to superscript, the display properties don't indicate default font-size. Authoring tools should probably look at the [default classes](https://www.w3.org/TR/css-ruby-1/#default-ua-ruby) and offer those to users.
2. Note that [Text-emphasis-marks](https://drafts.csswg.org/css-text-decor/#emphasis-marks) interact with Ruby, but the ruby spec doesn't mention this. I've had real-world conversations where both are confused, so I'd recommend looking at it too.
3. A significant portion of the ruby spec talks about spanning annotations. These only happen in XHTML, and the ruby spec doesn't define a css property for it, so we shouldn't have to worry about them.
4. Bopomofo handling is still very experimental. Especially [the tone-marks handling](https://r12a.github.io/scripts/bopomofo/ontheweb#tones) is semi-unsolved. This seems to be compounded by the fact that apparently it's not just tone-marks, but also what Unicode refers to as 'final' letters ([In CLReq named 'dialectical checked tones'](https://w3c.github.io/clreq/#h-positioning_tones_in_zhuyin)). It's still up in the air whether the text-layout or the font is responsible for positioning these marks correctly, though there have been [fonts made that can place them](https://github.com/cmex-30/Bopomofo_on_Web) already.
5. related to that, SVG can officially not change writing mode in the middle of a text because it only has inline text. inter-character ruby is treated as inline-block, and one might need to double-check how things interact with inline-block for handling inter-character. For example, for [letter-spacing](https://www.w3.org/TR/css-text-3/#letter-spacing-property) 'inline-block' is treated as a single typographical character.

Anyway, please check out the samples and whether they're acceptable. I'll wait with providing feedback to the CSS issue tracker until people have had a chance to think about this here.

-- 
GitHub Notification of comment by therahedwig
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/870#issuecomment-991943723 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 12 December 2021 18:05:05 UTC