15:00:27 RRSAgent has joined #tt 15:00:27 logging to https://www.w3.org/2019/05/09-tt-irc 15:00:29 RRSAgent, make logs public 15:00:29 Zakim has joined #tt 15:00:31 Meeting: Timed Text Working Group Teleconference 15:00:31 Date: 09 May 2019 15:00:46 Agenda: https://github.com/w3c/ttwg/issues/37 15:00:53 Present: Andreas, Cyril 15:00:59 scribe: Cyril 15:01:01 chair: Nigel 15:01:21 nigel has joined #tt 15:01:29 Topic: This meeting 15:01:41 Regrets: Ggary 15:01:47 s/Ggary/Gary/ 15:01:57 Present+ Pierre 15:02:52 nigel has changed the topic to: TTWG meeting Thursday 1500 UTC. Agenda for 2019-05-09 will be at: https://github.com/w3c/ttwg/issues/37 15:03:24 atai2 has joined #tt 15:03:41 Regrets+ Philippe, Thierry, Glenn 15:04:49 nigel: we should probably skip the WebVTT topic 15:05:04 ... the other 2 topics we can discuss, even without Glenn 15:05:08 ... live contribution 15:05:32 ... and 3 PR or issues on TTML2 15:06:25 Topic: TTML Live Contribution 15:06:36 nigel: contribution in from EBU 15:06:47 ... 2 specifications of EBU-TT 15:06:58 ... extending the EBU-TT profiles of TTML1 15:07:06 ... and to specify web socket 15:07:17 ... my proposal is to rebase those on TTML 15:07:41 ... there is nothing specific about EBU-TT that is required to make this live extensions work 15:07:49 ... it does not use SMPTE time base 15:08:01 ... it is applicable to TTML1 or TTML2 15:08:09 ... EBU-TT is based on TTML1 15:08:31 ... and I don't think there is feature of TTML2 that are problematic 15:08:51 ... so the question is to which spec to rebase to 15:09:06 pal: do you need a normative reference to TTML? 15:09:20 ... does TTML2 say that it's a superset of TTML1? 15:09:23 nigel: mostly 15:09:34 ... yes 15:10:17 pal: you could always say both TTML1 and TTML2 15:10:45 ... or say conform to TTML1 and because TTML1 is a subset of TTML2, you could add it as a note 15:11:16 nigel: if we base it off TTML2, and because a TTML1 document is conforming to TTML2, that would work too (maybe with a note) 15:11:33 pal: yes, that works too 15:11:54 ... if you don't reference both, put a note to the TTML2 section about backwards compatibility 15:12:32 nigel: the scope of it is either live authoring or streaming of prepared subtitles and captions 15:12:43 ... the source is an author or system 15:12:52 ... the intent is not to define a distribution format 15:13:03 ... the target is an encoder 15:13:18 ... you can use CMAF for example as target format 15:13:38 ... the approach is that you send several documents 15:13:47 ... each one of which covers a period of time 15:14:19 ... a subsequent document can override a previous document 15:14:31 cyril: how do you know if it's too late? 15:15:03 nigel: if a particular interval of time is changed after the encoder has already created output for that period of time 15:15:05 ... it's too late 15:15:19 ... but if it's before, it can take it into account 15:15:41 ... obviously, the real world periods of time depend on deployment and delays 15:16:26 cyril: is it simply saying you can send TTML documents on web sockets? 15:16:33 ... or does it talk about ISD? 15:16:42 nigel: it doesn't mention ISDs 15:17:01 ... because TTML1 did not define ISD precisely 15:17:19 ... the format is agnostic of the transfer (websocket, tcp socket ...) 15:17:43 cyril: what is the normative part? 15:17:57 nigel: the normative part is resolving temporal overlap 15:18:16 ... rules on defining effective begin and end time of documents in the context of sequence 15:18:48 ... the contributions have lots of explanatory text and examples 15:19:01 ... what should be the structure of this? 15:19:12 ... have a small document with normative requirements, small 15:19:30 ... and a separate informative document that talks about real world deployments and examples, as a WG note 15:19:44 ... or to reproduce all the content in a new single specification 15:20:02 ... I would always make carriage over web socket a separate document 15:20:24 cyril: I would prefer having the smallest normative document 15:20:34 q+ 15:20:43 pal: the ratio of informative/normative is too high 15:20:54 ... it introduces one new attribute? 15:21:02 nigel: 2 parameter attributes 15:21:08 pal: processing requirements 15:21:14 ... 2 pages should be normative 15:21:26 ... the rest is use cases, requirements .... that should be moved somewhere else 15:21:35 ack at 15:21:38 atai2: I would also support this approach 15:22:04 ... I would go even further and just have the edit vocabulary with short descriptions 15:22:16 ... and the system model/processing in a different document 15:22:45 ... the least amount of text would be helpful to get the basic idea and how to implement it 15:22:57 nigel: we have an agreement 15:23:06 ... I will try to create a small as possible normative document 15:23:14 ... and have additional explanatory documents 15:23:22 ... to be published as WG notes 15:24:02 nigel: we thank EBU for providing these contributions 15:24:32 cyril: is there any reference to the HRD? 15:24:38 nigel: no there is no reference to it 15:24:52 ... it's unlikely to be a real world problem 15:25:04 ... you could of course stress a system 15:25:27 ... but only in that case you could exceed it but not in real world content 15:25:34 s/HRD/HRM/ 15:25:57 ... also HRM is a feature of IMSC not of TTML 15:26:53 topic: TTML2 and TTML3 Pull Requests 15:27:07 nigel: can we deal with any of them? 15:27:22 ... relative profile designator, we need Glenn 15:27:31 ... the topic on ruby needs Glenn too 15:27:51 ... can we talk about region timing? 15:27:53 cyril: yes 15:28:03 Topic: Missing test for #region-timing #1073 15:28:11 github: https://github.com/w3c/ttml2/issues/1073 15:28:24 i/Topic/scribe: nigel 15:29:11 Nigel: region timing is pretty complex, and there are no tests, right? 15:29:18 Cyril: I checked and couldn't find them, and neither could Pierre 15:29:21 Pierre: Nope, I couldn't 15:29:49 Nigel: Given the complexity of this I think it's something we should work on, or even deprecate the feature. 15:29:54 Cyril: It's used for IMSC Image Profile? 15:30:00 Pierre: That's the only place I've ever seen it used. 15:30:11 Cyril: How is it used? 15:30:26 Pierre: A div is selected in a region and the div has the smpte:backgroundImage, and there's a 1:1 mapping 15:30:31 .. between each div and each region. 15:30:38 Cyril: Why is the timing on the region and not on the div? 15:30:50 Pierre: I literally don't know. I remember seeing it once done that way. 15:30:53 Cyril: It's not a pattern? 15:31:02 Pierre: I don't think so. [checks out the Fox content] 15:31:32 pal has joined #tt 15:31:35 .. In their example the timing is on div. 15:31:46 .. I remember seeing this used once but I don't think it's a pattern. 15:31:57 Cyril: That one has div timing 15:31:59 Pierre: Right 15:32:27 Nigel: There are subtleties here: 15:32:56 .. For example, the ISD synthesis rehomes body to a region parent, but the body timings are not (I think) 15:33:05 .. relative to the region's timings. Is that right? 15:33:30 .. Therefore there's a potential intersection between the active intervals of a region and content selected into it. 15:33:48 .. So what happens to content selected into a region outside its active interval? 15:34:00 .. Does it get temporally clipped? Or does the region's active interval get extended? 15:34:47 .. Pierre, you must have implemented this, but I can easily imagine other implementers might get it wrong one way or another. 15:34:56 Pierre: [looks at the imsc.js implementation] 15:35:22 .. It's pretty clear that my conclusion at the time was that regardless of how timing was set on a region, if it was not 15:35:28 .. active then nothing else can be active at that time. 15:35:42 Nigel: So the region timing temporally clips its content? 15:35:51 Pierre: Yes. I think there was a thread on this, I'd have to go back. 15:36:13 .. This makes sense in the context of showBackground="whenActive". That's one way to have a region where 15:36:25 .. the black background is only shown when the region is active, and making that explicit. 15:36:30 Nigel: That does make some sense, yes. 15:36:52 Pierre: One way to set when a region is active explicitly, especially in the US caption style, is to have a begin and end 15:36:55 .. on a region. 15:37:17 Nigel: You'd think that, however the normative text on showBackground refers to content being selected into it. 15:37:35 .. So arguably even if a region is active, if no content is flowed into it then showBackground doesn't happen. 15:38:03 Pierre: The way imsc.js does it is it resolves timing completely separately for regions and body. It applies the timing 15:38:17 .. resolution algorithm separately to region and to body. So it's the intersection model. 15:38:35 Nigel: That's easily testable, right? 15:38:51 Pierre: Right. I was stunned not to find a test in the imsc tests, because I thought there was one, but maybe no test 15:39:05 .. ever made it to the test suite. I searched and couldn't find any region with a begin on it. 15:39:11 .. I really like the idea of adding tests. 15:39:46 Cyril: The related question is what to do on IMSC. I opened an issue to deprecate this feature in IMSC, w3c/imsc#473. 15:40:01 Pierre: In the grand scheme of things it's not a big deal if the intersection model is used, it's pretty easy to explain 15:40:12 .. and straightforward. And it's implemented in imsc.js. 15:40:27 .. One thing to think about is there are tons of other things that nobody should use, like nested timing. 15:40:44 .. Maybe one thing to consider is to at some point in the IMSC lifecycle do a pass on everything that we think people should not do 15:40:57 .. because there's no use for it and deprecate all of them. It would be weird to deprecate just that one. 15:41:11 Cyril: If you find other features to deprecate then fine, but we should give a signal and not let it linger. 15:41:21 Pierre: Why does it shock you, aside from the lack of tests? 15:41:31 Cyril: We don't implement it and don't see the value. 15:42:11 Pierre: That's true of other things, right, like seq timeContainer, nested region reference (e.g. nested divs with different region references)? 15:42:34 .. I've not found any reason why anyone would do the latter, which has serious consequences. 15:42:38 .. I have my own personal list! 15:42:51 Cyril: We should go through that list. If people don't implement it, then let's be clear about it. 15:43:06 Pierre: My suggestion is if we want to start deprecating things that are not broken but we think are not useful and 15:43:17 .. potentially confusing we should look at that. It's late in this cycle. 15:43:30 Cyril: If it has never been tested you can't say it's not broken, right? 15:43:42 Pierre: I don't think that argument really works. We can agree it's not great to use. 15:43:56 Cyril: If you cannot rely on it because implementations don't agree, then either it's broken or deprecate it. 15:44:12 Pierre: TTPE and imsc.js might actually work but that's not the right threshold. 15:44:22 .. Just because they implement it doesn't mean it shouldn't be deprecated. 15:44:31 Cyril: No, but if they don't agree then we should consider deprecating it. 15:44:47 Pierre: My point is there are a lot of features that go into whether or not to deprecate something. 15:44:55 Cyril: Exactly. 15:45:05 Nigel: The first stage is to create a test to see if the implementations agree or not. 15:45:07 Cyril: Yes 15:45:11 Pierre: I think that's a great idea. 15:45:29 .. I'm supportive of generating a list of features to deprecate from IMSC but we might be late in this process to do that. 15:45:50 Nigel: At least surfacing that list would be helpful even if we don't implement the deprecations until later. 15:45:53 Pierre: Totally agree. 15:46:19 Nigel: Does anyone want to create the tests? 15:46:35 Pierre: We can split the burden. Cyril, if you want to create the tests then I can add them to imsc-tests. 15:46:51 .. I recommend you create a pull request against imsc-tests and then I'll test them with imsc.js. 15:47:14 Cyril: Hmm, creating the tests when I don't support the feature! 15:47:32 Pierre: The primary ingredient for deprecation is that nobody wants it. 15:47:45 .. I'm not going to come back and say because you created the test you want the feature! 15:47:50 Cyril: Yeah, I'll create the test. 15:48:04 Pierre: By the way you might prove it's broken, in which case we can deprecate it urgently. 15:48:57 SUMMARY: @cconcolato to create a pull request on imsc-tests adding a region timing test, @palemieux to run the test through imsc.js 15:49:25 Topic: Character-related style properties should not apply to ruby containers. w3c/ttml2#1043 15:49:36 github: https://github.com/w3c/ttml2/issues/1043 15:49:52 Pierre: Although Glenn is not here, I'm interested in the perspective of other members. 15:51:08 Nigel: I've been quiet up to now because I can see both sides and don't have a strong view. 15:51:25 Pierre: This isn't about the white space handling - we have agreement on that. 15:52:55 Nigel: Right, I think we should be super clear about which style attributes should generate no marks on the boxes 15:53:12 .. generated by spans where ruby is container, textContainer or baseContainer. 15:53:31 .. I would do it like in your pull request Pierre, or by refactoring the definition into a single place and creating a special 15:53:36 .. term for those kind of span. 15:53:49 Cyril: I like Glenn's pull request and Nigel's proposal too. 15:54:13 Pierre: This is a real point of confusion because of the way Firefox handles it. TTML should be clear. 15:54:30 .. I'm happy to repeat the text or use a definition. I actually started with a definition but didn't want another one but 15:54:45 .. I'm really happy to recast the pull request with a definition, of a new kind of span, and use that. 15:54:56 Pierre: Thanks for sharing your feedback. 15:55:14 .. I'll update my pull request by putting in Glenn's text about linear whitespace etc. 15:56:52 Nigel: Glenn has already made it clear he doesn't think the existing spec is for any marks to be made, 15:57:17 .. but I haven't seen anything traceable there. Did you say your test only shows that in Firefox? What about Chrome or webkit? 15:57:28 Pierre: They're so broken with ruby that I don't trust them. 15:57:47 .. Glenn's argument is that text decoration only applies to terminal glyphs, but that's not always the case. 15:57:57 .. I will update my pull request based on your feedback. 15:58:09 .. Thanks. 15:59:35 Topic: Meeting close 15:59:44 Nigel: Advanced info, I won't be able to attend on May 30th. 15:59:51 Pierre: Regrets for me for next week. 16:00:28 Nigel: Thanks everyone [adjourns meeting] 16:01:11 rrsagent, make minutes 16:01:11 I have made the request to generate https://www.w3.org/2019/05/09-tt-minutes.html nigel 16:02:17 atai2 has left #tt 16:19:42 s/we should probably skip the WebVTT topic/Looking at the agenda, and given Gary's regrets, we should probably skip the WebVTT topic 16:21:07 s/a subsequent document can override a previous document/a subsequent document can temporally override a previous document, either completely or partially 16:21:46 s/because TTML1 did not define ISD precisely/because TTML1 did not define an ISD syntax 16:22:44 s/we thank EBU for providing these contributions/We thank EBU for providing these contributions. 16:26:23 rrsagent, make minutes 16:26:23 I have made the request to generate https://www.w3.org/2019/05/09-tt-minutes.html nigel 16:27:00 Log: https://www.w3.org/2019/05/09-tt-irc 16:27:01 rrsagent, make minutes 16:27:01 I have made the request to generate https://www.w3.org/2019/05/09-tt-minutes.html nigel 16:27:43 scribeOptions: -final -noEmbedDiagnostics 16:27:44 rrsagent, make minutes 16:27:44 I have made the request to generate https://www.w3.org/2019/05/09-tt-minutes.html nigel 17:15:24 dbaron has joined #tt 17:15:32 github-bot, end topic 17:15:37 dbaron has left #tt 17:24:48 github-bot has joined #tt 17:40:02 Zakim has left #tt