Handling non-kana text for rubyAlign with spaceAround or spaceBetween.

[r12a]

10.2.34 tts:rubyAlign
https://www.w3.org/TR/2016/WD-ttml2-20161117/#style-attribute-rubyAlign

If the value is spaceBetween, then excess whitespace is equally distributed between each ruby annotation glyph area. If the value is spaceAround, then excess whitespace is equally distributed before and after each ruby annotation glyph area descendant.

Note that the CSS Ruby spec recommends the use of justification rather than just distributing space equally. Both approaches would have the same result for ideographic base characters annotated with kana, but not the same if they were annotated with say pinyin latin text.

JLReq and CLReq, afaict, expect Latin annotations to be centred, rather than to have the letters stretched out. This isn't accounted for here, and i expect it needs to be.

Note, btw, that centred latin text is a justification for the use of justification in the CSS spec, however i'm not sure that is completely thought out, because if the annotation were two short latin words they may be separated rather than centred if justification is applied, and i think that the expectation is that they would be still centred. (I want to raise this question for CSS, too.)

[dae-kim]

Suggest we resolve with #274

[r12a]

So, what is still not clear to me is how spaceAround and spaceBetween look when applied to latin text annotations (such as pinyin ruby). I'm afraid this comes back to the definition of glyph area.

Glenn says that the Jay Chou example should be treated "as having 2 (not 7) ruby text boxes to be aligned with 3 base text boxes". Which implies a definition of glyph area that treats a pinyin word as a single unit.

That would mean that for spaceBetween you'd see

|jay    chou| 

rather than

|j a y  c h o u|

Which is correct?

[css-meeting-bot]

The Working Group just discussed Handling non-kana text for rubyAlign with spaceAround or spaceBetween ttml2#251, and agreed to the following resolutions:

• RESOLUTION: We will create tests to verify this behaviour and will be open to implementation feedback based on the results of those tests during CR.

The full IRC log of that discussion

<nigel> Topic: Handling non-kana text for rubyAlign with spaceAround or spaceBetween ttml2#251
<nigel> github: https://github.com//issues/251
<nigel> Glenn: This comes back to the definition of glyph area!
<nigel> .. @r12a asks which of the two is correct. I would say that the first one is preferred. I can
<nigel> .. see how he is asking if the sequence of three base latin characters j a y would be treated
<nigel> .. as a single glyph area. Ideally we would have a note or some language that says that for
<nigel> .. scripts other than... The real problem is that the rubyAlign language makes use of the
<nigel> .. glyph area counts, and if you don't know what a glyph area is I can see how that would
<nigel> .. lead to confusion. The natural interpretation for latin text is that each latin base character
<nigel> .. is a separate glyph area, arguing for the second treatment. From a user perspective you
<nigel> .. would want to see the first one.
<nigel> Cyril: According to the definition of glyph area today, how many do we have, 2 or 7?
<nigel> .. In #281 r12a was talking about Arabic words and asking essentially the same question.
<nigel> Glenn: Yes. I can see the question.
<nigel> Cyril: I get the sense that we need some technical change here, not just an editorial one.
<nigel> .. How do we deal with the comment? Are we prepared to let this out in CR1 and possibly
<nigel> .. improve it in CR2?
<nigel> Nigel: Are we saying that @r12a's second rendering is correct by the current definition and
<nigel> .. we are happy to leave it at that even though it may not be ideal?
<nigel> Pierre: Happy with that.
<nigel> Cyril: +1
<nigel> .. Can we respond saying we will prepare test vectors testing this and will deal with any
<nigel> .. implementation feedback based on those?
<nigel> Glenn: +1
<nigel> Pierre: +1
<nigel> RESOLUTION: We will create tests to verify this behaviour and will be open to implementation feedback based on the results of those tests during CR.

[nigelmegitt]

There's no further action for this ticket, as far as I can tell, given #251 (comment) so I'd like to close it, noting that we have not yet created the tests, and in general a lot of work is needed to create tests across the board.

[r12a]

I think that resolving the ambiguity around the term 'glyph areas' is also important for resolving this issue.

[nigelmegitt]

@r12a the definition has been updated and hopefully improved in the latest ED - see https://w3c.github.io/ttml2/index.html#terms-glyph-area for details.

[r12a]

We will create tests to verify this behaviour and will be open to implementation feedback based on the results of those tests during CR.

What was the implementation feedback from the tests during CR?

[skynavga]

As far as I recall, there was no specific feedback on this point. This spec is now in PR. If any new issues arise, we expect to mark them for processing in a subsequent TTML2 2nd Edition.

[skynavga]

Looking at this a little further, it looks like we have 5 specific ruby align presentation tests, but none of them exercise non-ruby kana text. So, it looks like we (inadvertently) failed to create specific tests to address this issue. I suggest we keep this issue open, and move it to the 2ed Milestone for further processing. I will do that now, but if there is an objection, let me know.

[css-meeting-bot]

The Timed Text Working Group just discussed Handling non-kana text for rubyAlign with spaceAround or spaceBetween ttml2#251, and agreed to the following:

• SUMMARY: @skynavga to raise an issue on w3c/ttml2-tests for creation of this test.

The full IRC log of that discussion

<nigel> Topic: Handling non-kana text for rubyAlign with spaceAround or spaceBetween ttml2#251
<nigel> github: https://github.com//issues/251
<nigel> Nigel: @r12a reopened this. It looks like we agreed to make a test for this case, but I do
<nigel> .. not think I could find one in the ttml2-tests suite.
<nigel> .. Glenn suggested moving it to 2ed milestone.
<nigel> .. I also wondered if we could create a test that's not formally part of the Implementation
<nigel> .. Report test suite, to complete this action.
<nigel> Glenn: We have some tests in the test suite that are excluded from the IR via an exclude
<nigel> .. flag in the manifest files.
<nigel> .. The case that that issue involves is what do you do if you have ruby that consists of say
<nigel> .. latin words, or English words, or pinyin translations of Chinese that are not kana or kanji
<nigel> .. characters, that is, the ruby text is not kana/kanji. In the context of rubyAlign, for example
<nigel> .. spaceAround, spaceBetween, where do you put the space, do you parse out words and
<nigel> .. put the space around them like with normal text alignment justification spacing or do
<nigel> .. you put them between the individual glyph areas for the roman characters, i.e.
<nigel> .. basically letter-spacing. That was the original issue that was filed. We said we would
<nigel> .. create some tests but we unintentionally did not do that. This fell through the cracks
<nigel> .. I guess because the issue had been closed out. So I think we can create some tests for
<nigel> .. it. The question about the tests in my mind is their artificial nature. We don't have any
<nigel> .. subtitles that might actually use these, at least I have no real world data about subtitles
<nigel> .. using them. I have to admit it is admissible in the spec which is vague on the subject.
<nigel> .. The technical point of the issue remains valid.
<nigel> Nigel: Can anyone volunteer to take an action to create those non-IR tests?
<nigel> Glenn: I don't see any option but to do this in 2ed.
<nigel> Nigel: We don't have to make any change to 2ed unless there's feedback requesting it.
<nigel> .. For now it is enough just to create the tests.
<nigel> Glenn: Are we going to solicit new feedback from implementers that we haven't already
<nigel> .. done before? There's only one implementation that reported on rubyAlign presentation
<nigel> .. in the IR, which is for TTPE. If we don't do anything new then it would fall into Skynav's
<nigel> .. camp to address this which means I have to look at our internal schedule. It's not a
<nigel> .. priority item for us because nobody is clamouring for Pinyin and Ruby in subtitles right
<nigel> .. now. I would rather push it off a little bit until we get into 2ed processing.
<nigel> Nigel: Can I suggest we create an issue on the ttml2-tests repo to create this?
<nigel> Glenn: Sure, that's reasonable. I'll create a TTML2 2nd Ed milestone under that repo too
<nigel> .. and label it under that since I have already released the test suite under the PR milestone.
<nigel> Nigel: Ok.
<nigel> .. Any other points to add on this topic?
<nigel> SUMMARY: @skynavga to raise an issue on w3c/ttml2-tests for creation of this test.