W3C

Timed Text Working Group Teleconference

19 Oct 2017

See also: IRC log

Attendees

Present
Nigel, Cyril, Pierre, Mike, David_Ronca, Thierry
Regrets
Andreas
Chair
Nigel
Scribe
nigel

Contents


<scribe> scribe: nigel

This meeting

Nigel: Today, we have TPAC planning (if there is any - reminder there are 2 calls between
... now and the face to face meeting).

David_Ronca: [will be present for first hour only]

Nigel: That's apart from today.
... We should review Cyril's compatibility document, and look at TTML2 Wide Review issues,
... to work out our disposition.
... For IMSC, there were some comments raised on the vNext Requirements doc to go through.
... Then hopefully resolve to publish as a WG Note
... We have some pull requests to look at for TTML2 also.
... I don't see anyone who can discuss WebVTT today but we will try to get to that if they join.
... Any other topics to mention, or other business?

group: [no]

Pierre: [will have to drop off after the first hour too]

Cyril: In IMSC 1.1 we should revisit the issue about subsetting of TTML2.

Pierre: I thought that was the primary topic.

Nigel: I see this as two questions (or three):
... 1) Compatibility between TTML1 and TTML2,
... 2) Inclusion of IMSC features in TTML2
... 3) Subsetting of TTML2 to generate IMSC vNext

TPAC planning

Nigel: I don't think there's anything to do here? Not everyone has put their names on the wiki yet.

TTML1 and TTML2 compatibility in practice

Cyril: I want to go through the document, but not in too much detail (that's for offline).
... Just for recapping: I did a side by side manual comparison of TTML1 and TTLM2 to
... identify changes, and then assessed if they are critical for compatibility, i.e. whether an
... TTML1 document would be rendered by a TTML2 processor in an acceptable way according
... to TTML1, taking into account fonts, rendering etc.
... I hope you all had a chance to look at the document.
... My general feeling after this is that there are some subtle differences but either TTML2
... is more precise because TTML1 was ambiguous, in which case it's okay, TTML2 rendering
... would be acceptable as a TTML1 rendering; OR there are features that are different, but
... for features that are specified in TTML1 but not used in IMSC1, like pixelAspectRatio,
... that is, the features with differences are not actually used.
... The problems I identified are the orange ones - pixelAspectRatio, direction (TTML2
... fixes a TTML1 problem, maybe a good candidate for TTML1 Third Edition), overflow - a
... MUST statement has been removed in TTML2, then a section on computed style set
... processing, where a filtering step in which TTML1 does not filter <set> elements but
... TTML2 does filter them, so the computed value would be different. My understanding is
... that's a problem in TTML1, so could be fixed in TTML1 Third Edition. That's it.

Nigel: For `<set>` exclusion I think that was an omission in TTML1.

Mike: This all came about to ensure IMSC 1.1 compatibility with TTML2. The exclusion of
... set becomes a problem.

Nigel: You should check the impact of this - I believe it was an oversight in TTML1 and
... you could say it was implied.

Pierre: We came to a decision on this - see ttml1#216 - the plan is to include it in TTML1
... Third Edition. It's just a bug in TTML1, and would have been in TTML2 if we had not found it in TTML1.

Cyril: I'd like to know if anyone thinks I've missed something?

Pierre: A good thing to check is if every difference has an issue in TTML1.

Cyril: I'll do that to make sure.

Pierre: If yes then you have agreement, otherwise we should go over them.

Cyril: Assuming I haven't missed anything, do you share the feeling that there's no
... significant gap between TTML1 Third Edition and TTML2 and that the renderings can be compatible?

Pierre: That was the goal from the beginning. So I agree with you - that's why those issues
... were filed against TTML1 and TTML2 was corrected accordingly.

Mike: I'm not sure what "significant" means here - we've identified some areas that could
... be done differently depending on which version is being used.
... We still need the [statement about no differences]

Nigel: Why do we need that statement? Put another way, if TTML1 is ambiguous and
... TTML2 is less ambiguous, is that a problem?

Mike: If we publish TTML1 Third Ed and then the differences are removed, it's not a problem.

Pierre: I'm with Mike in the sense that we should capture that goal, because we seem to
... keep coming back to it even though everyone agrees that its the goal. I don't understand
... the reluctance.

Nigel: My reluctance is "unintended consequences" - especially if there are multiple goals
... and they could come into conflict, it's a hostage to fortune if we state them; it's the work
... of this WG to resolve them, and if we intend TTML1 Third Edition and TTML2 to be
... compatible in the way that we agree, we just make it so, without having to state it in the spec.

Mike: This isn't about us, it's about the readers of the spec.

Cyril: There's section §3.4.2 in the spec about backwards compatibility.

Mike: I had an action to propose some wording.

Nigel: That's issue ttml2#458.

Cyril: Where's the actual text proposal?

Nigel: The only tonal difference I want to see is that we don't state a guiding principle
... but a statement of our understanding of what we have achieved.

Cyril: Why don't we put something like I put in the top of my analysis document, that
... a TTML1 document processed by a TTML2 processor would produce an acceptable
... result when processed by a TTML1 Third Edition processor.
... I don't care where that goes - in §3.4.2 or in the Scope.

Nigel: We have a dependency on TTML1 Third Edition here, which needs some work on it.

Mike: We're not jumping to TTML2 Rec tomorrow so we have some time.
... I know Glenn has done some work on TTML1 Third Edition.

Pierre: May I encourage the Chair to follow up with Glenn offline?

Nigel: Yes, I will.

Mike: It doesn't change the principle here - we can still state the same principle regardless
... of TTML1, because that's our intent.

Cyril: I agree.
... If the wording is about TTML2 being designed for acceptable results except for edge
... cases X, Y and Z would that work for you Nigel?

Nigel: Yes, sounds good.

Cyril: Everyone else?

Mike: Yes, sounds good.

Cyril: I'll propose text in ttml2#458.

TTML2 Wide Review

action-508?

<trackbot> action-508 -- Thierry Michel to Check if there are editorial/substantive labels for ttml2 issues and add if not. -- due 2017-10-12 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/508

Thierry: I don't think I've done that yet.

IMSC

Pierre: There's been a lively discussion on the reflector; now we've addressed the TTML1/TTML2
... compatibility, the outstanding issue is for IMSC 1.1 to be a subset of TTML2. It's been in
... the requirement of IMSC 1.1.

Cyril: Please clarify "subsetting"? What is "subset"?

Pierre: It means it doesn't introduce any extension, it only constrains features of TTML2.
... I thought that was the goal, but maybe that's the first question. Then there are two options
... for getting there. One is to hoist into TTML2 the syntax of IMSC 1.0.1; the other is to
... deprecate the syntax of IMSC 1.0.1 and use the syntax of TTML2.
... First I want to check that IMSC 1.1 is supposed to be a subset of TTML2?

Cyril: Yes

Mike: It's contingent on the previous discussion and arriving at some language.

Nigel: I'm concerned both about the cleanliness and tidiness of TTML2 and the difficulty
... of content providers creating documents that work in current IMSC 1.0.1 players and not
... having to produce multiple flavours of the same document.

Pierre: What about IMSC 1.1 being a pure subset of TTML2 with the exceptions of IMSC 1.0.1
... features that are deprecated for backward compatibility. That's what the requirements
... currently state.

Cyril: I don't understand what this means.

Pierre: Take any IMSC 1.0.1 extension, say ittp:aspectRatio - we have two options, one to
... import into TTML2 the syntax from IMSC 1.0.1, and stop there; the other option is to
... support but deprecate the IMSC 1.0.1 feature and support the TTML2 feature. Those
... options exist for every extension.

Nigel: I would also state what the mapping to the new syntax is and what the rule is if
... both are present.

Pierre: It's even more complicated - fillLineGap doesn't say the same thing in TTML2 as
... in IMSC 1.0.1.
... For each extension, we can figure out what we want to do.

Nigel: Seems reasonable.

Pierre: I think the goal is for IMSC 1.1 to be a subset of TTML2.

Nigel: If we want to end up with IMSC 1.1 extension features having a mapping to TTML2
... then we could do that either by choosing the option and putting into TTML2, so TTML2
... can support IMSC 1.0.1 syntax, or we could state the rules directly into IMSC 1.1 and not
... add the extensions into TTML2.

David_Ronca: I think I'm with Pierre that we can add the IMSC 1.0.1 features to TTML2 and
... use a deprecation model.

Nigel: So you'd put the IMSC 1.0.1 extension features in TTML2 as deprecated?

David_Ronca: No, I don't think they need to be in TTML2.

Nigel: So you'd put the deprecation language in IMSC 1.1 then?

David_Ronca: Yes because the extension features wouldn't be in TTML2.
... There are two ways forward, one pure TTML2 and one backwards compatible with IMSC 1.0.1
... and they would both be supported by an IMSC 1.1 processor.

Pierre: Just to clarify, you're not objecting to move extensions into TTML2. right?

David_Ronca: It would be weird to put ittp:aspectRatio into TTML2 but for things that don't
... exist in TTML2 they could be added.

Pierre: I'd like the flexibility to deal with each extension one by one.

David_Ronca: I agree with that. I'd expect TTML2 aspect ratio to have equivalent functionality
... to IMSC 1.0.1 ittp:aspectRatio, and not have both in TTML2.

Pierre: At TPAC we will have to ensure that the TTML2 semantics achieve what is in IMSC 1.0.1
... I'm proposing taking each extension one by one.

David_Ronca: I agree we have to do it that way.

Nigel: I think the result of that is that IMSC 1.1 would be a subset of TTML2 with the
... exception of deprecated features.

Cyril: yes

Pierre: That's what the requirements say.

Cyril: And for each deprecated feature there is a mapping to a TTML2 feature.

Pierre: Each one may take some discussion.

Cyril: There are only 6 right?

Pierre: As a result of this exercise some changes will be needed in TTML2.
... I'm particularly thinking about fillLineGap. There have been some exchanges about that
... in IMSC 1.0.1 and having different semantics in TTML2 would be really damaging.
... My plan is to proceed with a game plan for the group to review for each extension.

Nigel: Sounds good.

Cyril: Mike, are you still concerned that an IMSC 1.1 document with tts:disparity might be rendered differently?

Mike: Given the history I'm sceptical but I'm also optimistic that you will come up with the right language!

Cyril: Ok

Add equivalent CSS properties to style attributes #406

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

Nigel: A couple of things here. First, I opened a Pull Request for review by anyone who can.

Pull request

Nigel: And Cyril, you found transform::skew for fontShear.
... There are two actions. First, to update the CSS Requirements wiki to point to it;
... second to create an issue linking to #406 mapping fontShear to transform::skew.

Cyril: I will create that issue.

Nigel: I don't mind doing the work to add it to the pull request.

Cyril: How can we review the pull request?

Nigel: I committed the regenerated HTML so it can be reviewed, so you can open it at:

https://rawgit.com/w3c/ttml2/178659af16ee4b8514adc7f16ea1ca786fcf38a1/spec/ttml2.html

Cyril: Great, thank you.
... I'll have to review that.
... So in principle you're building this annex based on the wiki page?

Nigel: Yes with the additional filter of the CSS 2017 Snapshot so I check each feature
... against the latest snapshot version of the spec.

Cyril: At some point there should be a top level thing in the wiki page pointing to the
... new section in TTML2 in case they diverge.

Nigel: Good idea, when we've merged the pull request.
... However it's much easier to read in the wiki page so it might be worth updating.

Cyril: just having a sentence pointing to the more accurate information would be good.

Nigel: +1
... On this pull request I'd be interested in any suggestions for better formatting.
... The new section N.2.1 has a bunch of small tables, which blend into each other a bit.

Cyril: Yes it's not very compact.

Nigel: I agree - it has the right information in it I believe, but I don't like how it looks.

Reference CSS color semantic #413

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

Nigel: It looks like Glenn doesn't want to add anything, but I don't know why we don't
... just align with the CSS set while also keeping the additions already defined in TTML1.

Cyril: Eventually we should have the same list as in CSS, so we may need to ask CSS to add some new names.

Mike: I don't see any harm, and would be happy to get to alignment.
... Taking out named colors would have no benefit. It's trivial enough to translate the
... handful of named colors into the sRGB hex representation.
... §4.2 of the SVG 1.1 spec has a big table of named colors.

Nigel: I think it doesn't include transparent.

Mike: It would be a disservice to remove named colors in TTML2.

Nigel: +1

Mike: It would make TTML1 documents non-conformant that would be a bad idea.

Cyril: SVG supports CSS2 plus an expanded list of names. I think it should not be too difficult
... to have the CSS WG adopt the SVG color keywords. I might be wrong!
... On top of these we're just defining transparent, because there's no alpha channel defined
... in the SVG keywords.

Mike: We have to be careful about defining transparent because it is the initial value of the
... tts:backgroundColor.

Nigel: I think we have consensus to get alignment with the CSS color set while not removing any existing colors.

Mike: I'm okay with that, if the goal is to better align with CSS.

Pierre: I'm not against it but I see no advantage in adding "orange'.
... Recall that as long as there is a delta between CSS and TTML a lookup table is still needed.
... I would rather not touch it.

Nigel: I think it's about direction of travel.

Pierre: Adding "orange" now would cost implementors time for no benefit, because we still
... wouldn't be aligned with CSS, so that's no benefit now.

Nigel: I can see that, maybe we should go to CSS WG and ask them to align named colors
... with SVG, and then defer any change to TTML until that decision has been made.

Cyril: I like that.

Pierre: +1

SUMMARY: We will not add "orange" now but ask CSS WG to align named colors with SVG and then look at this again.

Region constraints are the same as in IMSCvNext #262

github: https://github.com/w3c/imsc/issues/262

Nigel: this is also about imsc#260
... The issue here is about the differences between IMSC 1.0.1 and IMSC 1.1 and about region constraints.

Pierre: The idea is to say IMSC 1.1 is IMSC 1.0.1 verbatim unless there's a divergence.
... Whatever text helps I'm happy to put that in.

draft proposal

Cyril: In the light of the discussion on TTML2 we will need to change that section.
... We said we'd go for a model where IMSC 1.1 imports features from IMSC 1.0.1 and TTML2
... and the IMSC 1.0.1 extensions to TTML1 are deprecated where there are alternatives in TTML2.

Pierre: That's a different issue but yes.

Cyril: The compatibility with 1.0.1 documents is true but is not always the preferred way, in the case of deprecations.

Pierre: #260 is handled by the appendix [L2]

Cyril: The pull request is okay to satisfy the two issues.

Pierre: except for Nigel's concerns about the new text.
... If we removed that new text would the issues still be addressed?

Cyril: I would prefer for each section a sentence saying "this is the same as in IMSC 1.0.1"

Pierre: We don't do that in TTML, and some sections are numbered.
... Purely for an implementor, they should be able to review the differences.

Nigel: Can I propose a minor change of wording, to:
... Relative to [ttml-imsc1.0.1] any additions or deprecation of features are summarised at Appendix L.

Cyril: Okay, good.

Pierre: Fine with me. I'll change it.

Cyril: I'll raise a separate issue to clarify the relationship with TTML2 in the Abstract, so it doesn't get lost.

Pierre: OK

SUMMARY: Update wording in Abstract.

Is #ruby necessary, or #ruby-non-nested sufficient? #2

github: https://github.com/w3c/imsc-vnext-reqs/issues/2

Nigel: I was able to ask someone from NHK in Japan about this yesterday and he provided
... a data point that in his opinion ruby on ruby is never used. He did think there may be a
... use case for textEmphasis on ruby though.

IMSC vNext requirements

Nigel: There's no issue for this yet, but the ARIB-TT use case mixes image and text in the
... same document, and my contact at NHK said that's really important for them, so this
... may be relevant for us thinking about image vs text profile.

Mike: Currently that's forbidden of course. At odds with this are all the changes we're
... making in IMSC 1.1, I think, that it will obviate the need for image profile at all.

Nigel: Good point, however his use case is that even in subtitles and captions they place
... e.g. company logos next to the names, so imagine, say a Dolby logo or a Nike swoosh etc
... placed next to the company name.
... Apparently this is a matter of reflecting current practice.

Mike: That's an interesting situation - taking it to the extreme we could merge the two
... profiles.
... It would simplify the spec actually.
... In US closed captions there's a symbol that folk came up with that doesn't exist in Unicode.

Nigel: Did they ask to add it to Unicode?

Mike: I don't think so. It's 2x "C" characters in the symbol to represent closed captions.
... These days people just use (CC). Anyway it would be a way to implement it.
... It's an interesting use case to put a non-Unicode symbol in on the fly.

Pierre: Another example I've been given in SE Asia is a symbol for a ringing telephone when
... there's the sound of a telephone ringing. With a simplistic left-right-left animation.

Mike: Sounds like we need to file it as an issue and discuss it more.

Nigel: Yes, I will.

Pierre: It would be really good to get ARIB to contribute.

Mike: Especially if we have to merge Text and Image profiles to achieve it.

CLDR

Nigel: The same person suggested one way forward is to try to add the caption characters
... into ISO 10646, which would have to be done quickly.
... My sense is that the status quo is not ideal but is okay.

Pierre: It's not been a complaint so far.

Mike: Is there an issue for this?

Nigel: No, there's no action to take until CLDR does something.
... The issue here is that IMSC 1 Appendix B refers to CLDR and we asked Unicode to keep
... a record of code points commonly used in subtitles and captions as part of the CLDR
... initiative, but they haven't really dealt with the request yet, at least we haven't seen any
... usable outcome.

Meeting end

Nigel: OK, thanks everyone, see you next week. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/10/19 16:20:41 $