- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Wed, 17 Sep 2014 02:08:44 +0000
- To: TTWG <public-tt@w3.org>, "public-texttracks@w3.org" <public-texttracks@w3.org>
- Message-ID: <5941EAB8802D6745A7D363D7B37BD1F749B68051@BGB01XUD1012.national.core.bbc.co.uk>
Minutes from today's joint TTWG/TTCG meeting (day 1 of 2) available in HTML format at http://www.w3.org/2014/09/16-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Timed Text Working Group Teleconference
16 Sep 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/09/16-tt-irc
Attendees
Present
elindstrom, tmichel, Frans_EBU, pal, Cyril, courtney,
andreas, glenn, nigel, Loretta
Regrets
Chair
nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]Introductions
2. [5]Agenda
3. [6]Work done so far
4. [7]Logical step through
5. [8]Agenda
6. [9]Document Structure
7. [10]Layout
8. [11]Summary of the day
* [12]Summary of Action Items
__________________________________________________________
<trackbot> Date: 16 September 2014
[13]https://www.w3.org/wiki/TimedText/geneva2014#Day_1_0900-170
0
[13] https://www.w3.org/wiki/TimedText/geneva2014#Day_1_0900-1700
Introductions
<scribe> scribeNick: nigel
Introductions - Nigel, BBC
andreas: IRT
Cyril: Telecom ParisTech university; GPAC
elindstrom: Opera software
zcorpan: Opera software
tmichel: W3C, staff contact for the TTWG
pal: Movielabs
courtney: Apple
glenn: Representing various over the years, currently Cox,
previously Samsung and Microsoft
frans_EBU: Coordinator of EBU group on subtitling
Agenda
nigel: goes through agenda on wiki page, all happy with that.
... We need to think about how we capture our output, and who
will edit the note.
courtney: I'm happy to edit the note.
... I don't have a document yet, I've been working on the code
first, and have some issues to tackle, and a spreadsheet for
attributes.
glenn: For browser implementations mapping direct from TTML to
HTML would be more efficient
... If the purpose is for direct display then this mapping
would be better, but if we want to interchange to WebVTT then
that translation would still be useful.
courtney: I'm interested in captions both inside and outside
browser environments so I'm not focused on HTML solely.
andreas: From the mapping we have done we will quite quickly
see the overlap - maybe there's a cut and paste into HTML as
glenn mentioned.
pal: Re WebVTT outside browsers?
courtney: Yes, e.g. in an ISO MP4 file that is rendered in a
video player.
pal: So do we need CSS in practice? To present WebVTT in
subtitles and captions?
courtney: You certainly can, but it depends on how fancy you
want to be. You can do basic 608 without CSS.
andreas: you need CSS to do colours, and that's certainly
required in Europe.
courtney: We define for example a simple mapping from CSS to a
property list. I think the better approach is to stick with CSS
and
... have a way to embed it in an MP4 file track, and also in a
WebVTT file.
pal: Will the mapping we do today include that?
courtney: yes
Cyril: +1
courtney: I've been thinking that one TTML file will map to a
WebVTT file + a CSS file
glenn: That's what I've been thinking, and there's a reusable
overlap into HTML/CSS
nigel: I've created a wiki page at
[14]https://www.w3.org/wiki/TimedText/TTMLtoWebVTT
[14] https://www.w3.org/wiki/TimedText/TTMLtoWebVTT
<zcorpan> can you paste the number in irc?
Work done so far
andreas: presents work so far
... This work has been supported by the HBB4ALL project, whose
target is to roll out accessibility to IP connected devices,
including subtitles, signing and audio (video) description,
... with a focus on hybrid broadcast.
... This is based on EBU-TT-BasicDe as a very restricted TTML
feature set.
... In fact it's a subset of EBU-TT-D which is a subset of TTML
plus a couple of small extensions.
... It has a video frame with a safe area, 10% in from each
edge.
... Alignment is top or bottom only, vertically.
... Horizontally, centred, left or right.
... For Germany, it's left to right, top to bottom writing
direction.
... There are 8 different text foreground colours, as from
WSTeletext.
... All subtitles have the same background color, font-family,
font-size and line height.
... Line breaking is done manually with the <br> element at
authoring.
glenn: How is the background padding extended on either side of
the text?
andreas: That's just in the example image, it's not actually
present.
... How is this mapping achieved? Positioning, Styling, Timing.
... Positioning:
... [shows video frame with image of Verona]
... In TTML and EBU-TT there's a root container. In EBU-TT it's
always the height and width of the video. WebVTT uses the
viewport concept,
... which I understand to be the height and width of the video
also.
... For the safe area, we define the tt:region, with top-left
being 10% 10% in x y as specified by the origin.
... The CSS property is topleft
... The extent is 80% 80%, which in CSS is the width and height
of the block level element eg the div
... To place a subtitle the region is defined once in the head
and then referenced by the tt:p element. This is similar to a p
in html.
... The paragraph gets the width of the region, and the height
is calculated by the number of lines inside the p element.
... Vertical alignment is displayAlign: bottom or top.
nigel: Will there be CSS mappings for all of these in this
presentation?
andreas: This is setting out the features to map, we should
consider them in scope for our mapping later.
... I didn't use the advanced concepts in WebVTT of cue
alignment, so I didn't use them. I wanted something that would
certainly work in current browsers.
... In WebVTT I've put the cues in for the text. For a width of
80% the cue box has size: 80%
... The height is defined by the number of lines, just like the
p element.
... This is per cue, so the settings seem to need to be
repeated every time. I don't know a way to define it once and
have it carried through.
courtney: If you use a region you can do that.
andreas: I didn't use a region.
courtney: Then you have to repeat it.
andreas: So that's positioning. We can define the position of
the box from the left of the video frame, with 10%, using
position:10% align:left
... The align setting is important. It works very differently
than in TTML e.g. if you set align:middle and position:10% then
the reference point for the middle isn't the cue
... start but is the middle of the cue.
... So to centre the text then you have position:50%
align:middle
... For vertical alignment it's a bit trickier. To come 10% up
from the bottom you can set line:90% or a line number value.
... But this doesn't align the end of the cue box, but aligns
the top of the cue box. So that doesn't work.
... What you actually need is position:100% - margin - height
of cue-box.
... That works if you have a lot of control over the font
height and can calculate the position this way.
... In most cases that's a bit risky. So then I changed to the
other possibility, to use line alignment
... The first line in the cue generates the line grid, then you
can position the cue box with positive line numbers from the
top
... or negative line numbers starting from -1 from the bottom.
... [example shows text one line up from bottom]
... You have to have the snap to lines flag set - this happens
automatically if you use line numbers.
... For one line you can have line:-2, or for a two line
subtitle, line:-3. Needs a bit of calculation.
... A dirty trick possibly is always to set it to -1 and let
the renderer push it up. Possibly this is not recommended but
it may work.
... Styling:
... In EBU-TT-BasicDE there's a default style defined once in
the head, and a div element that references the defaultStyle.
... In WebVTT you can define a general cue selector ::cue and
use almost the same property names and values.
... For font-size some calculation is needed. 60% font size in
TTML comes out at 5.33% of the height of the video, which is
100% in CSS.
... A separate CSS file is needed to contain the ::cue
selector.
... For inline styles in TTML we set the colour attributes on a
style referenced from a span.
... In CSS you can use the pseudo-selector ::cue(c.textWhite) {
color: #ffffff; background-color:rgba(0,0,0,0.7); }
... Then in the VTT c.textWhite cue class
... Timing:
... In TTML put a begin and end on, with media timeBase,
reference sync is zero. In EBU-TT-BasicDE the fractional
seconds are limited to 3 digits.
... This is the same for WebVTT cues.
pal: What are the rules for CSS styles when combined with
locally set rules? Which takes precedence between author and
user choices?
courtney: We would consider user choices to override author
styles.
pal: If you're displaying it on a web page, then web styles
taking over seems like not the right thing to do.
andreas: It's not clear to me how the CSS that applies to the
web page interacts with the VTT cues. From testing there's no
relationship.
... The video is a separate viewport with independent styling,
from my testing anyway.
Cyril: I think that's not expected. I remember that the cues
are sourced in the HTML page so the styles should be applied.
andreas: I tried it out in Opera.
zcorpan: The styling was implemented in presto - I'll put
together a quick demo and paste the link
andreas: One important point is that we put the background
color just behind the text not the box. From what I read
there's no possibility
... in WebVTT to put the background only on block level
elements, e.g. the whole region/p/div etc.
... It only puts the background behind each glyph. I think
there's a WebVTT background box concept but it doesn't seem to
apply to the block level.
glenn: So TTML allows the background to be specified on the
containing block and possibly differently on the span or the p
within the larger block.
... So this example (showing two spans each with its own
background color) wouldn't be possible?
andreas: That's right. In Europe both possibilities are in use.
... We need to be aware of this restriction in the mapping.
<zcorpan>
[15]http://w3c-test.org/webvtt/rendering/cues-with-video/proces
sing-model/basic.html has styling
[15] http://w3c-test.org/webvtt/rendering/cues-with-video/processing-model/basic.html
zcorpan: This shows how a stylesheet applies to WebVTT cues -
the stylesheet is in the HTML page and the cues use those
styles
... There's a white video behind it.
pause for 4 minutes, back at 10:33 (CET)
<zcorpan> wrt to the positioning discussion, there are open
bugs on the webvtt spec for both changing how positioning works
and for adding something that allows for exact positioning.
[16]https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=webv
tt%20positioning&list_id=43983
[16] https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=webvtt%20positioning&list_id=43983
<zcorpan>
[17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25632
[17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25632
nigel: we're reassembling...
courtney: Here's what I've discovered from writing mapping
code.
... There's an issue that we don't have an official WebVTT spec
yet - we're working off drafts that aren't versioned.
... When Andreas was talking he was using browser supported
features. This is causing a bit of an issue. The mapping I've
been doing is off the most
... current WebVTT spec version.
[18]http://dev.w3.org/html5/webvtt/
... Here are 3 categories of issue:
... 1. TTMl is more hierarchical than WebVTT
... 2. The two specs define different properties implicitly vs
explicitly.
[18] http://dev.w3.org/html5/webvtt/
3. The basic problem of converting units (value type
conversions)
scribe: Hierarchical vs Flat:
... WebVTT has a flat structure with no nested elements. TTML
provides a hierarchical structure.
... Metadata: in TTML you can nest metadata hierarchically
[shows ttm:agent holmes and Dr Watson]. In WebVTT you get a
list with no relationships between them.
... Proposal for WebVTT is hierarchical metadata keys
nigel: Is that just metadata or presentation issues too?
courtney: It may be less of an issue for presentation issues
but there are cases where we run into a similar problem.
... Another example: Calculating relative timings
hierarchically in TTML and linearly in WebVTT.
Cyril: I think some profiles restrict that.
andreas: Yes, EBU-TT-D doesn't allow nested timing.
Cyril: That raises the question which profile are we looking
at?
Courtney: Yes, we can simplify the problem by specifying a
profile.
glenn: It's useful, though it may take longer, to start from
the general case and identify where in the absence of a profile
there are issues.
... For example re timing and even styles we could define a
mapping based on the sequence of Intermediate Synchronic
Documents, to remove the timing issues.
... Just documenting these issues is useful.
nigel: We decided last week to use TTML1SE and WebVTT.
andreas: for styling there's some hierarchical structure in
WebVTT too, by application of class nodes that are nested.
courtney: Yes you can have nested styles within a cue but if
you want the same style for 10 cues you can't put them in a
fragment and declare it at the fragment level.
... Implicit vs Explicit:
... Some functionality is explicitly described by attributes or
parameters in one spec but implicitly derived in the other.
... For example, horizontal writing direction. In TTML there's
a way to specify horizontal direction but in WebVTT there isn't
(unless it's vertical) - it's inferred from the font.
glenn: tts:direction is designed to work in relation to the
Unicode bidi control characters
... absent of those you can still infer directionality based on
the content of the element, though it's harder with mixed
content.
... So the direction attribute in TTML doesn't really say
'write right to left' but does specify the default writing
direction in the absence of bidi.
courtney: WebVTT has bidi too, and rtl and ltr entities.
andreas: In Unicode the information is already there.
glenn: You have to look at the history of Unicode - people
didn't want to use nestable control codes so they wanted CSS
attributes to do the same thing.
<zcorpan>
[19]http://dev.w3.org/html5/webvtt/#h4_processing-model says
how to determine direction
[19] http://dev.w3.org/html5/webvtt/#h4_processing-model
zcorpan: The horizontal direction is taken from the text in the
cue, not from the font (in WebVTT)
... You can override it with unicode bidi characters if you
want.
nigel: Seems like there's no issue to log in our issues list.
<zcorpan> "Apply the Unicode Bidirectional Algorithm's
Paragraph Level steps to the concatenation of the values of
each WebVTT Text Object in nodes, in a pre-order, depth-first
traversal, excluding WebVTT Ruby Text Objects and their
descendants, to determine the paragraph embedding level of the
first Unicode paragraph of the cue. [BIDI]"
glenn: TTML has the CSS features as well as the plain text.
courtney: Example 2: line breaks - need to be explicit in TTML
but can be just new lines in WebVTT.
Cyril: That's due to the parser - XML requires this.
andreas: Later on we can look at xml:space attributes. From the
tests I've seen with xml:space="preserve" then line breaks
should be preserved.
<zcorpan> XML doesn't require it really
glenn: In XSL-FO there are 4 different properties. We define an
explicit mapping of xml:space to sets of those values, in TTML.
We didn't expose the full XSL-FO model.
courtney: Value Type Conversions
<glenn> tnx 4 reminder
courtney: Example 1 - times
... TTML has different time expressions, WebVTT always has
hh:mm:ss.sss with fractional seconds.
... Fortunately the ttp: namespace defines all the required
metadata to do the conversions.
... Though I'm not sure that's the case with lengths and
position values
... Again TTML allows a broader set of units - pixels, em,
cells, %ages
... I'm assuming lineHeight is sort of like em. For some TTML
documents I think you need the authored video dimensions to do
the mapping.
pal: I think if you use %age or c you don't need the video
dimensions. If you're going to use pixels then implementations
should use tts:extent on the root as well.
glenn: By specifying extent on the root you can derive a pixel
dimension - this doesn't tell you the pixel relationship to the
video though.
andreas: An issue is that in general the root container pixel
dimensions are not necessarily coincident with the video
dimensions.
... The document has no way to specify this in TTML, in
general.
pal: CFF-TT and EBU-TT-D relate the root container to the
video. IMSC introduces an aspect ratio. All the profiles
specify how the mapping goes.
andreas: For general TTML documents this is an issue.
courtney: Attribute mappings
... Some are straightforward.
... Though WebVTT IDs can be purely numeric, and xml:id doesn't
allow that. So some modification or convention may be needed,
e.g. "cue"+number.
... We could define the best practice.
... Both use BCP47 language values
... Preserve space needs further discussion.
... Styling attributes: colors, fonts etc are fairly
straightforward.
pal: Is there a subset of CSS that's supported for WebVTT?
<zcorpan> [20]http://dev.w3.org/html5/webvtt/#css-extensions is
the subset
[20] http://dev.w3.org/html5/webvtt/#css-extensions
andreas: In WebVTT there's a subset of properties that are
permitted. E.g. padding is not allowed.
courtney: One requirement set is what's needed for CEA608. It
would be useful to have a standard set of CSS classes that can
be used for any CEA608 translations into WebVTT.
... There are some properties with no WebVTT equivalent:
display, overflow, padding, showBackground.
... For alignment, displayAlign maps to the latest version of
the WebVTT spec.
andreas: I tried it out, and it would work perfectly.
courtney: But they're not widely supported yet. The mapping is
nicer at least.
<zcorpan> "the properties corresponding to the 'background'
shorthand" is allowed, if that is what showBackground does
zcorpan: any other properties will be ignored than those listed
in the spec.
... I'm not sure how the TTML features map to those but there
is a defined subset in the spec.
courtney: To expand on that, things like textDecoration in TTML
you can have underline set on a cue, but for the rest of it
you'd have to go to CSS to do?
<zcorpan> <u>
zcorpan: For underline you can use CSS or the <u> element
inside a cue.
courtney: visibility and zIndex - I can't see how to do those
in WebVTT.
... extent can be done with a cue box size or a region size.
... A lot of the timing in the ttp: namespace metadata doesn't
map to the WebVTT because the timing that's allowed is a lot
simpler.
zcorpan: visibility and zIndex is not possible in WebVTT.
nigel: can't you do visibility with opacity?
zcorpan: yes you can do visibility.
courtney: there are also the attributes "use", "value" and
"type".
glenn: Those are in the profile definition mechanism - they're
not content or style based.
Cyril: does this mean they don't have to be mapped?
courtney: since there are no profiles in WebVTT I guess not.
glenn: This is all part of the TTML way to specify what a
processor needs to support, based on SMIL and SVG originally.
... I think it can probably be ignored but needs more thought.
andreas: If we do not find a direct mapping between WebVTT and
TTML that doesn't mean that we can rule it out for the mapping
... because there's some intent in the source document and we
have to check if theres something that needs to be done.
courtney: Ruby: there's no simple mapping from WebVTT to TTML
for ruby.
glenn: In TTML1 you have to do the work at authoring time and
use regions to place the ruby in the right place.
... I've recently specified in TTML2 the ruby markup.
Cyril: There may be several ways to define the same thing, so
we should try to use a canonical representation as the mapping
source.
... For example there are several ways of expressing timing -
maybe a requirement before mapping is a single syntax. I'm not
sure if this is possible.
courtney: it may be an interesting way to break the problem up.
Cyril: A problem I've seen before is that when attributes need
to be resolved at runtime based on context, e.g. frame rate,
video size etc there's not much that can be done.
... We maybe need to classify those attributes that can be
mapped offline vs those that need full context to resolve.
courtney: that's my presentation.
Cyril: There's also the question of which TTML profile to use.
But also there are different classes of WebVTT: valid or not?
parsable or not?
... Invalid documents may be presented okay by browsers. We
should say which class we're looking at.
... Then WebVTT can represent metadata, chapters, subtitles,
captions etc. so we should indicate which ones we're mapping,
if not all.
Logical step through
nigel: Processing model
Cyril: how does TTML handle overlapping times?
glenn: there's arbitrary overlap permitted.
... The first step I'd advocate is to create the intermediate
synchronic documents and map to WebVTT.
Cyril: In WebVTT there's the concept of cues becoming active
and then bumping up existing visible cues.
some discussion of how this is handled in TTML
andreas: Formally the concept of creating the ISDs makes a lot
of sense - we need to make sure everyone understands what that
means.
glenn: I agree. For example one thing that may not be obvious
is that style inheritance is only defined on ISDs so one has to
perform the ISD creation prior to style inheritance.
... I've also added a function on the TTV tool to generate the
set of ISDs.
nigel: We have a choice here to map ISDs or specific bits of
cue text.
... This impacts efficiency and metadata.
pal: This depends on the use case - if we just have the goal of
getting equivalent presentation then efficiency and metadata
are secondary concerns.
elindstrom: from a browser perspective we're interested in
accurate presentation.
courtney: I've been thinking about it the opposite way - from a
TTML to WebVTT conversion preserving semantics.
andreas: Would it be possible to take Courtney's attribute list
and make it a structured document, take it as a header, explain
the problem scenario,
... and indicate what the options and recommendations are from
the WG?
... If you try to map abstractly the logical model then it's
very hard. Something more concrete may be a better start.
pal: This is a question of how complicated we want to make it -
I haven't heard of anyone wanting to use WebVTT as a
master/archive/mezzanine format.
glenn: There's a use case for distribution though.
pal: I can see the use case of converting the TTML experience
into a WebVTT experience.
glenn: Part of this may be timing oriented in the sense that
user agents may potentially add TTML renderers directly, which
would reduce the future needs.
... But there may still be WebVTT-only presentation devices.
pal: The issue for me is about the non-presentation-based usage
of WebVTT.
elindstrom: I don't expect that to be a huge use case.
nigel: Seems like we've been considering TTML -> WebVTT here.
Does the same consideration apply the other way?
courtney: WebVTT does roll-up - I'm not sure how we do that
with TTML.
glenn: we may need to consider using the set element in TTML1.
pal: When you say roll-up you mean where there's an animation
displayed?
glenn: yes, gradually moving up.
pal: To do that explicitly in TTML you need animation, but what
is possible is to have a region that contains line A at t=0 and
at t=1 line B is added, moving line A up.
... This doesn't require any animation.
glenn: Yes correct but it doesn't do the whole 608 animation.
pal: Then the question is do we need to explicitly define the
roll-up animation.
glenn: Yes, we put in a note that implementation might do that.
courtney: What about paint-on?
glenn: That's no problem.
... Does WebVTT support smooth roll-up as opposed to discrete
line based roll-up?
courtney: I think it does yes, I'll have to confirm.
nigel: As a general point here we can leave it open to the
converter where it's left unstated in the source spec.
courtney: There's a scroll setting on the region in WebVTT that
specifies this.
nigel: Is there anything else regarding processing model that
may affect how we do the conversions?
... So far we have: ISDs, smooth vs discrete scrolling.
... I guess discontinuous markerMode in TTML may be
non-mappable too.
glenn: I've been thinking about this too - I think it would be
modelled by playing back the related media that triggers the
discontinuous smpte events and recording the
... elapsed time to make a conversion from discontinuous to
continuous.
... There's also the clock based timing which is also
interesting! In appendix N we mapped all the timing models to a
potentially continuous timeline.
nigel: I think we should exclude discontinuous marker mode and
maybe clock mode too, as being non-mappable from TTML1 to
WebVTT.
glenn: I think there may be some TTML2 work that can support
this.
nigel: I propose to make our mapping explicitly related to
TTML1 and if there's anything that helps in TTML2 we can update
it later.
glenn: Or we can simply reference the ISD creation process.
<zcorpan> "If region's text track region scroll setting is 'up'
and region already has one child, set region's
'transition-property' to 'top' and 'transition-duration' to
'0.433s'." - smooth rollup in webvtt with scroll:up.
[21]http://dev.w3.org/html5/webvtt/#h4_processing-model
[21] http://dev.w3.org/html5/webvtt/#h4_processing-model
nigel: Maybe we can do both, and reference the ISD generation
process and make a note that in TTML 1 the process isn't
defined in a way that facilitates
... conversion to WebVTT for discontinuous and clock mode
times.
courtney: If we refer to ISD conversion rather than TTML1
what's the reference document?
glenn: I'm working on this for TTML2.
courtney: Is there a draft document to refer to?
andreas: If you make the ISD concept central to the mapping it
must be fully elaborated so that everyone can understand it.
glenn: I agree but I think there's no way to avoid it other
than to create an alternative flavour of the same thing.
... This is the only way to solve the timing hierarchy problem.
... It also gets around the style inheritance process.
andreas: Formally I agree but it's hard to communicate the ISD
- it wouldn't be a valid TTML document. So the converter
wouldn't be from TTML.
glenn: We do have examples of ISDs in the TTML1 spec, which is
something I'm adding in TTML2.
andreas: ISD creation is specified in TTML1 so I think we can
use what's there. Is anything else needed?
glenn: Yes, the only thing absent is the specification of a
serialised form. We only used ISDs as a didactic construct for
explaining the formatting model.
... In TTML2 I plan to make interchange of ISDs possible in a
standard way.
... It would also be useful for this exercise. Now I have an
implementation already those things combine to make this
progressable.
pal: For mapping can we simply assume that an ISD is a valid
TTML document that happens to be static?
glenn: almost - it's not quite the same because there's some
transformation, e.g. the body element is copied and reparented
to the region elements that are temporally active.
courtney: My feeling is that this is just trading off one set
of problems for another.
pal: I was hoping that ISD could just be used to mean 'the
state of a TTML document between successive events".
Cyril: do we have a presentation on ISDs?
glenn: No, though I could do it verbally.
andreas: Maybe if it's in the TTV software we could have a look
at some simple examples?
... So we don't get stuck here, can we start on attribute
mappings that have to be done either way?
courtney: I'd prefer to stick with TTML rather than ISDs and
defer some of these problems.
nigel: +1. Most of the problems are just about timing.
glenn: Unfortunately that's not true - there's also the problem
that associates content with regions and then performing region
style inheritance.
... In the ISD document the content has been associated with
individual regions and then region style inheritance, and if
you don't go through the ISD process then the latter breaks.
nigel: I think you can do the style computation without making
the ISD.
glenn: There's a risk of duplication of effort.
courtney: I think you can map directly.
nigel: I want to defer timing issues to ISDs and do everything
else directly.
glenn: To be clear I didn't mean previously that we need to
serialise the ISDs
Cyril: We talked earlier about categories - we need to think
about metadata etc.
pal: I've not heard those use cases.
Cyril: Can we assume that metadata-only WebVTT files are out of
scope of this?
glenn: I guess the issue is searchability - if there are use
cases that need searchability e.g. characters, roles, other
agents, then we might need to consider that.
... If we're strictly talking about presentation than maybe we
don't need to consider that.
... In WebVTT can you use metadata to define larger classes for
presentation?
courtney: The only thing I've encountered along those lines is
voice, which may be one example. The approach I've taken is
just to map what is possible to map.
... In the document we can describe what's well defined and
note what can't be supported.
andreas: I agree - we should publish something sooner and limit
certain parts to a canonical representation if there are
multiple ways to express the same thing.
... We can decide on a feature by feature basis what to limit,
for example.
Cyril: we didnt talk about which mapping direction we're
talking about.
nigel: it's both.
andreas: Additionally there are, e.g. in Germany, cases where
browsers aren't used to present content, and renderers only
understand TTML.
... So we need to go both ways.
nigel: Adjourns for lunch - return at 1330 CET.
<zcorpan> i will call in 14:00. then 15:00-15:30 i will be
absent again
<zcorpan> correction. i will call in now but be absent between
14:00-14:30 and 15:00-15:30
trackbot, this is ttml
<trackbot> Sorry, nigel, I don't understand 'trackbot, this is
ttml'. Please refer to
<[22]http://www.w3.org/2005/06/tracker/irc> for help.
[22] http://www.w3.org/2005/06/tracker/irc%3E
trackbot, start meeting
<trackbot> Meeting: Timed Text Working Group Teleconference
<trackbot> Date: 16 September 2014
<scribe> chair: nigel
<scribe> scribeNick: nigel
Agenda
nigel: We may switch things around tomorrow due to changes to
flights etc.
We will capture output at
[23]https://www.w3.org/wiki/TimedText/TTMLtoWebVTT where I
enter 'wiki' in the minutes
[23] https://www.w3.org/wiki/TimedText/TTMLtoWebVTT
Document Structure
courtney: Can we go through TTML elements?
Cyril: can we map the tt element to the top of a WebVTT
document?
glenn: explains TTML structure down to style attributes.
Cyril: Suggests defining a style class in WebVTT corresponding
to each style in TTML
glenn: yes, we can do this.
courtney: Yes. Right now the CSS document is separate, but in
the future it could be embedded.
pal: Will there be feedback into WebVTT from this?
courtney: There are competing desires here - yes, in principle.
Cyril: can we go through these?
glenn: Let's keep going with structure.
... Takes group through region properties - including style
attributes for origin and extent, and referential approach.
... Each region has an id. If there are no regions defined
there's a default, covering 100%.
Cyril: How different is this from WebVTT regions?
courtney: WebVTT regions can not have styles, but the layout
information translates pretty directly.
glenn: For example tts:opacity is a region-specific property.
backgroundColor can apply to regions independently of the
content in the region.
... There are a number of style properties that only apply to
regions.
andreas: Can a region be compared to a div element in HTML?
glenn: yes.
andreas: So this is the only element that can be positioned
absolutely within the root container.
glenn: moves to body
Cyril: Will we have an output document structure with headers
and bodies, with two subsections - for styling and layout?
Courtney: yes.
Glenn: That's not a bad way to do it.
courtney: Part of this will describe the separate CSS and
WebVTT document.
glenn: takes us down through body, div, p and span.
... div can contain div; p can not contain p; p can not contain
div; div can not contain text.
Cyril: so p is equivalent to a cue?
courtney: seems that way.
glenn: Timing can be specified on body, p, div, p, span and br.
Cyril: cues can have nested timing in spans.
pal: is there a reason why each p can't map to a cue?
glenn: my mental model of a cue is that it is not overlapping
in time with other cues. I think this makes things easier.
pal: But if we can map a p to a cue then the mapping is
simpler.
courtney: What else would it map to?
glenn: Are you still assuming time has been flattened down and
sliced?
pal: Yes.
glenn: So there are no overlaps. At that point content that is
selected into regions is present and everything else has been
filtered out.
... every piece of content is associated with a single region
in TTML.
Cyril: same in WebVTT.
glenn: So the concept is to start from body, work down, and
associate each piece of content with a region.
... So if there's a region we're not interested in we can
filter out that content.
... So there may be multiple <p>s all mapping into a single
cue.
courtney: With WebVTT you'd define regions, and for each cue
reference the region id.
glenn: That's exactly how it works in TTML but with the ability
to inherit region from an ancestor.
Cyril: So you can in principle flatten the TTML structure and
remove the <div>s.
glenn: You can't remove the <div>s because they specify breaks
and style.
Cyril: But you could propagate down.
nigel: You can paint the background of a div so if you remove
it then some information is lost.
andreas: is there a layout impact of div?
glenn: It implies a breaking boundary in the line progression
direction and it may contain styling.
group: discusses slicing apart divs into multiple <p>s each of
which generates a cue.
Cyril: so if I start by resolving all the style references on a
p, flattening out all the styles, then...
glenn: so you can now enumerate all the <p>s and <div>s and
assign each to a cue.
courtney: I think we should do that in the document.
glenn: Okay but you may end up with a lot of cues all with the
same timing. If there's no intrinsic limitation on that then we
can go ahead.
Cyril: Layout: so div affects layout?
glenn: Yes, divs can't (spatially) overlap each other within
the same region.
andreas: but the only fixed dimension defined is for the
region, so the height of each p and div depends on the content
flowed into them.
... So there's no difference between the block level boxes that
are generated by divs and ps.
Cyril: We could create artificial regions for divs that have a
background color
nigel: we may have some non-mappable functionality here, if a
region, a div, and a p all have different background colors.
glenn: Also if the div contains a div and both divs contain a
p, and all the background colors are different, then you end up
with different background paint areas
andreas: Can a div create a space that isn't occupied by a p?
If a p covers only 50% of the height of the region then its
parent div will just have the height of its contained <p>s
... and not expand to the height of the region.
glenn: So it will have the same background color as the p
courtney: you can't specify an extent on a div or a p?
glenn: no that's right.
andreas: the width is defined by the region and the height by
the flowed in content.
Cyril: so you can't have a div with a different background
color from its child <p>s?
glenn: That's right because we don't have a margin before or
after.
nigel: I think we've just resolved that <p>s map to cues
(repeating Glenn's earlier joke)!
glenn: In TTML2 we have padding on content elements not just on
region, which might impact this, but thinking about it, it
should be okay because it's not margin.
courtney: What are content elements?
glenn: body, div, p, span, br.
Cyril: What if spans have timing that's shorter than their
parent p?
glenn: If there's an explicit end on the span that makes its
active end prior to the active end of its parent then it would
depend on the fill mode - it's either freeze or remove.
... I'd have to check what we said about this, from SMIL.
andreas: in WebVTT you can have non-ended cues, that last
until... when?
glenn: In TTML if there's an explicit end on the parent
container and the child ends prior to that then there would be
two ISDs, one
... covering the first period and the other covering the second
period, and the span wouldn't be present in the second period.
nigel: +1
Cyril: so you can have a span that contains text that activates
and deactivates part way through the cue.
glenn: Yes, that would be possible in TTML.
Cyril: Can we do that in WebVTT?
courtney: I don't think so - there's only styling changes part
way through a cue.
... So spans with time on them - would we have to separate them
into separate cues?
Cyril: I don't think that would work because they'd appear on
different lines.
... You'd have to go down to the ISD level.
nigel: Can you have spans with timing?
Cyril: only to switch the text on, not off.
... So not every p is a cue, it's a bit more complicated!
glenn: If you split everything into ISDs that do not overlap
then these problems can be resolved.
... We need to look more at the details and work out if there's
a problem here.
... The only thing we didn't cover is animation. There's a set
element in TTML1 that can also delineate ISD boundaries.
... In TTML2 we're adding continuous animation using the
animate element
In TTML2 ISDs there may be some internal animation within the
ISD.
andreas: it's also worth noting that every element can have
metadata attached.
glenn: metadata, except for the ttm:agent attribute which can
appear on any content element only, and the region, which
reference agent definitions in the header,
... other metadata elements are all local not referential.
andreas: TTML also allows child elements that are not in a TTML
namespace so it can be extended. A TTML processor is required
to prune these out and not reject
... the document. But it doesn't have to display.
courtney: Does anyone know if we can have metadata in CSS
within a style class?
andreas: you can have comments.
glenn: they're ignored in the CSS object model.
zcorpan: you can have custom properties that can be used for
any purpose including metadata.
<zcorpan> [24]http://dev.w3.org/csswg/css-variables/
[24] http://dev.w3.org/csswg/css-variables/
nigel: Can we go through the WebVTT structure and see how that
maps?
courtney: WebVTT files have a header section that starts with
WEBVTT
[25]http://dev.w3.org/html5/webvtt/
[25] http://dev.w3.org/html5/webvtt/
courtney: Then there can be metadata, such as language,
copyright etc.
Cyril: so when you parse the file, big objects are separated by
double line separators.
... Every piece of text separated by two lines is either a cue
or is a comment not for display.
andreas: but comments are not defined?
<zcorpan> [26]http://dev.w3.org/html5/webvtt/#webvtt-comments
comments are defined here
[26] http://dev.w3.org/html5/webvtt/#webvtt-comments
Cyril: no. For example in MP4 carriage you could remove it, or
put it in a previous or next segment - it won't be displayed.
courtney: In the header section you can also include region
definitions.
nigel: so you can't have untimed cues?
Cyril: yes. Can you in TTML?
nigel: yes you can - they have the duration of the whole
document (assuming there's no inherited time from a parent time
container etc)
Cyril: this is in flux in the WebVTT standard, using keywords
like 'Next' for 'until the next cue'.
glenn: during the conceptual ISD mapping process every piece of
content gets timed. Ultimately the active period of the related
media object will determine that time,
... in the absence of any other information.
andreas: We also have to think about multiple <br> in TTML
documents, which are allowed, but shouldn't generate multiple
line breaks because they wouldn't
... be displayed in WebVTT.
Cyril: so you could define line numbering or put non-breaking
spaces on otherwise empty lines. I'm not sure how the
backgrounds would be painted for spaces.
... records issue on wiki
andreas: You can use empty spans on each line.
courtney: Identifiers are used - each cue can have an
identifier, which would show up before the begin and end time
lines.
... Also regions have ids that can be referenced in cues.
Cyril: Those cue ids come from SRT - in SRT each cue has to be
a monotonically increasing number with no gaps.
... it's very common to have WebVTT files with numeric
identifiers.
andreas: and the ids can have spaces in between, which isn't
permitted in xml:id
courtney: so we should have a convention for mapping to TTML
Ids.
nigel: Can VTT cue ids be duplicated?
courtney: no.
nigel: the reason for mentioning it is that if we do TTML ISD
-> Cue then the same TTML id may resolve to multiple cues.
courtney: there's something to think about here with slicing
VTT cues into time slices.
Cyrill: As long as all the spans in a p aligns with the end
times of the p then you can keep it as a single cue.
nigel: that's a special case - think of live word by word
subtitles.
Cyril: cues have to be laid out in start time order.
... Within a cue you can have internal timing values, that I
think also have to be in increasing time order (I'm not sure
about that).
... can you have TTML spans that display in reverse time order
compared to the document order?
glenn: Yes, there are no constraints.
Cyril: what about in profiles?
pal: I haven't seen any profile that constrains that out.
glenn: if the TTML time container is a par (parallel) time
container than a child can start after one of its preceding
siblings.
... the order in the content will define the order of
presentation order (spatially).
pal: IMSC 1 allows a document to be labelled progressively
decodable which forbids timing on descendants of <p>s.
courtney: So that needs to be in the document, i.e. temporal
ordering within the document.
andreas: EBU-TT-D doesn't constrain this but recommends time
ordering. Most legacy formats are sequentially ordered in time
as well.
Cyril: even if the <p>s were out of order in time that wouldn't
be a problem, but out of order <span>s would be a problem.
pal: But going to ISD level would avoid that.
Cyril: adds this issue to the wiki
nigel: Do we have to worry about rtl direction when sorting
spans into order in WebVTT?
glenn: I would expect that when a span is active all text
content of active spans are merged and then directionality is
applied on the result.
courtney: let's leave the identifier mapping convention until
later.
nigel: Voice spans are straightforward aren't they?
courtney: I think voice maps to agent pretty well.
nigel: +1
... What about styling based on voice cue selectors?
courtney: You could define a TTML style for each agent.
... Along those lines you can put styling directly on a span -
in WebVTT I think you'd have to define CSS classes for those.
Cyril: you may not have to scan the whole document but could
create a random hash for every time one is encountered.
... I'm also interested in streaming, transcoding live streams.
glenn: If it's not been converted into an ISD sequence then you
can't avoid parsing the whole document (unless it's
progressively decodable).
... You never know if the last markup element will be timed
prior to the rest.
Cyril: WebVTT documents are always progressively decodable.
... go to example just before section 2 - this has multiple
lines in the header. In this case Regions, but it could be
copyright, anything else.
... So some parts of the header map to regions and others to
metadata.
... continuing on document structure.
... Each cue has a timestamp for start and end, followed by
optional settings.
Courtney: There are additional settings available.
Cyril: they are a combination of styling and layout.
nigel: What about at the end of the document?
Courtney: there's nothing to mark the ends of documents.
Cyril: that's a feature - you can concatenate two WebVTT files,
and if the timestamps obey the time rules then it's valid.
... The second header would be ignored.
pal: what about styles?
andreas: We also need to think about error handling -
processing of invalid documents.
nigel: Can we simply constrain our mapping to input documents
that are valid?
Cyril: maybe not - we could consider the WebVTT to TTML mapping
to do what a presentation processor would do when given an
invalid document
... The behaviour is well defined.
nigel: Let's take a break until 1545...
<zcorpan> re "nigel: Can VTT cue ids be duplicated?" - yes,
there is no requirement about uniqueness for cue identifiers.
however region identifiers need to be unique and don't allow
spaces
<zcorpan> hmm. sorry, looks like cue id requires uniqueness
also. i think that changed from a few years ago
<zcorpan> looks like the spec allows a cue id to be duplicated
as region id
Restarting...
Layout
andreas: We should start with the positioning of a <p> element
relative to a region.
courtney: The positioning is the piece that will map into
WebVTT. There are several region attributes in TTML that can
not go in WebVTT.
group: discussion of xml:lang on <region> and how it may get
inherited by content elements in TTML.
... discussion of style attributes on region - which must be
included?
courtney: Maybe we should go through each attribute.
<tmichel> I just joined Zakim using SIP. It works for me using
code ttml#
<zcorpan> i still get "this passcode is not valid"
glenn: I have a list of style attributes that apply to region.
... there are 12 in TTML1, and of those, 9 apply only to
region.
... Styles that apply both to region and other content elements
are backgroundColor, display and visibility.
... the ones that apply only to region in TTML1 are
displayAlign, extent, opacity, origin, overflow, padding,
showBackground, writingMode and zIndex.
... Note that at least one of these will be opened up to
content elements in TTML2, which is padding.
... We may also open up opacity to content elements, which
would allow the definition of opacity for an element and its
content as a collection.
andreas: Should we rule out the attributes that will change in
TTML2?
glenn: In fact opacity and padding are extended to all content
elements in TTML2.
... In both cases they aren't being removed from region, so
they are still applicable to region in ttml2.
courtney: So let's start with those. I believe that only 3 map
to a region in WebVTT: displayAlign, extent and origin.
andreas: And they can be mapped to properties of the region?
nigel: can't you do visibility by setting a style with opacity
zero?
courtney: you can do that but only on a cue, not on a region.
nigel: So another way to say the same thing is that there's no
region selector for styling?
courtney: Yes.
nigel: does the lack of zIndex imply that in WebVTT overlapping
regions are prohibited?
courtney: I don't think they're prohibited.
glenn: In TTML2 on this subject we have a request for
expressing z ordering for content to be able to handle 3D.
pal: That sounds similar but it's a different concept.
Loretta: I'm trying to see if the magic layout algorithm
applies to region as well.
... In general there's no notion of zIndex in WebVTT.
nigel: Is there an alternative way to achieve backgroundColor
on regions in WebVTT?
courtney: I don't think so, you can only do it for cues.
Cyril: adds non-mappable showBackground on region and zIndex to
the wiki.
courtney: overflow is always hidden for regions too.
glenn: Can wrapping be prevented so that overflow may be
relevant?
... Or what happens if you put too much content into a region
i.e. too many lines?
... It sounds like extent, origin and displayAlign are
currently expressible. The other 9 attributes seem to be
absent.
... display seems to be only worthwhile in conjunction with
animate.
nigel: It seems that the pseudo classes past and future have
some relationship to animate.
andreas: Wants to note that when we finish on the TTML
attributes we should go the other way round.
courtney: Let's do the non-style attributes on a region
first...
... You can put timing on a region in TTML - there's no
equivalent in WebVTT. attributes begin, end, dur, timeContainer
glenn: timeContainer is on regions for the processing of
animate elements that are children of region.
<Loretta> Does the cue-region pseudo-element let us apply CSS
styles to regions?
nigel: What's the action on that - to add it to the
non-mappable list?
Cyril: why have timing on regions?
glenn: The main reason is to provide timing for background
painting when no content is active, and also to specify the
timing for animate elements that are children of that region.
Cyril: I'm not sure it's not mappable - you can have empty cues
applied to a region, with the equivalent times of the TTML
region.
... Then that would activate the region in the same way - what
happens then is a later question, e.g. background painting.
glenn: Actually the timing of a region in TTML can be used to
temporally clip the flow of content into that region, so it's a
bit more than that.
... The question really is: do implementations use animate?
pal: I'm going to check the examples I have.
... another thing is how do you achieve dynamic positioning for
text? One way is to create one region per subtitle.
... In that case you may be tempted to put the timing on the
region.
Loretta: What are you trying to do here?
pal: In TTML1 there's no per-cue positioning, e.g. of each <p>.
One way to achieve that effect is to define one region per
subtitle and position each region
... individually.
andreas: From the layout perspective, there's a chance that
timings are put on region elements.
courtney: Shall we talk about the things that do map?
... On a WebVTT region the available settings are: width,
lines, region-anchor, viewport-anchor and scroll.
... I believe that extent in TTML maps to width and lines.
... We have the dimension issues for value units, e.g. if it's
in %age then it's okay but in pixels you need the size to do
the unit conversion.
... I think that displayAlign and origin in TTML, in
combination, map to a combination of regionAnchor and
viewportAnchor in WebVTT. The two specs have
... different ways to achieve the same thing. In WebVTT you
define a point within the video frame that maps to a point
within the region and they don't necessarily
... have to be the same thing. Origin + displayAlign allows you
to achieve the same effect.
nigel: I thought there was some freedom in WebVTT about the
precise positioning, whereas in TTML there's no freedom of
movement - is that right?
Loretta: I'm still wading through the WebVTT algorithm.
Certainly for cues things get moved around to be as close as
possible to the stated location.
nigel: Yes, I'm not sure if that applies to regions as well as
cues.
Loretta: Yes, I think it may do - I'm still checking.
courtney: I think we should take that offline and research it.
andreas: I see a problem with the lines value - this defines
the height of the region. A line is defined by the height of
the first line of the cue, so a region does not
... always have the same height, as it depends on the first
line's size. This is a hard topic to research in general, how
this will resolve.
nigel: What's a concrete example of that problem?
andreas: In general the mapping from TTML to WebVTT may not be
possible because for each cue selected into the same region the
line height could be different,
... which will result in the region changing height.
Loretta: presumably WebVTT would expand the region to
accommodate the 5 lines and TTML would clip?
glenn: That would depend on lineHeight, fontSize and overflow
attributes in TTML.
... Right now we don't have an object-fitting algorithm such as
in CSS.
Loretta: Is there a way of setting font-relative dimensions?
glenn: yes, they can be defined in ems or cells. Ems would be
font-relative.
andreas: Why is region height important for WebVTT when no
background can be drawn?
Loretta: the height is important because that determines when
scrolling will start.
nigel: This seems very similar to the overflow attribute in
TTML - if some lines fall out of a region, which ones should an
implementation hide?
glenn: That's an implementation issue.
andreas: Can you explain the difference between the region
anchor point and the viewport anchor point?
courtney: the region anchor setting defines a point that is
fixed in location relative to the region, in case the region
has to grow.
... the viewport anchor setting defines where in the video the
region must overlap.
... It needs to be understood in relation with the
display-align setting.
Loretta: right, we need two points. It's like sticking a pin
through the region and in the viewport, and any changes to
region size keep that point invariant.
courtney: the region viewport anchor setting has two points
defined, the point within the video and the point within the
region.
... Then there's an additional point that is held constant when
the region is resized.
ack
nigel: I think we need to understand the region mapping
algorithm from WebVTT - to origin and extent, and if that's a
single value or if there are multiple values,
... which in TTML we can do using set elements on the region.
... I think we need a strawman algorithm for this mapping so
that we can look at it.
andreas: I propose a gist on github for example.
courtney: I'll take it as an action item to come up with a
strawman proposal.
glenn: A moment ago I thought I heard something about origin
being in the centre in TTML - was that the question?
Courtney: yes, would you do that with displayAlign?
glenn: origin is always top left. You can use displayAlign to
define where lines are drawn from - in which direction. Right
now there's no anchor mechanism in TTML.
... Sean did come up with a change proposal, which I will have
to try to dig out.
courtney: It's always top left?
glenn: yes.
nigel: In scope terms, do we need to consider the placement of
text within regions, and also the placement of text not in
regions?
<glenn>
[27]https://www.w3.org/wiki/TTML/changeProposal015#region_ancho
r_points
[27] https://www.w3.org/wiki/TTML/changeProposal015#region_anchor_points
glenn: on the prior point, change proposal 15 has a section on
this.
... This is proposed for TTML2, but not implemented yet.
courtney: In WebVTT cues can have positioning - in TTML1 they
don't. So in the mapping to TTML we need to translate to a
region.
glenn: In TTML2 we are defining inline region definitions, so
div and p in TTML2 can take a child region element, including
extent and origin.
andreas: This is sometimes misused in operation!
... In mapping from WebVTT with no region and snap to lines is
active, from the WebVTT spec it looks like margins need to be
added top and bottom. Is that correct?
... If the first line is not to be at the bottom and the last
line must not be at the bottom, that is.
... We need clarifications of this for accurate mapping.
... will add to the Issues list on the wiki
Summary of the day
nigel: We've looked at existing work from Andreas and Courtney,
thought about the processing models and document structures,
... identified that style attributes should mostly transfer
straightforwardly, thought about metadata a bit, and spent a
while on layout.
... Tomorrow we have some time set aside for testing, and I
suggest we combine the test case generation with the mapping
algorithms.
... Thank you everyone, see you tomorrow.
adjourns meeting.
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [28]scribe.perl version
1.138 ([29]CVS log)
$Date: 2014-09-16 15:07:16 $
__________________________________________________________
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 17 September 2014 02:09:19 UTC