Add display alignment and fix timing in examples in Appendix S (#459).

[skynavga]

Closes #459.

[nigelmegitt]

Built version is at https://rawgit.com/w3c/ttml2/issue-0459-appendix-s-build/index.html

Diff is at https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fttml2%2Findex.html&doc2=https%3A%2F%2Frawgit.com%2Fw3c%2Fttml2%2Fissue-0459-appendix-s-build%2Findex.html

[nigelmegitt]

The issue discussion and resolutions were possibly unclear here, but I think we reached the point where we agreed only to change the roll up example in S.2. The change made here isn't quite right, so requesting reversions to the paint on and pop on examples and a fix to the roll up example.

[nigelmegitt]

Modifying the Pop On example makes no difference to this example, and we agreed not to change this one. I think it better to revert the changes to this example. The descriptive paragraph above includes:

Each paragraph is non-overlapping in time and appears in the same single row of its targeted region.

[nigelmegitt]

Shouldn't the additional <br/> elements be at the beginning of all but the first <span> rather than at the end of all of them? Otherwise the first <span> is never on the bottom line, since the <br/> always bumps it up one. The text is only ever bumped up by the next line becoming active.

[skynavga]

@nigelmegitt an empty line area at the after edge of a block is always elided, so using <br/> at the ends of lines suffices (and looks better in example code).

[nigelmegitt]

@skynavga I wondered if that is supposed to be the case. I'm aware that some documents use multiple trailing <br/>s in a region with tts:displayAlign="after" to position subtitles some lines off the bottom of the region. Does that mean that never works?

This technique is one of the strategies defined in EBU Tech3360 - see the example at §4.5.6.3.1 for example. This suggests that at least some implementations do not elide in the way that you say.

Since this is unclear in the world (regardless of what is correct according to any specifications), I would prefer to avoid the confusion, by moving the <br/>s in this example to go at the beginning of each <p> other than the first one.

[nigelmegitt]

I think the consensus was not to modify the paint on example. The presentation does depend on the value of displayAlign but demonstrating the paint on effect does not. It works equally well with before and after but arguably, since the region is defined near the top, the default before makes sense here. Otherwise the example gets mixed with roll up. I think it better to revert this change.

[skynavga]

@nigelmegitt please check with fixes

[nigelmegitt]

Recent changes are helpful, however since we discussed this at the f2f I've found evidence (mentioned in the comment) about usage practice that suggests it would be useful to change the roll up example's <br/> positioning.

[nigelmegitt]

@skynavga I wondered if that is supposed to be the case. I'm aware that some documents use multiple trailing <br/>s in a region with tts:displayAlign="after" to position subtitles some lines off the bottom of the region. Does that mean that never works?

This technique is one of the strategies defined in EBU Tech3360 - see the example at §4.5.6.3.1 for example. This suggests that at least some implementations do not elide in the way that you say.

Since this is unclear in the world (regardless of what is correct according to any specifications), I would prefer to avoid the confusion, by moving the <br/>s in this example to go at the beginning of each <p> other than the first one.

[skynavga]

@nigelmegitt on further checking, I see that we map br to

<fo:character character="&#x000A;" suppress-at-line-break="retain/>

which has semantics

retain
The glyph area generated by the fo:character shall be placed in the area tree whether or not it first or last in a line-area.

I need to verify behavior on an XSL-FO implementation, but it may be that the start of line or end of line will produce the same behavior.

[nigelmegitt]

Thanks for digging into that @skynavga - this confirms my view that we need to remove trailing <br/>s from the example.

[skynavga]

@nigelmegitt please check

[nigelmegitt]

Thanks, looks good to me. Good to learn something too.