Timed Text Working Group Teleconference -- 17 Sep 2014

<trackbot> Date: 17 September 2014

<scribe> scribeNick: nigel

IMSC 1 issues

issue-339?

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

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

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

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

<pal> 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 https://www.w3.org/wiki/TimedText/TTMLtoWebVTT to reference the files for each test

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

group starts working on tests etc

<courtney> Here are some links to VTT test files: 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> 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 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 http://www.w3.org/2014/09/17-tt-minutes.html#action02]

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

<scribe> ACTION: frans Revisit issue-339 to investigate potential resolution options [recorded in 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 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 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 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

- DRAFT -

Timed Text Working Group Teleconference

17 Sep 2014

Attendees

Contents