W3C home > Mailing lists > Public > public-tt@w3.org > October 2017

{minutes} TTWG Meeting 2017-10-19

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 19 Oct 2017 16:21:14 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D60E8F4B.4C3D4%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/10/19-tt-minutes.html

In text format:


      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

19 Oct 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/10/19-tt-irc


          Nigel, Cyril, Pierre, Mike, David_Ronca, Thierry





     * [3]Topics
         1. [4]This meeting
         2. [5]TPAC planning
         3. [6]TTML1 and TTML2 compatibility in practice
         4. [7]TTML2 Wide Review
         5. [8]IMSC
         6. [9]Add equivalent CSS properties to style attributes
         7. [10]Reference CSS color semantic #413
         8. [11]Region constraints are the same as in IMSCvNext
         9. [12]Is #ruby necessary, or #ruby-non-nested
            sufficient? #2
        10. [13]IMSC vNext requirements
        11. [14]CLDR
        12. [15]Meeting end
     * [16]Summary of Action Items
     * [17]Summary of Resolutions

   <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
   ... 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

   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

   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
   ... 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

   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

   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
   ... I know Glenn has done some work on TTML1 Third Edition.

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

   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


   <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


     [18] http://www.w3.org/AudioVideo/TT/tracker/actions/508

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


   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
   ... 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

   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
   ... 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: [19]https://github.com/w3c/ttml2/issues/406

     [19] 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.

   [20]Pull request

     [20] https://github.com/w3c/ttml2/pull/470

   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

   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:



     [21] 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: [22]https://github.com/w3c/ttml2/issues/413

     [22] 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
   ... 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
   ... 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

   Pierre: I'm not against it but I see no advantage in adding
   ... 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: [23]https://github.com/w3c/imsc/issues/262

     [23] 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.

   [24]draft proposal

     [24] https://rawgit.com/w3c/imsc/297dcb3f5aa35889029bb10e5def87ca089407aa/imsc1/spec/ttml-ww-profiles.html

   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

   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
   ... 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: [25]https://github.com/w3c/imsc-vnext-reqs/issues/2

     [25] 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

   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

   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.


   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

Summary of Action Items

Summary of Resolutions

   [End of minutes]

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

     [26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [27] http://dev.w3.org/cvsweb/2002/scribe/



This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Thursday, 19 October 2017 16:21:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:44:20 UTC