{minutes} Geneva F2F day 2 17/09/2014

Minutes from today's joint TTWG/TTCG meeting (day 2 of 2) available in HTML format at http://www.w3.org/2014/09/17-tt-minutes.html

We made one resolution:

RESOLUTION: We will adopt the 2014 W3C Process for IMSC 1, TTML2 and WebVTT
The provisional period for this resolution under our Decision Policy will end on Wednesday 1st October.

Minutes in text format:


   [1]W3C

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

                               - DRAFT -

                Timed Text Working Group Teleconference

17 Sep 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/09/17-tt-irc

Attendees

   Present
          frans_EBU, tmichel, Cyril, pal, andreas, mike, glenn,
          courtney

   Regrets
   Chair
          nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]IMSC 1 issues
         2. [5]Tests and mappings
         3. [6]overflow (redux)
         4. [7]TTWG Process
         5. [8]IMSC 1 Next steps
         6. [9]next steps for WebVTT
         7. [10]TTML2 FPWD issues
         8. [11]Review of mapping tests
         9. [12]prizes!
        10. [13]Assess progress, onward actions.
     * [14]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 17 September 2014

   <scribe> scribeNick: nigel

IMSC 1 issues

   issue-339?

   <trackbot> issue-339 -- Allow the use of #overflow -- open

   <trackbot>
   [15]http://www.w3.org/AudioVideo/TT/tracker/issues/339

     [15] http://www.w3.org/AudioVideo/TT/tracker/issues/339

   pal: My assessment is that there's ambiguity in TTML1SE on what
   visible means. The value "hidden" is much clearer, and forces
   the author to
   ... size the region so that all the text shows up when he's
   authoring. That provides a solid basis for the presentation
   engine based on that assumption.
   ... there's been a suggestion that visible needs to be
   permitted to ensure that text is drawn, but that doesn't take
   into account the common case in the US
   ... where implementations allow user control of font size.
   ... There's a potential impact on HRM. I haven't heard any
   strong technical argument for including visible in IMSC 1, why
   it's a good thing.
   ... So it's my recommendation that we don't include it.

   glenn: Irrespective of that, if the adoption of IMSC is
   curtailed then that's a valid reason.

   andreas: Is it right that the reason for not allowing overflow
   in IMSC is based on a misreading of TTML1SE overflow
   definition?

   pal: I don't think that's the entire story. First I don't think
   that correcting the region growth muting the HRM would solve
   the problems on existing implementations.
   ... We're talking about provisions with conformance language.
   Even if we all agree here on the intent it would not solve the
   problem for implementations.
   ... Second, tts:overflow="visible" allows the authored document
   to appear correct to the author and yet does not provide a good
   basis for the presentation engine.

   andreas: In IMSC 1 if overflow is not allowed, how is it
   handled? In TTML1 the feature exists and there are assumptions
   about how it should be handled.
   ... So where are the reasons not to include the attribute?

   pal: The default value of the attribute is hidden, which avoids
   any confusion.
   ... The default in CSS is visible, not hidden. Is it really the
   intended behaviour to prevent the presentation processor from
   being allowed to display text out of the region?

   mike: In the proposals are we talking about document
   conformance or presentation processor conformance?

   andreas: Shouldn't it be the same? If you set it in the
   document to a specific value then the processor must interpret
   it as specified?

   mike: If you allow the value but some presentation processors
   don't support it then that creates one environment. If you
   forbid it in the document
   ... then that situation is avoided.

   andreas: The main thing is to permit it in the document. If an
   IMSC processor does not support the feature then would the
   processor reject it?

   glenn: It's a document conformance issue in that case.

   pal: The spec says what the document must contain.

   andreas: So if a processor sees an IMSC document with this
   attribute set then it can reject it.

   glenn: BY excluding visible then you're saying that overflow
   content will never be visible. I wonder if that's in the
   interest of the author or the end user.

   pal: That's not my read of it. There's a specific use case in
   the US where users can change the size of fonts. Clearly no
   implementation, if it permits this, would hide
   ... the text, or simply overflow the text out of the region
   like in the example.

   glenn: Any implementation that does either of those is a
   non-conformant processor.
   ... Assuming that we care about implementations conforming to
   the spec...

   pal: That choice by the user is made at rendering, and the
   processor can assume something about the authors intentions and
   can scale the region accordingly.

   glenn: You're projecting into the spec something that is not
   there.

   pal: One approach would be to capture that intent language.

   glenn: I would object to any language in IMSC that would imply
   or specify that a presentation processor should alter the
   region size based on a user setting.
   ... That doesn't mean we can't in the future define support for
   that feature, but IMSC 1 is intended to be compatible with
   TTML1.

   nigel: We need to get to a resolution on this, and so far I've
   not formally heard an objection to Issue-339.

   pal: I formally object to Issue-339.

   andreas: Shows an example where overflow=visible would be
   helpful, without affecting the dimensions of the block
   container.
   ... The behaviour when hidden is to obscure some of the text.

   pal: Can we look at the normative wording in TTML1SE?

   andreas: The features in TTML1SE are explained with reference
   to XSL-FO.

   glenn: It was not the intended behaviour of TTML1SE to diverge
   from XSL-FO. The example in the spec clearly shows that.
   ... Whoever has read that clause wrongly has ignored other
   wording in the spec and hasn't checked with the group or the
   editor.
   ... I can see how an implementation may be based on a reading
   inconsistent with the intended meaning.
   ... I've filed an issue for this, as an errata.

   issue-345?

   <trackbot> issue-345 -- tts:overflow - ambiguous language about
   region extent -- pending review

   <trackbot>
   [16]http://www.w3.org/AudioVideo/TT/tracker/issues/345

     [16] http://www.w3.org/AudioVideo/TT/tracker/issues/345

   glenn: Computation meant of the descendant areas not of the
   region itself. The erratum in issue-345 is available also here:

   Cyril: There does seem to be a discrepancy between the
   normative spec text and the example.

   glenn: Agrees.

   Cyril: It's normal not to go back to the WG for guidance. The
   normative text would be used first.

   pal: We can't blame readers of the spec for the spec having the
   wrong words.

   glenn: I admit that, so if the spec doesn't properly express
   the intent normatively, we need to fix it.
   ... The question is how to we deal with the implementations
   taking the non-intended interpretation.

   pal: We have to be more factual - some implementations have
   followed one path, others another.
   ... I'm not convinced that Andreas's example diagram is what
   most implementations do.

   glenn: It's what every CSS and XSL-FO implementations do.

   pal: That's a way to express semantics only though.

   glenn: The implementation described is inconsistent with that
   behaviour and is non-interoperable.

   <glenn>
   [17]https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttm
   l1-errata.html#errata-8.2.15-1

     [17] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-errata.html#errata-8.2.15-1

   andreas: Do you know of any implementation that implements
   visible with the alternative reading of the spec text?

   pal: That's how implementors understood it.

   andreas: But are there any implementations that use overflow
   visible and implement it in the non-intended way?

   nigel: I want to understand here - is the basis of the
   objection the potential implementation based on a misreading of
   the spec, which we can address?

   pal: I have other reasons too.

   andreas: The authoring tools may not know the presentation
   renderer's font layout behaviour precisely, so if that happens,
   it's probable that
   ... the region defined isn't large enough to fit the text into
   it.

   pal: If you use reference fonts you can get around this.
   ... I would think that implementations that want to present
   nicely wouldn't just extend the text without the region
   background.

   glenn: Yes but those images were reviewed by the group and even
   though they're non-normative they are the specification.

   pal: But implementations may want to do something cleverer.

   glenn: We're not specifying any user agent in the spec. If a UA
   wants to do things cleverer that's up to it. We don't have a
   certification process for TTML or IMSC
   ... presentation engines.
   ... I don't think the example image can just be ignored.

   Cyril: If the spec is broken the reader needs to look primarily
   at the normative text.

   glenn: Also, in the CSS spec it says that even if overflow is
   visible content may in fact be clipped.

   andreas: This is why the spec text says "should" not be
   clipped.
   ... Proposal: 1. Fix TTML1SE with an erratum as per issue-345;
   then how to deal with IMSC? IMSC is a subset of
   ... TTML so you can restrict within TTML. So we have room if we
   include overflow to make clear what is meant and add any other
   text that would improve
   ... the implementation on the decoder side. This would give
   clear guidance to implementors implementing IMSC.

   mike: That sounds fine but the fundamental issue with overflow
   is that there are implementations today that have undefined
   behaviour if it is present and set to visible.

   nigel: But there can't be an IMSC processor that has any
   behaviour as it's not in the spec.

   mike: The default value from TTML1 may be taken to be the
   defined behaviour in the absence of the attribute.

   glenn: I'm not sure if there are any implementations here.

   andreas: It may be in the TTML test spec.

   mike: Yes it's probably there in the TTML test suite.

   andreas: The behaviour according to TTML1Se is a SHOULD not a
   SHALL so any implementation that treats visible identical to
   hidden wouldn't be broken.
   ... On purpose the feature is written that different forms of
   rendering are valid, and one of them is the one that's already
   implemented, the other is to do the new behaviour.

   mike: That's a problem in itself.

   pal: The fundamental issue is that different people have
   interpreted this to mean different things. What author doesn't
   want their text to be shown? I don't know of any.
   ... but that's not what the normative text says.

   glenn: That's a matter of disagreement.

   pal: The specific meaning is not the ideal one.

   glenn: That's exactly the same as the XSL-FO and CSS model
   without any change at all.

   <glenn>
   [18]https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/old/dfxp
   /tests/sOverflow001.png

     [18] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/old/dfxp/tests/sOverflow001.png

   nigel: We can only base IMSC 1 on TTML1SE, and overflow is the
   only show in town. We can address this in IMSC 2 or TTML2 but
   we don't have that option.

   glenn: That link shows an image that has been in existence as
   part of the DFXP test suite for a long time.

   nigel: We have two opposing positions and no consensus yet, so
   we need to find some alternative that can remove the
   objections.

   coffee break, back in 5 minutes.

   and we're back

   nigel: Unfortunately we haven't resolved the issues.

   glenn: I believe there are two things: one, fixing the spec,
   which I've proposed, two, whether or not to support visible in
   IMSC.

Tests and mappings

   nigel: suggest we split into 3 groups, each taking a
   non-overlapping topic. Each group to have at least one WebVTT
   expert and one TTML expert.
   ... I'll be awarding prizes for the best test cases and
   resolved issues!
   ... I guess a test is a pair of documents and a pass/fail
   criteria. We can paste these into the wiki later, or put them
   in directly.

   courtney: I have some proposals for the issues, can I show
   them.
   ... Shows example for id mapping.
   ... and for begin and end times, and style.
   ... (assuming there's an appropriate CSS document that goes
   along with it).

   mike: So the idea is that there's a CSS document accompanying
   the WebVTT document?

   courtney: Yes.

   Cyril: How do we test that the result is the same thing? Which
   players can we use?

   andreas: As we are targeting WebVTT current spec there aren't
   any implementations that support all features.

   courtney: I can think of a not-yet-available WebVTT player.

   andreas: Maybe we should include the target example too.

   courtney: I agree.

   andreas: We can make it up in HTML and express the test output
   as we expect to see it in HTML.

   Cyril: firefox has a js implementation of WebVTT to make HTML -
   feed it cues and get back HTML. It doesn't implement everything
   yet, e.g. not reasons.

   andreas: I suggest doing it by hand.

   [19]http://www.w3.org/2008/10/dfxp-test-coverage.html

     [19] http://www.w3.org/2008/10/dfxp-test-coverage.html

   nigel: There's a zip file link at the bottom.

   <pal>
   [20]http://www.w3.org/2008/12/dfxp-testsuite/web-framework/STAR
   T.html

     [20] http://www.w3.org/2008/12/dfxp-testsuite/web-framework/START.html

   Cyril: I've made a test example. The naming convention is e.g.
   br001.xml - I'll make a br001.vtt

   nigel: I suggest we upload the files to the wiki and create a
   child page of
   [21]https://www.w3.org/wiki/TimedText/TTMLtoWebVTT to reference
   the files for each test

     [21] https://www.w3.org/wiki/TimedText/TTMLtoWebVTT

   <glenn> see
   [22]http://lists.w3.org/Archives/Public/public-tt/2014Sep/0050.
   html for info/download of (now dated) DFXP Viewer Application

     [22] http://lists.w3.org/Archives/Public/public-tt/2014Sep/0050.html

   group starts working on tests etc

   <courtney> Here are some links to VTT test files:
   [23]https://github.com/w3c/web-platform-tests/tree/master/webvt
   t

     [23] https://github.com/w3c/web-platform-tests/tree/master/webvtt

   nigel: Time to start thinking about heading up for lunch.

   courtney: When I've put these in the draft doc I may come back
   and ask for more assistance generating more tests.

   Cyril: I need to go after lunch, so what I've done so far:
   ... made a viewer HTML page for the WebVTT, and set up a test
   environment for displaying them;
   ... Made WebVTT examples from the tests for most of the content
   elements - 10 examples in all.
   ... There's another issue for the list, for WebVTT. To add
   style to a particular cue, in the VTT cue there's a cue span
   with an identifier, then
   ... in the CSS there are rules that apply to that class. If you
   have multiple video elements in a page you have to load all the
   CSS files and there may be naming clashes
   ... between the classes in different files. I don't know how to
   resolve that.

   andreas: For the specific example of a single mapping we don't
   have that problem.

   Cyril: That's fine, but this is a problem that WebVTT will need
   to handle.

   courtney: Having a style: in the WebVTT header would be one
   proposal.

   Cyril: It would solve the scoping problem if we had the
   possibility to include the CSS in the WebVTT file.
   ... Alternatively to put CSS properties directly on the cue.

   courtney: That would map nicely to TTML.

   Cyril: there are some parsing issues there, because spaces are
   allowed in CSS but not in WebVTT, so it would need some
   thought.
   ... We should use the web platform tests to post our sequences,
   in the github repository.

   andreas: +1 to using the github repository.

   Cyril: You don't need a complex procedure just to use that as a
   repository as opposed to automating the tests with javascript.

   Adjourns meeting for lunch

   trackbot, start meeting

   <trackbot> Meeting: Timed Text Working Group Teleconference

   <trackbot> Date: 17 September 2014

overflow (redux)

   issue-339

   <trackbot> issue-339 -- Allow the use of #overflow -- open

   <trackbot>
   [24]http://www.w3.org/AudioVideo/TT/tracker/issues/339

     [24] http://www.w3.org/AudioVideo/TT/tracker/issues/339

   Reasons against permitting #overflow in IMSC 1:

   * It is unclear what presentation processors should do if
   tts:overflow=“visible”, so there would be interoperability
   issues with different processors producing different output.

   * There are mechanisms available to allow authors to avoid any
   overflow scenario occurring (via reference fonts).

   * Authors may use tts:overflow=“visible” as a proxy for setting
   region extent too small, on the basis that implementations will
   expand the region to fit. That would break the presentation
   model and allow the HRM to report a lower complexity value than
   is correct.

   * CFF-TT implementations would require change.

   * If an IMSC 1 document were to include a processor profile
   that states that #overflow support is required then existing
   conformant processors would be forced to reject the document.

   <tm> /invite zakim &test

   Reasons for permitting #overflow in IMSC 1:

   * It would curtail adoption of IMSC 1 if the feature were
   prohibited.

   * Implementations are already expected not to clip text, as it
   is never the authorial intent. So arguably the current wording
   in IMSC 1 that prohibits values other than the initial “hidden”
   is incorrect.

   * The mechanisms for allowing authors to avoid overflow
   scenarios can never be complete so an alternative is needed.

   * There are real world cases where overflow=visible is better
   for the audience than overflow=hidden.

   * There are already some changes planned for IMSC 1 that would
   require changes to existing implementations e.g. CFF-TT
   processors.

   mike: Could you elaborate more on the last one?

   andreas: I think it just means that implementation changes are
   possible.

   Frans_EBU: Can we list the changes?

   mike: I think there's a qualitative difference between the
   implementation of some of the features, so I'd suggest
   softening "would" to "may" require changes.

   pal: I'm suggesting not implementing Issue-339 because the
   feedback I have had is that it would be a significant
   engineering change.

   andreas: I'd add one further reason to integrate it: documents
   that would be authored against other standards would be
   invalidated re IMSC by omitting this feature.
   ... If we accepted #overflow then this allows almost all
   EBU-TT-D documents to be valid IMSC 1 documents, but preventing
   it would invalidate them.

   mike: The opposite is also true - by permitting it, from the
   profile perspective, it would invalidate CFF-TT documents.

   Options we have now:

   * Fix wording in TTML1SE as per issue-345.

   * Movement to CR: we can

   ** block CR until this issue is resolved.

   ** resolve the issue by one of the following options:

   *** withdraw the request and omit the feature

   *** Include the #overflow feature as a MAY, with no other
   changes

   *** Include the #overflow feature as a MAY, and add
   non-normative notes to resolve points against

   *** Include the #overflow feature as one of the previous two
   options and mark the feature as AT RISK in the CR.

   andreas: In the penultimate option, it is also possible to add
   normative points to IMSC 1.

   nigel: I would timebox any discussion right now to 5 minutes,
   otherwise we go back to the respective groups and seek
   proposals for resolution for discussion in next week's telco.

   glenn: In the absence of any IMSC 1 implementation all features
   are at risk in the CR in principle.

   pal: I do expect there to be an IMSC 1 implementation during
   CR.

   Frans_EBU: over lunch we discussed implementation evidence.

   pal: I think the 2014 process offers some easier choices than
   the 'demonstrate two independent implementations'.

   nigel: are there any spec text changes that would help remove
   the objection to Issue-339?

   pal: I don't know of any right now.

   andreas: I think we have to go back to our groups and seek
   proposals.

   mike: Can we have a show of hands of who is in
   favour/neutral/against the proposal to include #overflow
   (tts:overflow="visible") as specified by TTML1SE including the
   Issue-345 errata?

   group: 1 abstain, 1 don't care, 2 against, 4 in favour.

TTWG Process

   nigel: We have a choice to adopt the 2014 process.

   mike: I proposed that we adopt the 2014 process for IMSC 1,
   TTML2 and WebVTT.

   nigel: This has been on the email reflector. I've seen no
   objections or concerns raised with the 2014 process.

   RESOLUTION: We will adopt the 2014 W3C Process for IMSC 1,
   TTML2 and WebVTT

IMSC 1 Next steps

   pal: This means we intend to go to CR under the new process on
   October 15. Only Issue-339 is outstanding.
   ... Do we need a test plan for CR?

   tmichel: We don't have to have a full test suite or
   implementation report to enter CR. We do need an implementation
   experience report, a test suite and wide review to exit CR.
   ... This means we have to contact the WGs that have
   dependencies with our group and request review of our document.

   mike: We received a liaison from DECE today.

   nigel: Thank you, yes, it's been circulated on the members-only
   list.
   ... shows the group the message.

   mike: describes the test files available and the verifier
   functionality.

   nigel: short break before next topic

   <scribe> ACTION: pal Revisit issue-339 to investigate potential
   resolution options [recorded in
   [25]http://www.w3.org/2014/09/17-tt-minutes.html#action01]

   <trackbot> Created ACTION-328 - Revisit issue-339 to
   investigate potential resolution options [on Pierre-Anthony
   Lemieux - due 2014-09-24].

   <scribe> ACTION: Frans_EBU Revisit issue-339 to investigate
   potential resolution options [recorded in
   [26]http://www.w3.org/2014/09/17-tt-minutes.html#action02]

   <trackbot> Error finding 'Frans_EBU'. You can review and
   register nicknames at
   <[27]http://www.w3.org/AudioVideo/TT/tracker/users>.

     [27] http://www.w3.org/AudioVideo/TT/tracker/users%3E.

   <scribe> ACTION: frans Revisit issue-339 to investigate
   potential resolution options [recorded in
   [28]http://www.w3.org/2014/09/17-tt-minutes.html#action03]

   <trackbot> Created ACTION-329 - Revisit issue-339 to
   investigate potential resolution options [on Frans de Jong -
   due 2014-09-24].

next steps for WebVTT

   tmichel: I will go back to Dave Singer and Silvia and see when
   we can target a FPWD publication. I'd like to have this moved
   to the TTWG and
   ... do the first public draft and call for exclusion etc.

   courtney: What steps need to be taken to get there?

   tmichel: I think the document is mature enough though there is
   some room for improvement. Dave Singer is pushed for time so I
   volunteered to help.

TTML2 FPWD issues

   glenn: There are no blocking issues as far as I know, for FPWD.
   The criteria for publishing are low.

   nigel: We said we'd publish it next week.

   glenn: I want to spend the next few days getting in some more
   material and placeholders that I've been working on, at least
   Editorial Notes for new material that
   ... is needed before we go to CR.
   ... The current list of authors that are listed hasn't been
   changed since TTML1. For TTML1 we set up specific actions for
   individuals to come up with spec text.
   ... I've been authoring all of the pieces that are going in.
   The current names are out of date. I could list it as 'Active
   members' instead of contributing authors,
   ... or take out the Contributing Authors list. I'll still be
   listing people in the acknowledgements section.
   ... At least everyone here will be listed. Why don't I just
   take that section out for the FPWD?
   ... It varies in other W3C publications.
   ... In TTML1 the names were people who had contributed a
   specific piece of spec. We haven't taken that approach so much
   with TTML2.
   ... I haven't taken spec text e.g. from issues or change
   proposals verbatim, other than some of the proposals from Sean
   Hayes. So I'd only leave his name in there
   ... if we kept the list as it is now, in format.
   ... Please could the chair make a decision and let me know?
   ... I don't want to omit anyone who wants their name there.

   <scribe> ACTION: nigel Consider Contributing Authors section of
   TTML2 [recorded in
   [29]http://www.w3.org/2014/09/17-tt-minutes.html#action04]

   <trackbot> Created ACTION-330 - Consider contributing authors
   section of ttml2 [on Nigel Megitt - due 2014-09-24].

   glenn: We can continue with the dedication to David Kirby.

   nigel: Do we have a date for CR?

   pal: We need to acknowledge the SMPTE feature requests.

   glenn: Absolutely, hopefully they'll make it into the FPWD.
   Additionally the section on HTML/CSS mapping and a
   section/annex on a Serialized form of ISDs.
   ... I've already got a schema for ISDs. You can create an ISD
   sequence document whose root element is <isds> and the other is
   a document whose root is just <isd>.

   nigel: That's interesting - I've also got some work ongoing to
   define rules for combinable documents and an algorithm for
   combination.
   ... The two don't conflict, and solve different problems.

   glenn: The ISD approach is needed for generating static
   HTML/CSS documents for each ISD.

   nigel: We did set out a TTML2 publication timeline:
   ... Wednesday 8 October: closure date for issues on TTML2 - any
   new feature issues beyond this point to be addressed after LC
   or in v.next.
   ... Thursday 20th November: all issues on TTML2 to be closed or
   deliberately postponed (to v.next or LC review stage).
   ... Wednesday 17th December: CR doc ready to request for
   publication.

Review of mapping tests

   nigel: I suggest we show each set of tests and then later
   (offline) upload them to the wiki.

   courtney: I'm going to want to collate the tests anyway so I'll
   organise them.

   andreas: I started on the text alignment.
   ... I used the default for textAlign. [shows TextAlign001.xml,
   TextAlign002.xml, TextAlign003.xml, TextAlign004.xml,
   TextAlign005.xml, TextAlign006.xml from the DFXP test
   repository]
   ... this sets the textAlign attribute on the p element to
   left/right/center/start/end depending on the document.
   ... The mapped WebVTT documents need to have the position: and
   align: settings correct.
   ... For example for textAlign="right" position:100% align:right
   ... For textAlign="left" set position:0% align:left
   ... For "center" position:50% align:middle

   glenn: In WebVTT is "middle" a keyword for "center" in CSS?

   andreas: yes.

   glenn: In CSS "middle" references vertical alignment and
   "center" horizontal alignment. So they're both "middle" in
   WebVTT?

   andreas: yes.

   glenn: And align:start is a logical rather than absolute
   setting, e.g. for right to left writing mode start would be
   mapped to right?

   andreas: I didn't check that. The default for all the TTML
   examples are left to right, top to bottom.
   ... VTT has both the logical and the absolute align settings
   available.
   ... for "end" position: 100% align:end
   ... So textAlign maps to position: and align: settings
   ... Looking at visibility:
   ... [shows Visibility001.xml, Visibility002.xml,
   Visibility003.xml]
   ... Visible is easy - you only have to worry about part of the
   text being invisible.
   ... In Visibility003.xml the first line is always visible, and
   the second line is hidden.

   glenn: You have to watch for non-visible text affecting visible
   text, e.g. if hidden text has a much bigger font size and
   consequently line height than the visible text on the same
   line.

   andreas: Shows the CSS for Webvtt. Sets
   background-color:transparent and ::cue(.invisibleText) {color:
   rgba(0,0,0,0)}

   glenn: So are you using rgba because visible isn't available?

   andreas: yes. The CSS visible property isn't available in
   WebVTT. [Shows the VTT document with c.invisibleText class, and
   example HTML page]
   ... Also shows the background color being drawn behind
   invisible text by changing to green.

   glenn: In TTML the background color on a span shouldn't be
   shown if the text is invisible. So you may need to map
   background-color: rgba(0,0,0,0) also on that cue selector.

   andreas: I just started on writingMode, which is a bit more
   complicated.
   ... [Shows the WritingMode test examples for TTML]
   ... The default in both formats is left to right inline
   progression and top down block progression direction. Nothing
   needs to be changed.
   ... The only way to influence writing direction in WebVTT is
   the vertical cue setting (e.g. vertical:lr).

   courtney: THat's the only explicit way but you can also do it
   in the Unicode.

   andreas: This needs more investigation - the Unicode bidi
   doesn't seem to be the same as writingMode, so I'm not sure.
   ... E.g. WritingMode002.xml: writingMode="rltb"

   glenn: That doesn't change the order of any of the letters or
   words in the text, but just changes the default in the block
   element as right to left.
   ... The text in the example seems to be misleading and untrue.
   The only effect in this case would be to set the default bidi
   level of the <p>s to be 1 instead of the 0 default.

   andreas: I may not have got this 100%, the combination of
   unicodeBidi and writingMode.

   courtney: I don't really understand it.

   glenn: It has to do with weakly directional characters vs
   strongly directional characters. E.g. digits excluding letters
   would be laid out based on the default
   ... level.

   andreas: But look at the example spec for writingMode.

   glenn: That example depends on unicodeBidi="override" - without
   that then the text wouldn't have its direction changed.
   ... Obviously it does in the vertical dimension.
   ... In the test document changing between rltb and lrtb would
   switch the interpretation of start and end between r/l and l/r.

   andreas: So in WebVTT there's no change to make.

   glenn: If VTT has both the logical and absolute keywords you
   can just preserve them across between WebVTT and TTML since
   both support both kinds of edge names.

   andreas: For this example from the TTML test suite we have no
   difference in the WebVTT. For full implications we have to make
   other test files that combine
   ... writingMode with text alignment to see the implications.

   glenn: in the mapped WebVTT from WitingMode002.xml the initial
   value is start, so it should be preserved.

   andreas: There's no writing mode in WebVTT - it's only left to
   right (i.e. dependent on the Unicode bidi).

   glenn: So you would have to map to right.

   courtney: In the WebVTT spec, under the alignment cue setting
   there's a note: the keywords are relative to the text
   direction.

   glenn: So it's using the context of the text as opposed to an
   explicit writing mode, which may be considered buggy.

   courtney: This is on our issues list.

   glenn: In TTML if the writing mode is rltb then even if all the
   characters are latin start would still map to right.

   andreas: Is the position: 100% align: end combination correct
   for rltb, start in TTML?

   glenn: it would be less ambiguous if you set it to right.

   courtney: Because it's roman characters, that's right. If the
   text were in hebrew or arabic then the alignment would be
   different.

   glenn: Normally logical to absolute alignment is separate from
   the content.

   courtney: So the rule there is you have to go from logical to
   physical to properly handle alignment?

   glenn: Yes, but separately you deal with the bidi and ordering,
   after you deal with the block level alignment.

   andreas: We do need better documentation about how this works.
   ... [shows WritingMode005.xml with tblr]

   glenn: that's an unusual combination because it's not used by
   any language. Normally for tb it's rl so I'd focus there first
   for vertical.

   andreas: I mapped tblr to align:left vertical:lr

   glenn: The orientation has been changed to be sideways on this
   example. With vertical text that is not normally written in
   vertical mode, e.g. in latin script, you can
   ... choose to leave the letters upright (as in the TTML1 spec
   example) or "sideways right" which is how the example WebVTT
   doc you showed was presented.
   ... SMPTE requested a TTML2 setting to make this choice
   explicit, and we're adding that. In TTML1 we assumed upright
   not sideways. You may need to map to a CSS
   ... text orientation property which I don't know if its
   supported in WebVTT.

   andreas: For these writing modes I'd propose we use it for
   characters that normally written top to bottom, e.g. chinese,
   with an image for those who aren't used to
   ... reading it.

   glenn: I'll show this on my screen. Rather than mapping issues
   I decided to try to focus on representing some of this content
   in HTML for useful renderings.
   ... I created a template in HTML to allow me to put temporal
   frames into an HTML document, and some CSS template rules that
   map to some of the region properties.
   ... Getting displayAlign right was tricky. In CSS there's the
   vertical align property, but it only applies to table cells
   that must be explicitly sized.
   ... That took me longer to get it working than I thought, and
   it's not exactly precise between different browsers; some do
   strange things like adding margins from
   ... the default style.

   andreas: Can't we use flexbox?

   glenn: Yes but I didn't want to rely on it for this mapping and
   certainly don't want to rely on it for the official spec - it's
   changing on a weekly basis so isn't stable yet.

   mike: I found some issues.
   ... Shows an edited DisplayAlign001.xml and
   DisplayAlign001a.txt. I had to change some of the units from
   the example file.
   ... The tts:color value is application dependent, so you don't
   know what color to set it to in the WebVTT.
   ... We can't use the TTML2 initial element for this, but we're
   only looking at TTML1SE here.

   andreas: But that means that any color is correct.

   mike: This is an issue.

   glenn: for the mapping exercise some of the missing info like
   root spatial and temporal extent and initial color should be
   provided as parameters to the mapping application.
   ... If they're unknown you can't do anything with it.

   mike: I changed backgroundColor from white to black in the test
   document and added tts:color.
   ... None of this had anything to do with displayAlign!
   ... A default stylesheet or input to the translator would be
   needed.
   ... For this particular one the region was set to
   displayAlign="before" and in WebVTT if I've understood it right
   I set scroll=up align: left
   ... The text-align shouldn't be "top" as that's not an
   available value.
   ... The times were easy, but the region width and height needed
   the root container extent for the mapping. If there were
   cellResolution or something similar
   ... in the TTML this would have been trickier. Also I had to
   round the number of lines - up or down? I rounded down.

   andreas: I wonder if for some mappings you're better off not
   using the WebVTT region and just using the cue setting.

   mike: In this example that's true, but it might be hard to
   figure out for big documents.

   andreas: Is the behaviour defined in WebVTT if two regions with
   active content overlap?

   courtney: Cues are always ordered by their start time; I don't
   know about regions.

   andreas: Does scroll=up mean that text grows upwards towards
   the top?

   mike: I'm not sure where the first line goes - top or bottom?

   courtney: I think it goes at the bottom.

   mike: Then this example isn't quite right.

   courtney: The height of the region in lines determines how many
   lines are visible at a time.

   andreas: And if there are too many lines?

   courtney: The ones at the top disappear.
   ... This region functionality was designed to map the CEA608
   features.
   ... the other value for scroll is "none".

   mike: So for "none" does the text go in backwards?

   courtney: No I think it goes top to bottom and then when it
   hits the bottom the region grows to fit.

   <Loretta> Anything going on that I can help with?

   andreas: If you set scroll=none then it looks like you don't
   need to specify the lines on the region as it has no effect.

   pal: To help with the process of validating algorithmic
   conversion of TTML to WebVTT it looks like there's a great set
   of TTML test files. One thing that was missing
   ... was a way to play them back, to see if the conversion
   results match. Glenn managed to dig up an old TTML player
   executable. I massaged the current TTML

   <Loretta> scroll none behavior: When there is no scroll
   direction, cue lines are added in the empty line closest to the
   line in the bottom of the region. If no empty line is
   available, the oldest line is replaced.

   pal: test files so they're accepted by the executable. It's not
   perfect but it's better than nothing.
   ... I can post the test files with a big warning about 'only
   use them with this exe they're not spec compatible'.

   courtney: could we update the exe?

   glenn: I'd like to but I'm not sure if I'll have time. It's
   about 8 years old, written in C++ using stdlib, with its own
   XML parser and DOM implementation, so it would
   ... need to be ported to a more modern compiler. If I did that
   I'd wrap it with a Mac Xcode UI and update the rest of it to
   use TTML instead of DFXP.

   andreas: But if you can confirm that the output of this tool is
   correct then we can capture it and save it as PNGs.

   pal: Part of the interest is it does animation etc. Maybe one
   way is for people to contact me and I can send them what I
   have. It works for a large number of test files.
   ... [shows it running against a huge number of tests] about
   70-75% of the tests work.

   nigel: Do we know who wrote this and why?

   glenn: It was a company I owned and ran. It was based on DFXP
   and was a fairly complete implementation with timing, styling
   and some extra styles including
   ... the animate element that we're adding in TTML2
   ... It went into a consumer electronics product that was on
   sale.
   ... It would be useful to update it to TTML1 and maybe TTML2.
   I'll undertake to put it into github along with the other exes.
   ... We did use that implementation as a reference for
   implementability in TTML1 so it's in the implementation report.

   courtney: I was looking at timing. I started running through
   the BasicTiming00n.xml examples.
   ... [shows BasicTiming001.xml and .vtt mapped version]
   ... This covers timeContainer="par" with begin of 10 seconds
   and duration of 10s.
   ... So in WebVTT it's 00:00:10.000 --> 00:00:20.000 which is
   pretty simple.
   ... To illustrate timings it would be good to have multiple
   cues.
   ... In BasicTiming002.xml I changed it to show two samples.
   This has a body and a div with timeContainer="par" and two
   samples with the same begin time and duration.
   ... In WebVTT I made two cues with the same begin and end time.

   glenn: In the WebVTT would they both be in the same region?

   Loretta: WebVTT would move one of them.

   courtney: It would do magic collision avoidance.

   glenn: In TTML since they would appear in the same ISD and map
   to the same default region they would appear as two paragraphs
   within a div at the same time.
   ... They would be non-overlapping, and placed in document
   order.
   ... (one above the other in the same region).

   Loretta: it might or might not produce the same output in
   WebVTT.

   courtney: We'll find ways to actively validate these.

   glenn: So it's a question about mapping - if there's separate
   content that happens to be time overlapping and it's in the
   same region in TTML is there a way to express
   ... that in WebVTT?

   Loretta: The conversion could explicitly position the second
   cue below the first.

   glenn: Or it could merge them into one cue.

   Loretta: right.

   courtney: You can style text differently within one cue. It
   would be interesting to see if the default behaviour is the
   same.

   andreas: I just checked in Chrome and if you use a line
   percentage value it goes in the same position so the second cue
   overlaps the first one but if you use lines
   ... then its the same behaviour as in TTML.

   courtney: So to get that behaviour you have to have the cue
   setting line?

   andreas: Yes you have to specify the line number, e.g. 1 to
   appear at the top. If you don't use that setting then it would
   be the default, which is -1, which for this example
   ... with the text appearing at the top you have to explicitly
   set the line cue setting to 0. Then it works exactly as in
   TTML.

   courtney: [shows BasicTiming003.xml and VTT equivalent]. This
   has a seq timeContainer setting on a div inside a body with
   timeContainer par.
   ... this affects the computation of times. Here the cue begin
   time of the second one is added to the end time of the first.

   andreas: This is a great demonstration of how timeContainer
   works in TTML.

   courtney: [shows BasicTiming004 test example] Again this has
   body with timeContainer=par and div timeContainer=seq and a set
   child of the p.
   ... Here I think you have to add the set begin time to the p
   begin time.
   ... I flattened the timings and made a single cue. This does
   lose some information.

   nigel: This mixes time expressions, which is interesting. 5s,
   00:00:19:29.99 (fractional frame), "00:00:05.5" which is
   interesting.

   courtney: I didn't use all the times - some information got
   collapsed.

   glenn: Agree this isn't round-trippable, which is generally not
   going to be true - we should state that in the mapping
   document.
   ... Because both formats allow the expression of comments and
   metadata, technically you could incorporate the TTML source as
   a comment in the output VTT if you wanted to.

   courtney: Could we do the reverse?

   glenn: Yes, in a metadata element so it's visible at the XML
   level.

   nigel: What if the XML had something that coincidentally looks
   like a cue in it?

   glenn: Well you could BASE64 encode it.

   courtney: That would be roundtripping by pass-through rather
   than lossless conversion.

   andreas: I wonder how the set feature works in TTML - possibly
   it is better used in relation with a styling attribute like
   color or something.

   courtney: [shows BasicTiming006.xml and VTT mapped version]

   <Loretta> brb

   courtney: This would better illustrate timeContainer with
   multiple samples - it's pretty simple right now. It has a dur
   but no start time, so the default of zero applies
   ... because it's the first sample.

   glenn: begin defaults to zero effectively.

   courtney: In VTT it goes from 00:00:00.000 --> 00:00:15.000

   <Loretta> back

   nigel: 2 minutes break before we finish off

prizes!

   nigel: and we're back.
   ... awards the prizes in a very serious manner.

Assess progress, onward actions.

   nigel: Goal 1 was to produce a first draft of the mapping doc -
   we don't have the doc but we have a great source input for
   Courtney to pull together.
   ... Goal 2 was resolve any issues for TTML2 FPWD - and we now
   have none.
   ... Goal 3 : Resolve blocking issues against IMSC 1 for CR. We
   have one remaining with an action plan hopefully to resolve in
   next week's telco.
   ... so great progress! What are the actions for the mapping
   document now?

   courtney: The high level goal is to come up with a 1st draft.
   We have some structure from the logical breakdown yesterday
   that I'll use for an outline starter.
   ... As part of that effort I will go through today's samples
   and organise them, and incorporate them into the draft where it
   makes sense.

   nigel: We need to store the mapping examples/tests somewhere.

   andreas: Cyril suggested posting them to the testthewebforward
   git repository.

   courtney: That's good but I don't know how! If someone can
   point me to it then fine.
   ... Please could the corrected files be posted not the
   incorrect ones.

   andreas: Nevertheless shall we send everything produced today
   to you Courtney?

   courtney: Yes, though some still need some work. If you want to
   post incomplete docs please mark them up as needing work.

   <scribe> ACTION: nigel contact cyril requesting git repository
   instructions for the tests. [recorded in
   [30]http://www.w3.org/2014/09/17-tt-minutes.html#action05]

   <trackbot> Created ACTION-331 - Contact cyril requesting git
   repository instructions for the tests. [on Nigel Megitt - due
   2014-09-24].

   courtney: I had some outstanding issues noted that I will try
   to investigate. For example we need a proposal for id mapping
   conventions.
   ... We need a strawman proposal for mapping dimensions of
   regions from TTML to WebVTT.
   ... We need to check how margins work with WebVTT.
   ... These are open issues that I will need to close before
   completing the document.

   nigel: we also have the wiki page with some issues on at
   [31]https://www.w3.org/wiki/TimedText/TTMLtoWebVTT

     [31] https://www.w3.org/wiki/TimedText/TTMLtoWebVTT

   andreas: For the open WebVTT spec questions will you post the
   questions to the CG reflector, e.g. about margins?

   courtney: First I'll check with my engineers, otherwise yes.

   andreas: It may be a spec problem in which case we should
   discuss on the reflector.

   nigel: Then when there are questions to raise we'll assign some
   agenda time in our meetings.

   <Loretta> Thanks, everyone.

   nigel: Thanks everyone - we've made great progress on our
   goals. Thanks to EBU for hosting, thanks for everyone for
   contributing; it's been an intense 2 days but we've done well.
   ... closes meeting

Summary of Action Items

   [NEW] ACTION: frans Revisit issue-339 to investigate potential
   resolution options [recorded in
   [32]http://www.w3.org/2014/09/17-tt-minutes.html#action03]
   [NEW] ACTION: Frans_EBU Revisit issue-339 to investigate
   potential resolution options [recorded in
   [33]http://www.w3.org/2014/09/17-tt-minutes.html#action02]
   [NEW] ACTION: nigel Consider Contributing Authors section of
   TTML2 [recorded in
   [34]http://www.w3.org/2014/09/17-tt-minutes.html#action04]
   [NEW] ACTION: nigel contact cyril requesting git repository
   instructions for the tests. [recorded in
   [35]http://www.w3.org/2014/09/17-tt-minutes.html#action05]
   [NEW] ACTION: pal Revisit issue-339 to investigate potential
   resolution options [recorded in
   [36]http://www.w3.org/2014/09/17-tt-minutes.html#action01]

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [37]scribe.perl version
    1.138 ([38]CVS log)
    $Date: 2014-09-17 15:03:20 $
     __________________________________________________________

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

Received on Wednesday, 17 September 2014 15:13:19 UTC