See also: IRC log
<trackbot> Date: 17 September 2014
<scribe> scribeNick: nigel
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.
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
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.
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
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].
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.
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.
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
nigel: and we're back.
... awards the prizes in a very serious manner.
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/,,,/.../ Succeeded: s/mdolan/mike/ Succeeded: s/1 were/1 document were/ Succeeded: s/frans:/Frans_EBU:/ Succeeded: s/5.xml/5.xml, TextAlign006.xml/ Found ScribeNick: nigel Inferring Scribes: nigel WARNING: Replacing list of attendees. Old list: Geneva New list: [IPcaller] WARNING: Replacing list of attendees. Old list: [IPcaller] New list: Loretta Geneva Default Present: Loretta, Geneva Present: frans_EBU tmichel Cyril pal andreas mike glenn courtney Found Date: 17 Sep 2014 Guessing minutes URL: http://www.w3.org/2014/09/17-tt-minutes.html People with action items: frans frans_ebu issue-339 nigel pal revisit[End of scribe.perl diagnostic output]