14:04:31 RRSAgent has joined #tt 14:04:31 logging to http://www.w3.org/2017/06/01-tt-irc 14:04:33 RRSAgent, make logs public 14:04:33 Zakim has joined #tt 14:04:35 Zakim, this will be TTML 14:04:35 ok, trackbot 14:04:36 Meeting: Timed Text Working Group Teleconference 14:04:36 Date: 01 June 2017 14:05:07 scribe: nigel 14:06:31 Present: Glenn, Andreas, Mike 14:06:36 Regrets: Dae, Pierre 14:07:07 Present+ Thierry 14:07:12 Chair: Nigel 14:08:04 Topic: This Meeting 14:08:55 Nigel: For today, we have TTML stuff - issues, progress, TTML1 vs 2 compatibility, a little 14:09:47 .. on IMSC that's in the agenda (even in Pierre's absence). Any thing specific to raise or AOB? 14:10:10 group: [silence] 14:10:15 Nigel: Okay then let's do it! 14:10:41 atai has joined #tt 14:11:12 Topic: TTML issue assignment and progress tracking 14:11:37 Nigel: I just want to recognise the huge amount of work that Glenn has done on TTML2 14:11:44 .. over the last month. 14:13:16 Glenn: I won't be able to make the telcos in June but will be able to work offline by 14:13:20 .. email. 14:13:31 Nigel: So there's no point in proposing to move the meetings? 14:13:37 Glenn: No, I still wouldn't be able to attend. 14:13:53 Glenn: In terms of progress I have only 1 issue remaining for which there is no PR. 14:14:14 .. The priority will be to wrap up the PRs and get to a version for WR. There may be 14:14:25 .. some other issues that I will address too, some of them recent, like not deprecating 14:14:40 .. ttp:profile. I don't know if I will be able to address the 24 or so issues raised by 14:14:54 .. Richard Ishida, but if there are simple ones I will try to do that. 14:15:08 .. For issue 195 on audio description I posted a preliminary PR which is not complete. 14:15:29 .. I see there are comments on that from you Nigel which I will look at, so that's also 14:15:42 .. on my list for June. I want to get all that work done by 23rd June which will give a 14:15:54 .. week to prepare a final version of the WR and deal with any publishing issues. 14:17:16 Nigel: Our goal is to publish WR by end of June. Can we have a completed draft by 14:17:43 .. 15th June for review to give 2 weeks review to verify that we have consensus? 14:18:14 .. Any commits after then, unless they are addressing review comments, might not make it in. 14:18:22 Glenn: Ok I'll see how far I can get by the 15th. 14:22:30 Glenn: I'd like to talk today about the proposal for dealing with line gap, and the other 14:22:38 .. is the lingering issues about em square and font size semantics. 14:22:50 Nigel: Ok, what about mediaOffset? 14:23:08 Glenn: The last issue I have, #96 on root temporal extent, encompasses that so I'm 14:23:18 .. not yet ready to review that today - I'm still working on it. 14:23:33 Nigel: Ok 14:23:45 Glenn: That's a case where maybe we need a special call with interested parties to 14:23:51 .. drill down into the details of that one. 14:24:54 Nigel: Sounds like a good idea. 14:24:59 .. Status right now on TTML2: 14:25:04 .. 44 open issues. 14:25:25 .. 7 issues for group review or awaiting HR comment on disposition 14:25:37 .. 28 open issues with no milestone 14:26:04 .. (19 are horizontal review comments) 14:26:40 .. 9 open on the Editor's WR work list. 14:27:21 .. Glenn is there anything specific where it would be useful for input from others, e.g. 14:27:28 .. editorial notes, examples? 14:27:36 Glenn: Not right now, #150 is the only one on here. 14:27:53 .. I'd like to talk about today. 14:28:21 Nigel: Before we dive into the issues, are there any other changes anyone has begun 14:28:24 .. to work on? 14:28:29 group: [silence] 14:29:02 Topic: TTML1 & TTML2 issues, actions, PRs, editorial actions etc 14:29:25 -> https://github.com/w3c/ttml2/issues/331 Revert deprecation of ttp:profile on root element. #331 14:29:36 Glenn: I posted a pull request on this last night that reverts the deprecation. 14:31:26 Nigel: There are two things to discuss here - the TTML1 vs TTML2 goal and the 14:33:18 .. behaviour for ttp:profile if ttp:processorProfiles is also present. 14:33:31 Mike: I want a statement at the beginning of the document that states that all TTML1 14:33:50 .. document instances shall be valid TTML2 documents. The handling of deprecations 14:33:58 .. is delegated to the places where those deprecations are defined. 14:34:10 Glenn: I don't see a problem with stating that as an informative note. 14:34:17 Mike: That's what I have in mind. 14:34:30 Glenn: If you say "should validate" that's complex, maybe "should remain conformant" 14:34:43 .. would be better. Validation may create warnings as well as errors. So a TTML2 based 14:34:55 .. validation processor may emit warnings when processing a TTML1 document that 14:35:07 .. uses something that's deprecated. 14:35:17 Mike: I had it right on the email - the important thing is to state informatively this 14:35:29 .. goal at the beginning of the document, which should guide us on not obsoleting 14:35:46 .. anything. I was concerned because I needed to check the meaning of "deprecate". 14:36:01 .. I think we should use "conformant" language rather than "deprecate". 14:36:21 Glenn: Another interesting thing is the scenario of processing a TTML1 document 14:36:45 .. under TTML2 rules rather than TTML1 rules. This could be done by a configuration 14:36:51 .. parameter. 14:37:03 Mike: That would be good to mention - we're not changing the namespace are we? 14:37:10 Glenn: No we're not changing that. 14:37:21 Mike: It would be helpful to discriminate old from new documents. 14:37:34 Glenn: For example I could take a TTML1 document and add a v2 attribute to it. It is 14:37:52 .. no longer strictly a TTML1 document because it has a version attribute. Now I feed 14:38:20 .. that to a TTML2 processor 14:38:36 Nigel: So your point is that the processing of a TTML1 document under TTML2 14:38:48 .. rules might generate different output from the same document processed under 14:38:53 .. TTML1 rules? 14:39:00 Glenn: I just wanted to point out there are subtleties. 14:40:30 Andreas: I have a question about handling of TTML1 documents by a presentation 14:40:41 .. processor. Is the presented result identical from a TTML2 processor as from a TTML1 14:40:49 .. processor? Is that also guaranteed? 14:40:58 Glenn: I doubt if you get that with TTML1 processors. 14:41:06 Andreas: But I mean the intent. 14:41:21 Glenn: It's not true in general because you cannot guarantee what fonts are used, and 14:41:29 .. the line breaking algorithm is not specified. 14:41:44 Andreas: My question is: is there any difference in TTML2 that would result in a 14:42:04 .. different rendering from a TTML 1 processor, having taken out the non-deterministic parts. 14:42:20 Glenn: If the implementations have the same fonts, the same rasterisation processing 14:42:35 .. and font implementation, and we assume that we are not considering implementatoin 14:42:58 .. dependent differences. If you throw out all those variables then it probably should 14:43:11 .. be close but I don't know if it would be exact even in theory. I don't think anything 14:43:23 .. in TTML1 right now says the output of a presentation engine has to be identical. 14:43:31 .. We don't have a testing regime to verify that. 14:45:46 Nigel: I'd flip this round and look for counter-examples. One of those is the handling 14:45:59 .. of tts:origin and tts:extent on div and p elements. Presentation behaviour is not 14:46:12 .. defined in TTML1 for that but it is in TTML2 so the two processing engines should 14:46:23 .. generate different output given a document that uses that syntax. 14:46:42 Andreas: I think that example is interesting. I think if we add such a statement, we 14:46:59 .. should add that all TTML1 documents should be processed okay by a TTML2 14:47:18 .. processor, and that changes in TTML2 do not lead to different results than a TTML1 14:47:33 .. processor. That is if we can be sure. Otherwise we should just state that document 14:47:43 .. conformance is given for TTML1 documents as being valid TTML2 documents. 14:48:08 Glenn: In TTML1 we define 3 standard profiles - full, presentation and transformation. 14:48:23 .. We tied those to v1 and in v2 that we are defining now we have created new 14:48:37 .. profiles with the same names but slightly altered. Now instead of dfxp-full etc we 14:48:50 .. have ttml2-full, ttml2-presentation and ttml2-transformation, so we have two sets 14:49:02 .. of built-in profiles, one that applies to TTML1 and the other to TTML2. We are also 14:49:20 .. extending the set of feature designators in TTML2. So a TTML2 processor can 14:49:36 .. choose only to treat documents as TTML2 or to process TTML1 documents as 14:49:58 .. faithfully to TTML1 as I can, except if ttp:version="2" which may lead to slightly 14:50:02 .. different presentation potentially. 14:50:49 Nigel: In summary, we should not state that a TTML2 processor will generate the same 14:51:09 .. output as a TTML1 processor for the same conformant TTML1 document, since we 14:51:17 .. do not know in general that it is the case. 14:51:26 Glenn: I think we should put this note in the Conformance section. 14:51:34 Mike: Shall I file an issue? 14:51:48 Nigel: Yes please do it so we can track it. 14:52:36 Mike: On this issue, can I refer to it? 14:52:55 Glenn: We need to make sure that we deal with the "used value" of ttp:version. 14:54:28 Nigel: Are you happy for #331 to bring back the wording about precedence in case 14:54:38 .. ttp:profile and ttp:processorProfiles are present? 14:54:52 Glenn: I thought there was some procedural wording there, I'll verify and if not then 14:54:56 .. yes I'll put that wording back. 14:55:08 Mike: I think we should not permit both to be present in the same document instance. 14:55:19 Glenn: We do not prohibit content inside the TTML document. 14:55:25 .. You may do that in a profile. 14:55:35 Mike: Why allow both in the same document? 14:55:47 Glenn: You should not but we cannot enforce author behaviour so we define what 14:56:01 .. the processor does. It is clearly not violating a syntactic rule and we do not want to 14:56:14 .. insist on a schema based rule to enforce it so we have semantic language that says 14:56:19 .. you should not do both. 14:56:39 Mike: I think that's weird but I understand that's the common practice so I'll back off. 14:56:52 Glenn: This is the case for origin and position too, for example. 14:57:25 Nigel: I agree even if the authoring practice is not good we should have a defined 14:57:32 .. behaviour rather than an undefined one. 14:57:38 Mike: Ok! 14:58:05 Glenn: I agree we need language to say you shouldn't do both and what to do if they 14:58:16 .. are both present so I'll make sure that's there. 14:58:20 Mike: Thank you. 14:59:27 Glenn: I can handle the addition of a conformance note to #331. 14:59:46 Mike: I'll raise an issue about the obsoleted feature. 15:02:20 rrsagent, make minutes 15:02:20 I have made the request to generate http://www.w3.org/2017/06/01-tt-minutes.html nigel 15:07:29 Topic: Line Gap 15:08:17 -> https://github.com/w3c/ttml2/issues/150 Ways to make span background height be lineHeight #150 15:08:52 Nigel: Glenn you requested here and on IMSC to make this a parameter attribute 15:08:56 .. rather than a style attribute. 15:09:16 q+ 15:09:36 Nigel: We did discuss this for IMSC and concluded that it should be a style attribute. 15:09:40 ack atai 15:09:51 Andreas: I tried to find this in the minutes from the London minutes, but as far as I 15:10:09 .. recall we had this discussion and even then Glenn wanted just one attribute for the 15:10:30 .. whole document; others had the strong view that it should be a style attribute. 15:10:40 .. I cannot remember exactly the use case. I think we definitely discussed the solution 15:10:47 .. and agreed to have it as a style attribute. 15:10:50 Nigel: +1 15:11:01 Glenn: I agree that's what we discussed. 15:11:10 .. I'm not convinced at all that a single document instance would use more than one 15:11:32 .. value at any point. I expect that documents would declare a style attribute as a top 15:11:44 .. level inherited value or an initial value so they will have the same value everywhere. 15:11:59 .. If we started out with a parameter version we could add a style version later for 15:12:03 .. more refinement. 15:12:14 s/parameter/profile 15:12:24 .. I think we don't have a requirement for it and it makes implementations and testing 15:12:26 .. more complicated. 15:13:58 Nigel: Glenn you asked me for an example - I added one to the pull request 15:14:10 -> https://github.com/w3c/ttml2/pull/346Issue 0150 inline background height #346 15:17:04 Nigel: This is based on the HbbTV 2.0.1 heuristic that does allow for documents to 15:17:22 .. vary the line gap filling behaviour, so a single ttp: namespace attribute would not 15:17:26 .. allow this example to work. 15:17:39 Andreas: We discussed this and decided the other way around. I think we should take 15:17:59 .. it for granted that there is a requirement to apply it as a style to a paragraph, so it 15:18:07 .. is not sufficient to have a document wide setting. 15:18:10 Nigel: +1 15:20:11 -> https://github.com/w3c/imsc/issues/238 Change itts:fillLineGap to ittp:fillLineGap. #238 15:22:56 Glenn: Since it is a style attribute in IMSC 1.0.1 I will close the issue and go back to 15:23:10 .. a style attribute - I don't particularly like it! 15:23:27 s|346Issue|346 Issue 15:24:07 Glenn: Are you happy if I make the change to #346 that I can merge it. 15:24:16 Nigel: Please could you make the change and then allow us time to double check it? 15:24:31 Glenn: Ok. By the way the reason I ended up going this way is because earlier on I had 15:24:46 .. proposed special values in bpd, but the more I tried that the more conflicts I uncovered 15:24:59 .. so doing something special is warranted. bpd and ipd do not apply to inline areas 15:25:17 .. that are not inline blocks so coming up with special language was too strange and 15:25:24 .. complicated to manage. 15:26:38 Topic: #200 Two value percentage font sizes 15:26:44 -> https://github.com/w3c/ttml2/issues/200 Two value percentage fontSize not fully defined #200 15:28:01 Nigel: I'm concerned that we are removing the semantic that allows the author to 15:28:15 .. define only the font height and have the processor present the glyphs without 15:28:27 .. any anamorphic scaling, possibly with knowledge of the display aspect ratio. 15:28:55 Glenn: It is already the case that font size has a defined width and height for the em 15:29:53 .. square. Logical pixels do not have any aspect ratio and we are talking about logical 15:38:27 .. pixel space here. When we scale the em square to a logical width and height... 15:38:56 [discussion of issue - scribe thinking not typing!] 15:40:38 Nigel: Presents starting condition of no tts:extent on root, use of %age dimensions, 15:41:27 .. implementation chooses what SAR, DAR etc to calculate. 15:41:39 Glenn: [walks through this] 15:42:30 .. e.g. for a 4:3 display the implementation would choose a SAR of e.g. 640x480. 15:42:42 .. That's up to the implementation to decide. Now we have SAR=DAR and PAR=1. 15:43:10 .. In this case all logical pixels map to square display pixels so if you specify a fontSize 15:43:37 .. of say "10%" on the region then you get logical pixels 64 high and 64 wide. Since 15:43:49 .. here we are mapping those to square display pixels you end up with a square em 15:45:23 .. square. 15:46:07 Nigel: Okay I think you might have persuaded me - if you switched to a 16:9 display 15:46:17 .. you would get more horizontal pixels and they would still be square. 15:47:20 .. By the way the issue originally arose because, although in the case we just went 15:47:34 .. through, the SAR is known, in a transformation processor it can not always be 15:48:58 .. known. There is one trick we could play which is to consider the horizontal width 15:49:12 .. as an equivalent rh value (i.e. width is a proportion of the height). 15:49:47 Glenn: That's in the PR. 15:49:53 Nigel: That's PR #336, which is merged. 15:52:45 Glenn: There's a note example under fontSize. 15:52:57 Nigel: Is it clear which pixels we mean, now that we define two kinds in Annex H. 15:53:24 Glenn: I have a note to myself to explain that we mean logical pixels. I think there may 15:53:41 .. be one place that you [Nigel] pointed out recently where we say display pixels but 15:53:46 .. we mean logical pixels. 15:54:01 .. Presentation Context Coordinate Space - under tts:position there's an image about 15:54:14 .. percentage based positioning and a couple of paragraphs down it mentions it. 15:54:22 .. So I need to review that and make sure that is is correct. 15:56:17 Glenn: I've noted for myself that all layout is done in logical pixels. 15:56:23 Nigel: I think that's worth clarifying. 15:58:26 q+ 15:59:51 ack atai 16:02:08 atai has left #tt 16:02:14 Topic: Meeting close 16:02:32 Nigel: We're out of time, thank you everyone. For those who are going to be present, 16:03:05 .. see you next week. Final word: please do review TTML2 now and raise any issues 16:03:18 .. sooner rather than later - anyone raising a bunch of issues on June 28 is just going 16:03:29 .. to create upset! [adjourns meeting] 16:03:36 rrsagent, make minutes 16:03:36 I have made the request to generate http://www.w3.org/2017/06/01-tt-minutes.html nigel 16:09:04 s/issue 195/#195 16:09:29 s/15th June for review/15th June 16:10:48 s/because I needed to check/until I checked 16:11:30 s/non-deterministic parts./non-deterministic parts? 16:12:34 s/faithfully to TTML1 as I can/faithfully to TTML1 as it can 16:14:46 s/Presents starting condition/[Presents starting condition 16:14:55 s/DAR etc to calculate./DAR etc to calculate.] 16:15:56 rrsagent, make minutes 16:15:56 I have made the request to generate http://www.w3.org/2017/06/01-tt-minutes.html nigel 16:18:28 ScribeOptions: -final -noEmbedDiagnostics 16:18:29 rrsagent, make minutes 16:18:29 I have made the request to generate http://www.w3.org/2017/06/01-tt-minutes.html nigel