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