- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Wed, 17 Sep 2014 15:12:45 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <5941EAB8802D6745A7D363D7B37BD1F749B6835E@BGB01XUD1012.national.core.bbc.co.uk>
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