IRC log of tt on 2016-09-19

Timestamps are in UTC.

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