Minor enhancements for Japanese subtitles

[cconcolato]

While finalizing TTML2, we postponed some of the features regarding Japanese support to a next version as they were considered edge cases. We should revisit those for TTML.next. This includes:

• line wrapping with rubyOverHang and overhangClass
• positioning with rubyOffset
• overflow

Additionally, while left-justification of Japanese content is possible in IMSC1.1 with multiRowAlign, it is not possible in TTML2. This should be revisited also.

The features should be aligned with CSS when possible.

[skynavga]

1. For overflow, I presume you mean rubyOverflow, which we had defined in the June 2017 WD [1]?

2. Could you elaborate on what you mean by "left-justification of Japanese content ... is not possible in TTML2"? Left justification is certainly supported on p, via tts:textAlign left or start. Perhaps you are referring to having it apply to a span having inlineBlock display semantics?

[1] https://www.w3.org/TR/2017/WD-ttml2-20170630/

[cconcolato]

1. Yes, I meant rubyOverflow.

2. I meant when you want the overall text to be aligned in the region, based on the longest line, but the other line to be aligned at the beginning of the longest line. It it sometimes referred to as "Chidori-style placement" as in Netflix guidelines.

[nigelmegitt]

@cconcolato the way you described Chidori-style placement doesn't seem to fit with what you linked to in the Netflix guidelines, but it sounds exactly the same as ebutts:multiRowAlign - is it in fact the same?

[cconcolato]

@nigelmegitt yes, that's what I said in the initial issue description.

[nigelmegitt]

@cconcolato ah yes so you did, I see. Then we have an interesting question about if we actually need to bring it into the base TTML specification or if it is in fact acceptable to have it available within a profile effectively as an extension. Handling of EBU-defined extensions in future should explicitly be a topic of our upcoming joint face to face meeting.

[skynavga]

My position is that a feature is not in TTML unless it is in a TTML namespace, so the ask here would seem to be for a tts:* homed style property.

[cconcolato]

As discussed in a previous call, I'm not necessarily asking for multiRowAlign to be in the TTML namespace (although it would make things simpler in some sense). The ask would be first that the feature becomes part of TTML, documented in the TTML specification. Having to compile multiple specs to implement is really a pain. Also from a maintenance perspective of the spec, it makes it easier. A question that could be asked to EBU is whether they would accept to release the copyright on this feature and let W3C copy the text in its specification, as is (modulo some editorial integration, without namespace change nor technical change).

[nigelmegitt]

Yes, we can certainly ask EBU that. @frans-ebu and @TairT one for you to note.

[skynavga]

As long as a new style property to support this is placed in the tts:* namespace, then I can accept it. As for copyright, copyright applies to the exact form of an expression, and we would not be copying that form out of the EBU spec. We would rehome its namespace, possibly rename it, and write new specification prose intended to behave in a similar manner. So, while copyright isn't an issue, IPR is nonetheless an issue, so we would have to follow W3C policy in this regard.

[nigelmegitt]

We will need to revisit the previous discussion about duplicating style attributes and how this serves document authors. There's apparently zero benefit to document authors in changing their practices just to change an attribute qualified name and do nothing else, only a cost. I'm not saying I have an answer here at this time, but the argument is not straightforward.

Similarly if it becomes valid to include both the existing ebutts prefixed attribute and a functionally overlapping tts prefixed attribute then we would need semantics to resolve the functional overlap.

It is important to have a sensible transition path for users and implementers.

[skynavga]

Just for the record, my objection to merely importing this feature while retaining it in the ebutts namespace are as follows:

• TTML does not at this time rely on any non-W3C or non-TTWG defined namespace with the exception of those defined by XML and XLink, which are core W3C technologies;

• TTML has a long-standing practice of importing attribute names from various sources (XSL-FO, CSS, SVG, SMIL), and in each and every case (except with XML and XLink), has normalized those names (into camel-case), placed those names in a TTML controlled namespace, written new normative prose to accompany the attribute, and documented the derivation in an appropriate appendix;

• Normative references in TTML are carefully designed to contain no normative reference loop; however, introducing an attribute from an EBU specification that normatively references TTML will introduce such a loop;

• TTML already permits authors and implementations to make use of attributes in foreign namespaces, including those defined by EBU specifications; therefore, usage of ebutts:multiRowAlign is already permitted without further specification change;

My conclusion is that if we are to entertaining adding this functionality directly to TTML, then there are no grounds for diverging from the existing practice indicated above, and that doing so would introduce an singular anomaly in TTML, both in process and substance, and that the result would weaken the integrity of TTML and the TTML family of specifications, both within the W3C and without.

[palemieux]

I do not share the concerns expressed by @skynavga, which appear to be largely non-technical. In particular, circular references can be easily avoided by coordination between organizations.

IMSC already normatively references EBU-TT for the purpose of requiring support for ebutts:multiRowAlign and ebutts:linePadding, and it would therefore be straightforward to move these definitions from EBU-TT to IMSC -- assuming EBU is open to such an approach and that adequate coordination can be arranged.

[skynavga]

IMSC is a derivative specification and was explicitly designed to directly employ foreign, non-W3C namespaces. So it is consistent and proper that IMSC should directly employ foreign namespaces. However, different rules and conventions apply to TTML as a primary language specification.

…

On Fri, Jan 18, 2019 at 12:12 PM Pierre-Anthony Lemieux < ***@***.***> wrote: I do not share the concerns expressed by @skynavga <https://github.com/skynavga>, which appear to be largely non-technical. In particular, circular references can be easily avoided by coordination between organizations. IMSC already normatively references EBU-TT for the purpose of requiring support for ebutts:multiRowAlign and ebutts:linePadding, and it would therefore be straightforward to move these definitions from EBU-TT to IMSC -- assuming EBU is open to such an approach and that adequate coordination can be arranged. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb_ZWMa7oxCvqiuxs3f_pgnxhWtisks5vEhyygaJpZM4ZbV95> .

[nigelmegitt]

OK we seem to have restated previous positions fairly briskly, and it doesn't seem that anything has changed. I would encourage us not to try to bash our heads against the wall on this one for too long, since I think there's little hope of finding a resolution, recalling the discussion about a year ago.

Instead, can we think of creative alternatives, something that would be a genuine benefit to users and implementers, and maintain the elegance of the specifications? I don't have a specific proposal right now but some points that seem salient:

• We're thinking about modularising the TTML specification
• We are looking for ways to get better alignment with CSS
• We are looking for ways in which externally defined styling extensions can fit with the TTML styling model better
• CSS is looking at how to address the multiple row alignment issue
• CSS through the Houdini work is looking at layout definitions, i.e. the ability to define a layout algorithm.

[andreastai]

@cconcolato Do you need the solution in TTML2 or is it sufficient to have it in IMSC? Do you use TTML outside of the IMSC subset?

[cconcolato]

Japanese features have been defined in TTML2. Improved/clarified features (for additional use cases/edge cases) should also be defined in TTML2, even if we'll probably use them in IMSC context.

[css-meeting-bot]

The Timed Text Working Group just discussed Minor enhancements for Japanese subtitles tt-reqs#12, and agreed to the following:

• RESOLUTION: Proceed with additional Japanese language features in a TTML3 module in close coordination with the CSS WG.

The full IRC log of that discussion

<nigel> Topic: Minor enhancements for Japanese subtitles tt-reqs#12
<nigel> github: https://github.com//issues/12
<nigel> Nigel: If CSS has done this then we should do it.
<nigel> Cyril: We should work with CSS and adopt what they do.
<nigel> .. I'm not asking for doing this without CSS support.
<nigel> .. This is mostly about edge cases not fundamental Japanese language support.
<nigel> Nigel: So Cyril does that mean you will take the lead with CSS WG to get these defined?
<nigel> Cyril: I will try!
<nigel> Glenn: This is the case where a module to define this would be appropriate and can be tracked to a
<nigel> .. timeline that matches what CSS is doing. We can do things in parallel with modules without having to
<nigel> .. waterfall it all together.
<nigel> .. Then we can explore with CSS their interest in solutions, and propose something to them and see how
<nigel> .. they react to it. I have no strong feeling on whose solution we adopt, the one we came up with or something new.
<nigel> Nigel: Anyone want to speak against doing this?
<nigel> RESOLUTION: Proceed with additional Japanese language features in a TTML3 module in close coordination with the CSS WG.