Timed Text Working Group Teleconference

18 Jan 2018


Andreas, Cyril, Glenn, Nigel, Pierre, Thierry


<scribe> scribe: nigel

This meeting

Nigel: For today we can dive straight into the actions, pull requests and issues. I propose
... to do TTML2, TTML1, IMSC, IMSC vNext Reqs in that order. And to include the issues
... that Pierre sent links to earlier.
... Any other business or particular requests for things to cover today?

Glenn: Could you comment on the issue regarding static files you just posted?

Nigel: [discussion of issue and reason for needing to serve images for use in the wiki]

Glenn: You could use rawgit to serve from the master branch.

Nigel: Yes, that could work.
... While we're on build scripts, I noticed that we need the build script to validate non-spec
... artefacts like example XML files too, and this is true for both TTML1 and TTML2.
... I just sent some stats around - it is clear that we will not be able to close the
... currently open TTML2 issues within our current process and have a CR ready by the
... end of the month. So we have to defer issues or allow ourselves a couple of weeks of
... slippage of the CR.
... Can I just check with Editors if there is any likelihood of a change in the rate of
... progress in tackling issues compared with what you've done in the last few months?

Cyril: I'm travelling but plan to contribute.

Glenn: I hope to increase my rate over the next couple of weeks. We have the option to
... agree to merge pull requests in meetings ahead of the review period.

Pierre: I count 6 non-editorial issues which I believe we can resolve by the end of the month.

TTML2 Actions


<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

Glenn: There are already editorial and substantive labels, plus a third "no change" which
... I added, where I anticipate no change to the spec, e.g. changes to build process files
... so I think you can close 508. It's no longer an issue.

Thierry: I didn't go through it but I'm fine closing it.

close action-508

<trackbot> Closed action-508.

Glenn: By the way I tend to put those labels on issues when they first get posted based on
... my anticipation but sometimes they change in actuality based on the implementation.
... I review those labels when closing issues off.

Consider aligning initial values of tts:position and tts:origin. ttml2#551

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

Cyril: I added it to the agenda but expected some internal feedback and have not had any
... yet so I propose to defer it. Does the group have any position on this issue?

Glenn: If we defer it we end up with two different initial values as apply to region.

Pierre: This is not a big fix.

Nigel: Are we all agreed that the initial value of position should be "top left" to align with
... the initial value of origin, for regions?

Glenn: I think it makes more sense to have "center center" but it introduces the disparity.
... Since users can add an initial element it is easy to change so I'm happy with making
... it "top left".


Nigel: Do we need to qualify this for regions and have a different treatment for the root element?

Glenn: There is some normative language in the spec that applies it to tt but on reviewing
... it recently I noticed it was not applicable to tt, so there is that discrepancy to deal with -
... does it apply to tt or not? Does it position the root container region within a positioning
... area such as the related media object region or some other positioning area.
... There's also the applicability of it to backgroundImage and image with respect to the
... extent of the padding area. With regard to the question of initial value semantics we
... need to have an answer that can apply to all contexts of use but we may actually end
... up saying there is an exception based on the content of use.

Nigel: It doesn't apply to image because that has the tts:backgroundPosition attribute.
... So I propose if we want a position to apply to tt then we call it something different.

Glenn: I don't like that idea - there are three similar position things in the spec. It is possible I admit.

Nigel: We possibly do not have the requirement to explicitly position the root container
... region anyway.

Glenn: IMSC1 makes the normative statement of positioning the root container region
... centered relative to the related media. That's where this feature comes from.

Nigel: Does anyone need to specify any option other than "center center"?

Glenn: There's a concept we started to discuss one time - frequently I find in letterboxing,
... especially in some of the really wide formats, the captioning is in the letter box area
... outside the active video. Right now other than using position we don't have any way
... to achieve that. We did not thoroughly discuss this issue.

Nigel: For now can we agree on position for region and open a different issue for positioning
... the root container region?

Glenn: The easiest thing to do is remove the two paragraphs and a note beneath the Percentage Based Positioning
... diagram under tts:position, after reviewing if there's anything that applies to region.
... If anything does apply to region I would leave that present.

Cyril: Regarding the initial value I'm fine. Re the use on the tt element, how does this
... relate to the alignment we discussed with the related media object that is also in IMSC 1.1?
... Is it configurable in IMSC 1.1?

Pierre: No the root container region cannot be configured within IMSC 1.1. Maybe a container
... like ISOBMFF might allow it to be specified.

PROPOSAL: Make the initial value of tts:position "top left" and remove the text defining behaviour of position when specified on the tt element.

RESOLUTION: Make the initial value of tts:position "top left" and remove the text defining behaviour of position when specified on the tt element.

Glenn: Where we remove functionality I have been marking as ttml.next. That applies here.

github-bot, end topic

Remove explicit animation, styling and timing from break (br) element. ttml2#552

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

Nigel: If we do this, then will it cause any incompatibilities with TTML1 documents that
... use the syntax?

Pierre: Will the prohibited content be pruned prior to validation?

Glenn: I'd say this is borderline.

Pierre: We have already disrecommended the syntax in TTML1 Third Edition.
... We can disrecommend it from TTML2 and prohibit it from a later version of TTML.

Glenn: Ok.

Cyril: I'm not sure how to implement this. Is it correct to match TTML1 and remove things
... introduced in TTML2?

Pierre: Change the disrecommendation to a deprecation.

Nigel: +1

Glenn: +1

Cyril: TTML1 did not talk about styling, just animation and timing.

Pierre: Styling and timing were added in TTML2 and need to be removed to match TTML1.

Cyril: No TTML1 has styling.

Pierre: It doesn't have timing.

Cyril: What should we do with style?

Glenn: We don't need to do anything because no style attribute in TTML1 applies to br.
... Whether the attributes are present or not is academic.

Pierre: I agree with Glenn - the only thing is to remove timing and deprecate animation.

Cyril: That's fine by me, I can do that.

Glenn: We need to check if any style is now applicable to br.

Cyril: Okay I'll check and add it to this issue if there are any.

RESOLUTION: Align the content model of br in TTML2 with TTML1 and make the recommendation about animation on br stronger by deprecating it in TTML2.

Glenn: Specifically we are removing animate, begin, dur, end, region and timeContainer.

github-bot, end topic

Do not default to px units in the absence of units on a `<length>` ttml2#561

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

Glenn: We had introduced a default unit in TTML2 to match what was in SVG. You make a
... case for not using it because it makes the potential use of a `<number>` as a syntactic
... element problematic in the case that some property admits both length and number as
... values. I don't think we have any of those right now but we could do in the future.
... TTT implements this but I'm not wedded to it strongly enough to insist on it staying in.
... We don't use `<number>` with lineHeight for example.

Nigel: This issue has 2 thumbs up.

Glenn: It will be a substantive change [adds the label]

RESOLUTION: Revert to prohibit use of `<length>` without units.

github-bot, end topic

Clarify tts:fontSize semantics ttml1#301 (pull request)

Pierre: This is awaiting a review from Glenn after the changes I made following our discussion last week.

Glenn: Okay I'll get that done today.

Pierre: Thanks - it matches TTML2 and what we discussed.

First Pass at IMSC2 to CSS Fallback imsc#218

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

Pierre: Thanks to the work done in TTML2 a lot of this is moot. My proposal is to close this
... but I think you're suggesting there be some text in IMSC 1.1 to cover the features not
... described in TTML2.

Nigel: That's correct.

Pierre: Some of those are present because there is no mapping to CSS. Is it worth saying that,
... especially since work is happening to introduce them in CSS?

Nigel: I see your point, I could live with omitting them.

RESOLUTION: Make no change to IMSC2 and close this issue.

github-bot, end topic

privacy and cross-origin policies not clear imsc#280

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

Nigel: There's been similar work on TTML2 here.

Pierre: Exactly, I want to check we're addressing w3c/ttml2#405.

Cyril: I submitted a pull for that issue - I wasn't aware of this so I'll check this text and
... take it into account.

SUMMARY: Continue with this when the TTML2 issue resolved.

github-bot, end topic

Clarify [associate region] algorithm ttml1#288 (pull request)

Pierre: I thought I'd add this to the agenda not because I have a good solution but because
... I think it is becoming increasingly risky to try to solve this within the timeframe we have.
... As we have known for a year this goes to the heart of the ISD construction algorithm.
... The benefits of solving it are minimum because most implementations don't trigger this
... behaviour. I'm getting close to suggesting that we defer this.

Glenn: I agree. The original intent was to resolve a potential ambiguity about interpreting
... a particular point 3 in the current TTML1 spec. I'm no longer convinced that there's an
... ambiguity there in any case. I'm not happy with the proposed change - going from 5 steps
... to 8 steps is the wrong direction.
... I would keep it the same in TTML2.
... We could address the potential ambiguity with a Note but I don't think it is really
... necessary. The trail of the thread documents it pretty well. Let's do nothing right now.

Andreas: I marked the original issue with a heart because that was a mechanism used at
... one point to mark issues that people wanted to discuss. It doesn't carry any particular meaning.

Glenn: The proposed language in the original issue is what we ended up implementing
... in TTX, so we've already basically implemented that recommendation.

Nigel: That's the one part that is not in the pull request!

Glenn: That's true. Part of the problem is that we have not agreed on the overall outcome
... we are trying to achieve.

Pierre: Exactly, and this has in practice hardly any impact.

Glenn: I've never had a bug report on this.

Pierre: Me neither.

RESOLUTION: Close this pull request #288 without merging.

Ambiguous definition for determination of descendant region identifier. ttml1#194

github: https://github.com/w3c/ttml1/issues/194

Nigel: See also discussion on #288 (pull request).

RESOLUTION: Close issue with no spec change.

Pierre: That's the only thing we can do now.

Glenn: Close this without prejudice.

Pierre: We should defer it - characterise it as to be fixed later.

RESOLUTION: (updated) Don't close the issue, close the pull request and Defer the issue to a later edition.

github-bot, end topic

is tts:textShadow required? imsc-vnext-reqs#13

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

Pierre: It sounds like textShadow and textOutline have different sweet spots and don't conflict.
... textShadow is supported by CSS so my plan is to support both in IMSC 1.1.

Nigel: It's a small point, but do we need to point out in the spec in an informative note why both are needed?

Pierre: Good examples as in TTML2 will show the difference. They're really different effects.

Cyril: I definitely don't want to remove textOutline because we're using it.

Pierre: I've also heard the same for textShadow.

RESOLUTION: textShadow is required, no spec change needed.

github-bot, end topic

Consider allowing images and text in the same profile imsc-vnext-reqs#4

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

Pierre: A reminder that this is IMSC 1.1 requirements.

Nigel: Right so some other version of IMSC in the future could support both image and text simultaneously.

Pierre: Exactly.
... Specifically on this issue, it is supported in TTML2, the question is if it is a requirement for IMSC 1.1.

Nigel: Playing devil's advocate here, our goal is to produce a global subtitle standard, and
... there's a concrete use case in existence already, in use in Japan, so we should support that feature.

Andreas: I'm not sure that an informal conversation is enough to add this to the requirements list.

Nigel: This may not be the most diplomatic approach - it was a genuine conversation from
... someone who came to me as Chair and asked for a feature to be requested.

Cyril: We would need to know more detail about the precise layout requirements - is it needed
... in vertical layout for example?

Pierre: It is reasonable to ask for more information.

Andreas: What does the requirement list mean? Is it the list of requirements we agree to as
... group members, or those collected from other organisations?

Pierre: It is the consensus list of requirements to drive IMSC 1.1.

Nigel: +1

Andreas: Then we need to ask if this is needed for the next version of IMSC.

Nigel: [scans ARIB-TT spec] - it looks like they're building this functionality based on SMPTE-TT.
... Shall we defer this then until a future version of the spec, assuming we have more information?

Pierre: Yes please go ahead.

RESOLUTION: Defer this requirement for the time being, absent more detail.

github-bot, end topic

Nigel: I've added the other issues to the 1.1 milestone but not this one.

Clarify anonymous span construction and implicit duration semantics ttml1#318 (pull request)

Nigel: My question is why we replace contiguous anonymous spans with single ones?
... Does it make any difference?

Pierre: Note this has been in the spec forever.

Glenn: To the extent that we defined semantics for timings on anonymous spans, I took the
... non-collapsed spans to be equivalent to the collapsed spans from a timing perspective.
... As long as you do that I think you end up with the same semantics whether you do it
... before or after time resolution.
... Efficiency was a large consideration in collapsing the spans but I cannot rule out off the
... top of my head that there wasn't something else. I suspect there isn't.
... It is also about testability though - should we have a normative wrapping to a concrete
... representation of an ISD used for testing purposes then this makes a difference.

Nigel: My concern is that this refactoring has accidentally introduced a change that we did not intend.

<pal> https://github.com/w3c/ttml1/pull/318#discussion_r162199073

Glenn: I am pretty sure the contiguous span collapsing can only occur before pruning inactive elements.

Pierre: That's how imscjs does it.

Glenn: My implementation would not do it either.

Pierre: In the clarified Third Edition it is not a possibility to do it, so the question is if it
... was possible before. Since it happened in style resolution before, that was after timing
... resolution, then it's pretty clear that...

Nigel: If you resolve timings first and then do this process then you would end up collapsing the
... two anonymous spans.
... Is there ever any difference in presentation between two contiguous anonymous spans
... containing some text and the same text in a single anonymous span?

Pierre: As children of a seq container they have no implicit duration so they never display.

Nigel: Agreed.

Glenn: XML representations can generate as many text nodes as they like.
... There are lots of processing features that are not specified that could lead to a change in
... interpretation based on the anonymous spans, for example being treated as possible
... word breaks or segment boundaries.

Nigel: I feel as though we are not going to resolve this and should move on.
... It's clear to me that we are introducing a change that could make it a requirement to
... generate contiguous anonymous spans, and that it is possible that could trigger some
... bugs not previously seen. However we have not got enough clear information to block
... progress on this pull request, and it is not even completely clear that this behaviour
... would not have happened before, so I'll remove this from my list of points to block my approval of the pull request.

Meeting close

Nigel: Thanks everyone. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

  1. Make the initial value of tts:position "top left" and remove the text defining behaviour of position when specified on the tt element.
  2. Align the content model of br in TTML2 with TTML1 and make the recommendation about animation on br stronger by deprecating it in TTML2.
  3. Revert to prohibit use of `<length>` without units.
  4. Make no change to IMSC2 and close this issue.
  5. Close this pull request #288 without merging.
  6. Close issue with no spec change.
  7. (updated) Don't close the issue, close the pull request and Defer the issue to a later edition.
  8. textShadow is required, no spec change needed.
  9. Defer this requirement for the time being, absent more detail.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/18 17:21:48 $