search

w3c / imsc-tests

IMSC test suites
https://w3c.github.io/imsc-tests/
Other
16 stars 13 forks source link

Remove text combination from ruby container's base content. #74

Open skynavga opened 6 years ago

skynavga commented 6 years ago

Although the TTML2 spec does not (at present) contain language dealing with the use of text combination inside a ruby container, it is not expected that implementations of TTML2 1e be able to apply a ruby text annotation to ruby base content that contains text combination in its base content. In part, this is because there is no suitable definition of whether a cross-baseline inline area generated by text combination constitutes a ruby base constituent. [We may, however, choose to take this up in 2e and make explicit such support by defining its semantics.]

As such, either the ruby markup (and ruby annotation) or the text combination should be removed from the content representing the second outer span of [1]. I would suggest removing the ruby markup and leaving the text combination to test shear in the context of a multiple-line paragraph containing both ruby (in the first line) and text combination (in the second line).

[1] https://github.com/w3c/imsc-tests/blob/imsc-1.1/imsc1_1/ttml/shear/shear003.ttml

palemieux commented 6 years ago

Although the TTML2 spec does not (at present) contain language dealing with the use of text combination inside a ruby container,

@skynavga Can you file a TTML2 issue, or point to existing one?

skynavga commented 6 years ago

https://github.com/w3c/ttml2/issues/978

palemieux commented 6 years ago

Looking back at my notes, shear003.ttml is based on a contribution from a subtitle software implementer based in Japan. I am following-up to determine whether the contribution was based on actual use cases, or intended to merely exercise IMSC 1.1 features.

skynavga commented 6 years ago

BTW, I am not disputing that there are use cases for the use of text combine in a ruby container. There are, though it is quite unlikely to see this in a non-print context. I am merely saying that such a use case is not explicitly sanctioned by TTML2 1e. I agree that the syntax and the specification permits it as it stands, but that doesn't mean it is well-defined. And, in fact, it is not based on conflicts with other spec language that I mention above. Given this situation, it would not be appropriate to include tests that exercise such a possibility, at least in the 1e time frame.