- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Mon, 19 Sep 2016 17:32:07 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <5941EAB8802D6745A7D363D7B37BD1F773F85F33@bgb01xud1012>
Thanks all for a very productive first day of our Lisbon TPAC face to face meeting. Minutes can be found in html format at https://www.w3.org/2016/09/19-tt-minutes.html
We made 1 resolution:
RESOLUTION: If we do not move WebVTT to CR in this Charter period then we will not include it in any new Charter.
The review period for this resolution under our Decision Process ends on Monday 3rd October.
Minutes in text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
19 Sep 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/09/19-tt-irc
Attendees
Present
Rohit, Nigel, Glenn, Thierry, Dae, Andreas, David,
Pierre
Regrets
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]Agenda bash
2. [5]Plan for Joint Meeting with Web & TV IG
3. [6]WebVTT stuff
4. [7]Tagging
5. [8]TTML1 Errata
6. [9]TTML2 Pull Requests
7. [10]IMSC 2
8. [11]Agenda bash
9. [12]TTML2 implementation work
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
Agenda bash
group: [discusses topics on meeting page
[15]https://www.w3.org/wiki/TimedText/tpac2016#Schedule
[15] https://www.w3.org/wiki/TimedText/tpac2016#Schedule
<glenn> +Present Glenn
nigel: Seems like the topics list is pretty close to the order
we want to cover stuff in.
Plan for Joint Meeting with Web & TV IG
nigel: We are meeting the Web & TV IG at 11, so need to provide
an update etc.
... Discusses proposal for Web & TV IG consisting of update on
our work in TTML,
... audio description requirements, issue of relationship
between encoded video, media player
... and timed text presentation; live contribution and BBC
subtitle guidelines. (last two points from Nigel with a
different hat on!)
andreas: I have some slides to discuss on TextTrackCue
interface support for different formats in HTML5.
... I would also point to the unconference session on this on
Wednesday. They may also
... want to log this as work that needs doing by a Web & TV IG
task force.
nigel: Good idea, let's do that ahead of my stuff on AD, live
contribution etc.
andreas: [Previews slides] including missing MIME type on track
element in HTML5
nigel: Thanks, let's do that after the TTWG update and if
there's time to hand back to me for the other parts then let's
do that.
WebVTT stuff
david: Number one priority is to find a new Chair to cover this
topic - I've indicated already to
... plh etc that I don't have the time to devote to this.
glenn: What's the status of implementation work?
david: At Apple it's bug fixing, keeping up with customers.
glenn: On the Chrome and webkit list I don't see much activity.
I am not following mozilla or Edge.
... What's the status in other groups e.g. MPEG referencing
WebVTT?
david: The Chair does need to make progress on moving it to Rec
so it can be normatively referenced.
... There is implementation work excluding region support in
many implementations.
andreas: I think there have been updates to the specification
that have not been reflected in
... implementations so this is a problem.
nigel: I've noticed that too - Simon made some really good
changes around 10-11 months ago,
... which i suspect have not been implemented. I'm not sure
about the status of editing to
... address the readability review feedback.
david: Apple's implementations predate those changes.
andreas: It's hard to know if those changes will ever make it
into implementations.
nigel: From a BBC perspective there are features that are
essential for accessibility that look
... like they would have to be put at risk for CR due to lack
of implementation, so that would
... be a "red flag" for me.
... For example the BBC's editorial guidelines at
[16]http://bbc.github.io/subtitle-guidelines/
... cannot I believe be met by most implementations of WebVTT
right now.
[16] http://bbc.github.io/subtitle-guidelines/
action-475?
<trackbot> action-475 -- Nigel Megitt to Contact the chair of
the web & tv ig to ask about schedule and joint meeting time.
-- due 2016-07-28 -- OPEN
<trackbot>
[17]http://www.w3.org/AudioVideo/TT/tracker/actions/475
[17] http://www.w3.org/AudioVideo/TT/tracker/actions/475
nigel: oops I meant:
action-473?
<trackbot> action-473 -- Thierry Michel to Contact co-chairs
and essential parties on how to move forward on vtt; need an
action plan -- due 2016-06-30 -- OPEN
<trackbot>
[18]http://www.w3.org/AudioVideo/TT/tracker/actions/473
[18] http://www.w3.org/AudioVideo/TT/tracker/actions/473
nigel: Thierry did this, but I don't believe we have an action
plan.
david: We need a suitable volunteer to go through the review
comments and respond.
thierry: The Community Group has looked into the review
feedback - about 30 comments
... have been discussed: that's the current status. Now those
comments need to be approved
... by the TTWG (and discussed) and then we should send those
responses to the commenters.
... At some point we need to coordinate between the CG and the
WG to progress those.
... This has not changed for more than a year, probably because
some people involved have
... left and Simon does not participate actively in the WG. We
are experiencing joint work with
... a CG and a WG and we need to invent a process to deal with
this.
nigel: This works both ways - the WG also has not scheduled any
effort to work on this.
andreas: I'm not really convinced that the CG exists as a
traditionally defined group.
nigel: Shall we close the action? The "contact the chairs" part
is done, we're missing an action plan.
david: Leave it open.
action-473: Discussed in TTWG F2F 2016-09-19 - need a volunteer
to progress this, possibly a new Chair.
<trackbot> Notes added to action-473 Contact co-chairs and
essential parties on how to move forward on vtt; need an action
plan.
action-396?
<trackbot> action-396 -- David Singer to Produce evidence of
request for wide review for webvtt, for the archive -- due
2015-04-17 -- OPEN
<trackbot>
[19]http://www.w3.org/AudioVideo/TT/tracker/actions/396
[19] http://www.w3.org/AudioVideo/TT/tracker/actions/396
david: I have not yet done this.
action-396: TTWG F2F meeting 2016-09-19: David has not been
able to do this yet.
<trackbot> Notes added to action-396 Produce evidence of
request for wide review for webvtt, for the archive.
nigel: TO be controversial/challenging, WebVTT has been on our
Charter since 2013 and we
... have made very little progress. Should we drop it?
david: If we don't complete it in this Charter period [end
March 2018] then we should not
... recharter it - I propose that as a resolution.
PROPOSAL: If we do not make progress on moving WebVTT to
Recommendation in this Charter period we do not intend to
include it on any rechartering.
thierry: That's a final step - I think we should be aiming to
move to CR well before that.
david: I agree.
glenn: We could publish it as a WG Note, to make it easier for
external people to reference.
nigel: This is a lot easier.
thierry: That would probably be a final step to that work.
nigel: In fact publishing a Note is a process requirement if we
stop working on it.
thierry: We would do that if we removed it from the Charter.
glenn: It would be helpful to have a document that does not
have the word "Draft" in it.
thierry: I'm happy to help with the wide review; that's one
thing. The second thing is the CR.
... We could stay in CR for a couple of years and monitor
implementation work, or we could
... remove non-implemented features. Right now there are a lot
of features that are not
... implemented. That's something we could do in parallel.
Maybe it is not useful to have
... comments on features that we are likely to drop.
nigel: I want to signal that if we have to drop features that
are essential for accessibility then
... I will have to object to it progressing.
thierry: There's also a lack of specification text on
integrating CSS. We could maybe save time
... by not addressing issues that we know are unlikely to be
implemented in the next two years.
group: discussion about who is interested in contributing to
implementation work etc and therefore progressing responses to
comments.
RESOLUTION: If we do not move WebVTT to CR in this Charter
period then we will not include it in any new Charter.
andreas: We could mention the TTML to WebVTT mapping document
in the Web & TV IG meeting.
... We published it last year and are awaiting implementation
comments. We are waiting for a
... stable reference for WebVTT in order to proceed.
thierry: You would expect to see at least a CR document?
andreas: CR would clearly indicate a stable set of features you
can map against.
Tagging
david: DASH and the MP4 file format have a way to tag the kind
of role of a track, using a URI
... to identify the vocabulary used, and then a term from that
vocabulary. I need a URI to
... refer to the @kind vocabulary in the HTML5 specification,
and there isn't one.
pierre: There is one but it is not complete, specified in DASH.
david: It is not specified in the HTML document itself.
pierre: That's correct. As long as we can reference the one in
DASH that can be used.
david: Agreed there is a DASH vocabulary.
pierre: So the request to add one to HTML is not required for
MPEG CMAF because the DASH one can be used.
david: I got agreement from WHATWG and the Web Platform WG for
about:html-kind as the URI
... that refers to the @kind vocabulary in the HTML
specification.
... And I have registered that with IANA.
... I'm waiting for that URI to appear in a revision of the Web
Platform docs. When it is then
... I will update the IANA form.
nigel: It's good to have that but I would note that in my view
the kind vocabulary is terrible.
glenn: There are some semantics associated, such as prevention
of display of metadata tracks by the UA.
david: I would agree that the HTML vocabulary is both under-
and over-specified simultaneously! (in different ways)
nigel: In my view it is insufficiently rich to describe the
purpose and intent of the track data.
pierre: It would be great if as making the HTML vocabulary more
official we could also fix it.
david: I support that.
... CMAF does prefer DASH at the moment - it says to use the
DASH term if it supports what you want to do.
nigel: I also note that we have not addressed how to extract
something equivalent to kind
... within a timed text document so that it can be extracted
and used to embed into a host HTML page.
... We did address language recently, but not kind.
david: Some people want to manage external manifest files, but
I'm in favour of self describing documents.
... I'm also aware of ongoing discussions about tags for easy
to read captions (mandated by FCC) and karaoke.
pierre: There is a very specific definition of those two terms
in karaoke.
glenn: In TTML2 we have a named metadata item for easy reader.
There's nothing on karaoke per se.
... nothing that uses that term in TTML2.
nigel: [adjourns for a break] - let's meet in Auditorium IV at
1100 for our update to Web & TV IG.
<nigel_> nigel: Joint meeting - see #webtv
TTML1 Errata
nigel: Are there any other errata other than for backgrounds on
spans and lines?
pierre: The only thing I'd mention is that the computed style
resolution for % is very well defined
... but the computed style for em is not so clear when you say
e.g. tts:fontSize="2em" but
... that is with respect to the current font size but that is
not well defined in TTML1. I assume
... it is relative to the parent element's font size but it
does not say that clearly.
glenn: I would consult TTML1 and then go back and reference
XSL-FO which would take me
... to CSS2. Without having done a recent review of that I
don't know off the top of my head
... but I'm pretty sure you're right - it would have to make
use of the computed font size of
... the parent element.
pierre: Notice that we already have issue #206 on the ttml1
repo which is a bug about
... specifying em units for fontSize on region.
nigel: That sounds very similar.
glenn: Right now there are 23 open issues on TTML1 so I would
expect that there are some
... errata to be written for those and they probably also need
to be fixed in TTML 2 also.
pierre: I can go ahead and create an issue for this.
glenn: Go ahead - also refer to #206 - it may be related but
more general.
... I think I propose that it should be in relation to 1c.
pierre: That was my first thought, but looking at XSL-FO I
think it is probably more like %.
nigel: Okay, so the one on the agenda is:
[20]https://github.com/w3c/ttml1/issues/209
[20] https://github.com/w3c/ttml1/issues/209
andreas: I think there has not been much progress since we last
discussed it. We said we need
... more investigation to find a good solution. I want to point
to something related.
... This problem about gaps between lines has been addressed by
the HbbTV 2.0.1 spec
... which a lot of televisions will implement. At the moment
that is not really interoperable
... and compatible with IMSC 1 so we should pay attention to
it.
... References spec text from HbbTV 2.0.1 that, specific to
EBU-TT-D 1.0 defines that
... where the lineHeight is "normal" or <125% the background of
each generated inline area
... shall be rendered such that there are no gaps between the
rendered backgrounds of
... adjacent lines.
glenn: We have a quasi default of doing what CSS does, which is
different from what this suggests.
... This mandates behaviour that is at variance with the XSL-FO
and CSS behaviour.
andreas: Yes.
glenn: By the way issue #209 on the TTML spec has a length
discussion on this.
... The bottom line in my reading is that the height of an
inline area in CSS is implementation defined.
... Different implementations have fine tuned themselves to be
consistent with each other, outside of any spec.
nigel: You can see an editorial requirement example of this at
[21]http://bbc.github.io/subtitle-guidelines/#Background-size
[21] http://bbc.github.io/subtitle-guidelines/#Background-size
glenn: I agree that we need to nail this down - also see issue
#212 in TTML1.
nigel: [22]https://github.com/w3c/ttml1/issues/212
... [23]https://github.com/w3c/ttml1/issues/209
[22] https://github.com/w3c/ttml1/issues/212
[23] https://github.com/w3c/ttml1/issues/209
pierre: A browser based CSS implementation would display a gap?
glenn: Correct
andreas: There are scripting techniques for getting around
this.
pierre: If we feel this is a common requirement for
accessibility then it needs to be addressed in the CSS WG
glenn: I've had a detailed offline discussion with Bert Bos
about this and he pointed out that
... one of the advanced level 4 modules might at some point be
able to deal with this.
... There are a whole bunch of assumptions in CSS on inline
non-replaceable areas, for example
... you cannot specify the content height manually. The height
property explicitly does not
... apply. That was the first problem we ran into, because we
wanted the height of the content
... box to extend to the line area. Somewhere I proposed a mode
for the style engine to use
... different semantics for the height of content areas. The
question is can you have a profile
... that defaults the parameter to a particular value.
nigel: The pressing need here is to issue some statement on
this for TTML1.
piere: I recall that some people use a style where they do
actually want the gap.
andreas: yes, for example if you have the lineheight at 200%
you don't want such a big background area.
pierre: In CSS can you always add padding to every line?
glenn: You can but the problem is you cannot determine at
authoring time what value to add.
... At first order we should document more carefully what the
current situation is in TTML1.
... That may allow people to come up with no-gap semantics. We
could define the default
... semantics to be the no-gap scenario but if we do that we
need to allow the author to define
... the other behaviour. If we change the default now what
would that break?
nigel: I understand that the content rectangle is not well
defined?
glenn: It is not, but all the browser implementations do it
roughly the same way.
nigel: Could we add an informative note via an erratum to say
that the content rectangle is
... not well defined but is commonly implemented so that it
does not go to the line height?
pierre: That's not what I'm hearing. I think CSS needs to
address this.
glenn: I'm worried that we cannot easily go back and
retroactively define the content height
... to never show a gap.
pierre: It would be easier to do that if it were not that some
folk like the gap.
glenn: In TTML2 we can add a new mode that drives that, but in
TTML1 what can we do?
andreas: This requirement for no gaps came from accessibility
guidelines to get proper presentation.
... The minimum we could say is that some specifications could
define this.
pierre: If someone is overriding that rendering it needs to be
flagged.
andreas: That will not change, I think this is more of an
interoperability problem.
... There is an initial step e.g. for an IMSC 1.1, and then a
long term TTML2 solution.
... For now we should say something about this in TTML1.
pierre: +1
andreas: I would also hope for a liaison to respond to this.
glenn: We can note that the algorithm for content height is not
concretely defined and that
... browsers do behave the same with current CSS
implementations and will introduce a gap.
... If we do want a new TTML1 feature we could write a short
specification introducing a
... ttsx namespace style that is interpreted in a particular
way.
andreas: Ideally if there is a proper parameter to control this
it should be defined in this group.
nigel: +1
glenn: That would be an official extension to TTML1, which we
could say maps to a particular
... syntax and semantic in TTML2.
... That might be an approach.
pierre: If there is an urgent need to address real problems we
should address it in IMSC 1.1.
glenn: I've heard 3 things: 1. Clarify TTML1 with an errata -
we can do that non-controversially.
... 2. We can define new mechanisms in TTML2 - we can do that
no problem.
... 3. More controversially, define a new extension style for
TTML1. That creates another fork
... in the implementation space.
andreas: The target when this was discussed was an IMSC 1.1
version. If that is possible we
... should do that.
pierre: Absolutely. The question is if there is an urgent need
to resolve an industry problem now.
... The worst thing would be to make a change that does not
solve the problem.
andreas: HbbTV has solved this for now - it would be
interesting to know if this breaks
... current implementations.
pierre: it would be good to have a formal communication with
HbbTV about this issue.
... It is essential that HbbTV is encouraged to communicate
their requirements to this group and we should be welcoming of
this, even if we make the initial communication.
andreas: We should also be clear that it is needed for
interoperability to establish this communication channel.
nigel: Notes that independent of HbbTV the BBC raised this
issue on TTML2 and andreas opened the equivalent on TTML1.
... I want to come back to what we can do here.
andreas: There's the formal comms with HbbTV, an errata for
TTML1, and a discussion about
... how to fix for TTML2. If there is no formal requirement for
this then it will not happen in IMSC 1.
pierre: BBC has raised this for TTML2, but the timescale for
that is very different than for TTML1.
... To make a change on TTML1 requires a higher threshold, so
if there is a group such as
... HbbTV that needs this in the short term then we should do
it.
<scribe> ACTION: nigel Draft a liaison to HbbTV requesting
further information and proposing an option e.g. to extend IMSC
1 to allow signalling of background height on span, and request
timelines etc. [recorded in
[24]http://www.w3.org/2016/09/19-tt-minutes.html#action01]
[24] http://www.w3.org/2016/09/19-tt-minutes.html#action01]
<trackbot> Created ACTION-478 - Draft a liaison to hbbtv
requesting further information and proposing an option e.g. to
extend imsc 1 to allow signalling of background height on span,
and request timelines etc. [on Nigel Megitt - due 2016-09-26].
nigel: Okay, that works; I would also still like to see the
erratum on TTML1 to provide the context
... for any update to IMSC 1 to allow signalling this
behaviour.
glenn: I have added a comment on the issue at
[25]https://github.com/w3c/ttml1/issues/209#issuecomment-247973
673
[25] https://github.com/w3c/ttml1/issues/209#issuecomment-247973673
nigel: Thank you!
glenn: Of course that doesn't explain what to do about it, but
that's for [26]https://github.com/w3c/ttml2/issues/150
... We have consensus in TTLM2 to solve this?
[26] https://github.com/w3c/ttml2/issues/150
nigel: Yes please!
glenn: I have a bpd content proposal where I define 7 possible
values.
nigel: That may be more than we need - let's review.
... Thanks for the good discussion everyone, let's adjourn for
lunch and return at 1400.
TTML2 Pull Requests
nigel: First up, [27]https://github.com/w3c/ttml2/pull/177 Add
tts:background{Clip,Extent,Origin}
[27] https://github.com/w3c/ttml2/pull/177
glenn: This is for image rendering support - I missed a couple
of items from CSS: there is
... an editorial note to add them.
... I ended up using backgroundExtent rather than
backgroundSize for consistency.
nigel: Just a note on reviewing the PRs - they don't include
the built HTML so it's hard to
... review or diff. I'd like a CI tool to build the HTML
automatically so we can review it.
glenn: I could do the build and check in the built HTML but
then on pulling I would have to
... remove it and build it again for gh-pages.
... I'll go ahead and make a change to make these easier to
review.
<glenn>
[28]https://www.w3.org/TR/css3-background/#the-background-origi
n
[28] https://www.w3.org/TR/css3-background/#the-background-origin
nigel: So now we have backgroundOrigin as well as
backgroundPosition?
glenn: We may want to rename these!
nigel: (notes that this looks analogous to origin and position
but is not)
glenn: backgroundOrigin defines where the background is drawn
relative to the content.
... This is as defined in CSS3 backgrounds and borders - it's
the same semantic.
... I took off the -box suffix that's on CSS3.
nigel: I sense that there are some changes needed here to clear
up the names and make them
... less potentially confusing. Also I'd encourage review of
this in the context of IMSC 2
... if we want to support image placement in more detail.
pierre: This does not express how you would use SMPTE
background image in IMSC 1.
glenn: That's actually mapped to the image element.
pierre: yes.
glenn: However we did define background image also in TTML2 and
these attributes
... I believe fully define the semantics for background images.
... In the case of a foreground image these don't come up
because they define the content
... rectangle. There's never a box in which to position it -
that only applies when the image
... is used for the background. Also bear in mind that
background images may be repeated
... in x and y directions, which can never happen with
foreground images.
... For foreground image size you would use bpd and ipd rather
than backgroundExtent.
... I need to think if it would ever be applicable to have the
same semantic as backgroundExtent
... on a foreground image. I want to see if CSS allows that
property on the image element
... in HTML and what does it mean.
nigel: Just considering the use cases for this - one that comes
to mind is the use of a
... graduated fill background image that is animated to move
along behind foreground text
... for karaoke usage. Do these semantics support that?
glenn: Yes I think you could animate the x and y positions,
either discretely or continuous.
nigel: The conclusions for the time being are 1) that more
thinking is needed for the names
... and 2) whether backgroundExtent can apply to foreground
images.
... For the hard of thinking, some example images etc would
really help, since the terminology
... has a lot of repetition that makes it hard to understand
the differences.
... I've added some notes to the issue.
... Moving on to Add support for rounded borders by introducing
<border-radii> compone...
... [29]https://github.com/w3c/ttml2/pull/179
[29] https://github.com/w3c/ttml2/pull/179
nigel_and_glenn: [discussion of single value processor
semantics for border radii without consensus emerging]
glenn: The more interesting case is the one raised in the issue
[30]https://github.com/w3c/ttml2/issues/176
[30] https://github.com/w3c/ttml2/issues/176
nigel: explains images in issue
glenn: I would suggest an optional token for this and a default
behaviour in case nothing is specified.
... We also have to set up some context for when it might apply
- it would not apply when
... all the line areas are the same length - you are proposing
a process for merging the
... background areas.
nigel: Yes
glenn: Would you allow me to merge this PR and address your
issue as a later iteration?
nigel: Yes, that allows progress.
glenn: I agree with the issue - I might consult others in CSS
land for their opinions too.
... It may even be in background and borders 4, I need to check
... How to specify merged background areas with radii when
there is no corner is harder
... to specify - I'm sure it's possible but it requires a bit
of thought.
nigel: Agreed!
... Okay, next one is Add missing two component expression to
<position> value syntax.
[31]https://github.com/w3c/ttml2/pull/180
... I added a comment about the ambiguity here.
[31] https://github.com/w3c/ttml2/pull/180
glenn: The ambiguity is resolved by the two value to four value
mapping tables.
... The last entry is ambiguous I agree since it does not
distinguish the lengths
nigel: Even if this is normative and clear I would prefer at
least note to point people at the
... order preference.
glenn: I'll see what I can do while I'm also dealing with the
last line in the table.
nigel: Let's take a break - back here at 1545
... Next is Remove cea{608,708} prefix from named items.
[32]https://github.com/w3c/ttml2/pull/182
[32] https://github.com/w3c/ttml2/pull/182
glenn: I had the same question in my mind as Nigel, whether or
not any of the deprefixed
... names had any similarity to the non-prefixed name. The
programName and programType
... seem to be likely, the others not.
... The ones that had cea prefixes need to be syntactically
compatible with SMPTE-TT.
... I can not simply remove the reference to 608 or 708 from
the definition of them without
... sacrificing syntactic specificity.
nigel: And there's an editorial task to add the source
definitions?
glenn: That's right.
... I'm pretty sure that programName is just a string and no
more restricted. The originalProgrammeTitle
... is probably the same semantic.
... We also need to check with Mike Dolan since he was involved
in defining these in
... SMPTE-TT. I think we should be able to merge programName
and originalProgramTitle
... probably. We have to choose which token to end up with - I
don't have a strong preference.
... My preference is to add a prefix back, but just make it cea
or cta (remove the 608 or 708)
... and we could add it for EBU also.
nigel: An observation here is that building the named items
into the TTML2 spec gives us a
... potential problem in that it makes it harder to update the
list later. A common pattern
... is to reference an external list or classification scheme
which can be updated independently.
... Since none of these named items normatively affects
processing this should be okay.
... This is a bit like the role registry approach in TTML1.
glenn: In TTML1 we had a requirement to prefer Dublin Core, and
after much debate we took
... a minimalist approach and hardly defined anything. Then
SMPTE-TT came along and defined
... a whole bunch of metadata items for 608 and 708 that were
thought to be important.
... Since one of the nominal driving factors for TTML2 is to
support all the extensions in
... SMPTE-TT we ended up adding these in.
andreas: I think the most practical solution is to reference a
document that we maintain that
... defines our unqualified namespace items and informatively
links to other sources of
... namespace qualified items in other organisations'
namespaces.
glenn: That sounds like a plan.
nigel: Same here.
glenn: I think we should leave in usesForced and
alternativeText
nigel: Even those we do not need to be in the specification
glenn: I think we want to refer to them elsewhere in the spec
so I'd like to keep those two
... unqualified names in the spec.
andreas: Ok, if they depend on these.
glenn: Others that we have not defined yet we can bind to a
namespace and offer a template
... for the future to define new named items.
... That would simplify this work quite a bit.
... I'll add a note to the issue with that plan.
... I didn't abbreviate alt text so I had it as alternateText -
what's the view?
pierre: Keep it as close as possible to IMSC 1.
nigel: yes, happy with altText.
glenn: ok
nigel: We have essentially covered Add alternateText named
metadata item (#107). [33]https://github.com/w3c/ttml2/pull/183
[33] https://github.com/w3c/ttml2/pull/183
IMSC 2
pierre: We are beginning to get industry feedback from IMSC 1
implementation.
nigel: There seem to be some preconceptions in the wild about
what IMSC 2 will be. I'd like
... us to collate requirements.
pierre: I would happily collate requirements for IMSC 2.
glenn: I think there will be a continuing requirement for
images to deal with internationalisation
... cases that not all clients will be able to support.
<scribe> ACTION: pal Refactor the IMSC repository in
preparation for future versions of IMSC. [recorded in
[34]http://www.w3.org/2016/09/19-tt-minutes.html#action02]
[34] http://www.w3.org/2016/09/19-tt-minutes.html#action02]
<trackbot> Created ACTION-479 - Refactor the imsc repository in
preparation for future versions of imsc. [on Pierre-Anthony
Lemieux - due 2016-09-26].
glenn: Having them in one repository helps with issue tracking
but you should use labels of
... some kind to distinguish between the different versions.
pal: At the root will be a roadmap document for all the
versions of IMSC.
... As soon as I get requirements for IMSC 2 I will start a
requirements document too.
nigel: It's not from BBC but Ruby seems obvious.
pierre: Yes I hear that a lot, also HDR and tate chu yuko.
Disparity is another one.
nigel: Also Wide Color Gamut?
pierre: Yes. Also background area between lines.
nigel: I would add the safe crop area stuff too.
andreas: As well as asking for requirements it would be good to
ask for the use case and the
... problem that needs to be solved, in some detail.
pierre: So yes, HDR, all east asian layout.
rohit: Any mention of the condition attribute?
pierre: No not yet. I've heard people wanting to do responsive
design, but I'm not sure we're there yet.
nigel: What about continuous animation?
pierre: Not yet.
nigel: Seems strange to me based on historical BBC research to
have disparity but not continuous animation.
andreas: We should check what east asian organisations need to
do.
dae: I'd like to know if there are any parts of TTML2 that folk
think might need to change. Ruby for example?
pierre: I'd like to be really specific about all the Ruby
features in a pedantic way.
glenn: All the TTML2 layout features were driven from existing
content in lambda cap. it is
... easy to say what was not driven from lambda cap.
... It is easy to enumerate all the different Ruby features -
look at TTML2 from
... §10.2.30 tts:ruby to §10.2.37 tts:rubyPreserve also
§10.2.40 tts:textCombine
... §10.2.41 tts:textEmphasis and §10.2.43 tts:textOrientation.
... All those were directly driven by lambda cap. There are a
couple that were not:
... rubyOverflow, rubyOverhand and rubyOverhangClass.
rohit: Also rubyReserve?
glenn: Yes. Overflow and overhang came out of the Japanese
requirements as well as how
... to handle some cases that were not obvious.
pierre: Thanks!
nigel: Do we have feature designators for these yet?
glenn: There's an editorial note in E.1 for adding those.
group: [discussion of structure of specification, areas of
TTML2 that may be relatively more 'risky', how to make progress
etc.]
dae: Can we revisit the initial construct in TTML2 tomorrow?
Agenda bash
group: plans ahead for tomorrow, updates agenda.
TTML2 implementation work
glenn: Skynav's TTT set of tools could be viewed as 1-3
implementations. It's a layered
... system - the validation layer at the bottom could be
considered a transformation implementation.
... TTX above that has one module that translates into an ISD
sequence. For example it can
... take IMSC1 or SMPTE-TT documents and turn them into TTML2
ISDs. Then the next
... layer is TTPE that implements formatting semantics.
rohit: At Netflix we are building a TTML2 oriented pipeline.
The idea is to take TTML2 source
... documents, convert them into a canonical form (probably
TTML2 ISD) and then use them
... to generate output formats including WebVTT and rendered
subtitles.
... Depending on the test vector set for TTML2 Netflix may be
able to meet 40-50% of the
... tests for implementation.
glenn: I'd also like to add: in terms of presentation semantics
implementation in TTPE for
... TTML2 features, the only new features it does not yet
support are the use of referenced
... external fonts, audio and disparity. Everything else that's
new in TTML2 it supports already
... from a presentation semantic. There might be some fine
points to some of the features
... that we are still tweaking. We have test content for all of
those features that we are using
... to generate presentable output in either images or SVG. So
we are way ahead on implementation
... of presentation and we have test content for most all of
it. Our schedule for finishing
... implementation work on TTML2 is scheduled to be finished
early March 2017.
thierry: The horizontal review groups request review
opportunity as soon as possible.
nigel: In fact I should trigger that process straight away.
... Wide review is even wider than that.
thierry: We should start to initiate that to make sure there is
enough time.
glenn: I'd like to have a version ready for a new WD by early
October.
thierry: Remember that we can limit the scope of review only to
the additional features in
... TTML2 that are new relative to TTML1.
pierre: Remember also for wide review you have to factor in
time to respond to comments.
... For the east Asian text layout there's an action to contact
ARIB specifically.
nigel: We will also need horizontal review. As a minimum I
should contact the horizontal review groups and request time on
their schedule for a new document early November.
<scribe> ACTION: nigel Request schedule time for horizontal
review of TTML2 [recorded in
[35]http://www.w3.org/2016/09/19-tt-minutes.html#action03]
[35] http://www.w3.org/2016/09/19-tt-minutes.html#action03]
<trackbot> Created ACTION-480 - Request schedule time for
horizontal review of ttml2 [on Nigel Megitt - due 2016-09-26].
glenn: Why don't I give you a list of new features to start
reviewing?
nigel: Good idea.
<scribe> ACTION: gadams Provide nigel with a list of new
features in TTML2 to begin reviewing [recorded in
[36]http://www.w3.org/2016/09/19-tt-minutes.html#action04]
[36] http://www.w3.org/2016/09/19-tt-minutes.html#action04]
<trackbot> Created ACTION-481 - Provide nigel with a list of
new features in ttml2 to begin reviewing [on Glenn Adams - due
2016-09-26].
glenn: How would it be if we have a solid working draft for
wide review by Nov 1?
nigel: Sounds good to me.
glenn: And how about moving to CR by the end of the year?
nigel: It's ambitious but we can try.
... Looking at the picture on
[37]https://www.w3.org/wiki/TimedText/Publications it shows
... a FPWD of IMSC 2 back in June, but I think from today we
have decided to collate
... industry requirements and then maybe base it on the TTML2
CR perhaps?
[37] https://www.w3.org/wiki/TimedText/Publications
pierre: We should aim to make IMSC 2 based solely on industry
requirements but we can
... certainly set a new date - I'm comfortable with that,
partly as a challenge to folk who
... want IMSC 2 - we need to get going on it.
nigel: Agreed. Shall we say IMSC 2 FPWD by Dec 1?
pierre: Sounds great to me, maybe even earlier.
nigel: Ok let's leave it at that for now and if we can make it
earlier, great.
dae: Can an implementation satisfy both TTML2 and IMSC 2?
nigel: Yes.
... Ok we're out of time for today, thanks all. Time to adjourn
for tomorrow.
andreas: Can we make sure we cover IMSC 1 implementation work
tomorrow?
nigel: yes let's do that.
... [adjourns meeting]
Summary of Action Items
[NEW] ACTION: gadams Provide nigel with a list of new features
in TTML2 to begin reviewing [recorded in
[38]http://www.w3.org/2016/09/19-tt-minutes.html#action04]
[NEW] ACTION: nigel Draft a liaison to HbbTV requesting further
information and proposing an option e.g. to extend IMSC 1 to
allow signalling of background height on span, and request
timelines etc. [recorded in
[39]http://www.w3.org/2016/09/19-tt-minutes.html#action01]
[NEW] ACTION: nigel Request schedule time for horizontal review
of TTML2 [recorded in
[40]http://www.w3.org/2016/09/19-tt-minutes.html#action03]
[NEW] ACTION: pal Refactor the IMSC repository in preparation
for future versions of IMSC. [recorded in
[41]http://www.w3.org/2016/09/19-tt-minutes.html#action02]
[38] http://www.w3.org/2016/09/19-tt-minutes.html#action04
[39] http://www.w3.org/2016/09/19-tt-minutes.html#action01
[40] http://www.w3.org/2016/09/19-tt-minutes.html#action03
[41] http://www.w3.org/2016/09/19-tt-minutes.html#action02
Summary of Resolutions
1. [42]If we do not move WebVTT to CR in this Charter period
then we will not include it in any new Charter.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [43]scribe.perl version
1.144 ([44]CVS log)
$Date: 2016/09/19 17:25:20 $
[43] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[44] http://dev.w3.org/cvsweb/2002/scribe/
--
Nigel Megitt
Executive Product Manager, BBC Design & Engineering
Telephone : +44 (0)3030807996
BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP
Received on Monday, 19 September 2016 17:32:49 UTC