[css-ruby] Zaima Use Cases for Ruby Annotation Level Testing

[dyacob]

The current CSS Ruby draft spec addresses annotation levels in sections 2.3.1 and 3.1 . The annotation capabilities described appear to support requirements for Zaima annotation.

My request is for the Zaima use cases to be used in the testing of the annotation level support. Multiple annotation levels are critical to the Zaima practice and Ruby markup and word processor support has been the primary means of authoring and rendering it digitally. I am available to port the existing use cases to the new markup, but would require a small amount of guidance to do so.

Referenced Sections

2.3.1. Segment Pairing and Annotation Levels: https://drafts.csswg.org/css-ruby-1/#segment-pairing

3.1. Interlinear Ruby Layout: https://drafts.csswg.org/css-ruby-1/#interlinear-layout

Zaima Use Cases: https://w3c.github.io/elreq/zaima/ZaimaUseCases.html

[dyacob]

Following the example in the CSS Ruby Annotation Layout Module Level 1 draft spec, ASCII style tables have been created to help with layout clarification:

https://w3c.github.io/elreq/zaima/ZaimaAsciiTables.html

[frivoal]

I wasn't aware of Zaima, but that's very interesting, and your offer is very much welcome. From what I understand about it based on the documents you shared, css-ruby should indeed be able to handle it, but that however comes with a major caveat: the layout would work assuming that a markup language which supports explicit spanning is used, so that you can indicate how many bases each annotation is supposed to span.

If such a language is used, css-ruby should do the job.

But HTML is not (at the moment) such a language. XHTML Complex Ruby Annotations would fit the bill, thanks to the rbspan attribute on the rt element, but I don't believe that is implemented anywhere.

Theoretically, there's no reason HTML couldn't be extended to support that, but given the resistance that simpler features have faced, that's unfortunately going to be a challenge. In particular, multi-level itself is still not fully accepted. Only Firefox supports it so at the moment. I don't know how much importance browser vendors will give to Zaima, but I suspect they may not be aware of its need for multi-level ruby, so maybe letting them know could contribute to prioritizing this feature.

---

Also, I'd like to draw your attention to this note from section 3.1.1:

Note: If there are multiple annotations spanning the same number of bases that overlap but do not coincide, the distribution of space is undefined. […] can happen in markup languages with explicit spanning […]

Depending on how specific the layout needs of Zaima are, this may or may not be an issue.

[dyacob]

Thanks @frivoal for setting expectations, I anticipate a long journey to full support by vendors 😄 . At this stage, my goal would be to assure that the lack of a specification could not be the rationale for non-support. An overview of Zaima here, from 2018, I'll happily add to it to provide answers to basic questions.

I have difficulty visualizing what is being described in section 3.1.1 , I'll keep working on it, is there a graphic available that presents the issue? I assume the "multiple annotations" in "...multiple annotations spanning the same number" means over various rows? On each row, the lateral positioning of annotation text relative to the base is pretty important. Basic alignment like "left|right|center" has been sufficient when working with a single row an <rt> tag (with occasional padding with a space symbol applied).

If the multiple annotations occur on the same row over base text, then the ruby-merge property seems to be a solution. The "ruby-merge: merge" value would be a default for Zaima practices, nice to see that already in place.

[frivoal]

I assume the "multiple annotations" in "...multiple annotations spanning the same number" means over various rows?

yes. Now clarified in the spec.

To better explain what the "problem" with 3.1.1 is, let me start with something that isn't a problem:

[a11] [  a1-23  ]
[b-1] [b-2] [b-3]

If the text in annotation a1-23 is wider than the sum of b-2 and b-3, the excess is distributed equally among the spanned columns. Same thing for a2-12 with b-1 and b-2 here:

[  a2-12  ] [a23]
[b-1] [b-2] [b-3]

However if you have a multi-level annotation like this, we have a (small) problem:

[  a2-12  ] [a23]
[a11] [  a1-23  ]
[b-1] [b-2] [b-3]

In this case if a1-23 is wider than the sum of b-2 and b-3 AND a2-12 is wider than the sum of b-1 and b-2, depending on how you go about doing it (distribute a1-23 first, distribute a2-12 first, somehow combine), the result may be different. All the potential results will be correct and keep things sensibly aligned, but the specification doesn't (at the moment) say how to resolve this ambiguity.

For instance, let's say that the content of all bases and annotations are 10px wide, except a1-23 which is 40px, and a2-12 which is 30px. If you distribute a1-23 first, you make the b-2 and b-3 columns 20px wide each, and then since a2-12's 30px do fit within over b-1 + b-2 (10px+20px=30px), you stop there. The columns end up being 10px, 20px, 20px.

However, If you distribute a2-12 first, you make the b-1 and b-2 columns 15px wide each, and then since a1-23's 40px do not fit within over b-2 + b-3 (15px+10px=25px), you need to distribute the 40px-25px=15px equally between these two columns, making b2=15+15/2=22.5 and b3=10+15/2=17.5. The columns end up being 15px, 22.5px, 17.5px.

It's unlikely to be a real issue, but depending on how specific you are about the result you'd like to see, you might notice.

This is a solvable problem, but leaving this undefined for now was a deliberate choice: given the absence both of a markup language where this case can occur, and of known use-cases documenting that this matters, this didn't seem worth diving into.

[dyacob]

Thanks @frivoal for taking the time to clarify so thoroughly. I understand the issue now. I will keep watch for a use-case from corpus to see how it is normally handled. My instinct is that the lower annotation row would take precedence, since it would be written first in the Zaima practice (in handwriting). Then on the higher rows text would be modulated (compressed or written at an angle) to fit available space.

Leaving the layout undefined seems fine for now until a use case is identified.