13:58:52 RRSAgent has joined #tt 13:58:52 logging to http://www.w3.org/2016/03/24-tt-irc 13:58:54 RRSAgent, make logs public 13:58:54 Zakim has joined #tt 13:58:56 Zakim, this will be TTML 13:58:56 I do not see a conference matching that name scheduled within the next hour, trackbot 13:58:57 Meeting: Timed Text Working Group Teleconference 13:58:58 Date: 24 March 2016 14:01:14 Present: Andreas, Harold, Nigel 14:01:40 Chair: nigel 14:01:44 scribe: Nigel 14:01:47 s/ni/Ni 14:03:03 tmichel has joined #tt 14:04:20 Present+ Glenn, Pierre 14:05:08 Present+ Thierry 14:05:56 Topic: This Meeting 14:06:14 nigel: Andreas and others have requested we spend time looking at the line area background issue. 14:06:27 ... AOB? 14:07:12 group: No AOB 14:07:40 Topic: Action Items 14:07:51 No updates from me 14:08:51 glenn: Regarding a TTML2 WD, the problem is we use an XSL Transform to convert XML to HTML, and the HTML 14:09:13 ... Table of Contents structure is not compatible with the new ToC sidebar pane. It produces a terrible looking 14:09:44 ... result (worse actually). I've started to rewrite that and got bogged down. It's going to require 2-3 days for me 14:10:04 ... to make it work, which I'm hoping to get to by the end of the month. 14:12:33 Topic: Charter 14:12:56 nigel: Thierry, any idea what the status is with the Charter review? 14:13:14 tmichel: No, I did ping plh but have no update right now - neither good nor bad news. 14:13:47 nigel: Were Charters on the agenda for the AC meeting? 14:13:57 tmichel: No, they weren't discussed at the AC meeting. 14:14:58 Topic: IMSC 14:15:21 pal: I spoke to Coralie at the AC meeting, and she and Karen are looking for information, quotes, use cases etc 14:15:35 ... so I have that on my todo list and if anyone else wants to help then please do. 14:16:18 pal: Later on I think we'll discuss the background issue for line areas, which I think may impact IMSC later. 14:16:25 Topic: TTML 14:16:41 nigel: We have two open issues, one on TTML1, the other on TTML2: 14:16:51 https://github.com/w3c/ttml1/issues/209 14:16:56 https://github.com/w3c/ttml2/issues/150 14:17:35 nigel: There's been some activity on these issues, especially some digging about XSL-FO from Andreas and further 14:17:44 ... thinking from Glenn - thank you both very much for this. 14:18:04 atai: Before we go into the topic itself it may be good to put it into context, why the discussion started. 14:18:24 ... It's possible that the current behaviour as specified is not seen as sufficient to comply with presentation requirements. 14:18:44 ... Because they notice this they may go in a different direction from the spec. Other specs that use TTML may 14:19:05 ... add some requirements to what is in TTML to meet accessibility requirements. This is moving quite fast. 14:19:19 ... The key question is how TTWG leads the way in solving this issue. I think this should be done in an 14:19:35 ... interoperable fashion so that everyone uses the same kind of solution. It's important also to see the timescale 14:19:49 ... of how fast we should indicate what we want to do because this could help others use a solution in line with 14:19:54 ... what this group thinks is best. 14:23:10 nigel: I hope that everyone has had a chance to follow the discussion on the issue. Am I right in thinking that 14:23:42 ... we've ended up with a specification trace that the padding rectangle for spans is the same as the content rectangle 14:24:04 ... for TTML1, and is the area in which the background is painted, and that its height is actually defined? 14:24:25 glenn: That's correct except that the block progression dimension of the content rectangle is not actually well 14:24:54 ... defined. I've been looking at the textGap metric and it seems to be defined differently in different OSes. 14:25:13 ... I determined that the code in blink and webkit uses this textGap/lineGap metric. At least 4 different browsers, 14:25:30 ... Chrome, Safari, Firefox and IE basically matched each other in the height of the content area that they are 14:25:48 ... using. They've possibly reverse engineered each other and copied the behaviour without a CSS specification 14:26:15 ... that really nails that down. So some of the browser behaviour is not well specified. 14:26:31 q+ 14:26:33 ... I've discussed this issue with Bert Bos (on various occasions), and he and I agree that none of the CSS 14:26:47 ... specifications defines this well, and is an issue. 14:27:04 ... There's another issue whether to look at this as content rectangle or content rectangle. I'm opposed to 14:27:26 ... implementations that arbitrarily modify the padding rectangle because it could cause a TTML1 vs TTML2 14:27:44 ... conflict. I don't think we can use something that uses padding to expanding the background out, but I do 14:28:09 ... think we can do something to address the content rectangle height. I have a question to answer from Andreas. 14:28:14 ack atai 14:28:34 atai: Thanks for exploring this and explaining it. One interpretation is how we should interpret it from TTML1, 14:28:56 pal has joined #tt 14:28:58 ... where CSS is not the reference styling language. I think TTML2 is more looking at CSS which makes sense. 14:29:16 ... Although XSL-FO is not the easiest to read I think it is very well defined and detailed. At least if we want to 14:29:29 ... fix the normative behaviour of TTML1 we should be looking at XSL-FO. 14:29:48 glenn: The problem with that is that XSL-FO refers to CSS. What it says in one place say regarding line areas 14:30:06 ... does not necessarily match CSS implementations. In particular we chose the line-area line stacking strategy 14:30:22 ... because XSL-FO claimed that it was compatible with CSS, but in fact it might turn out that it is not precisely 14:30:37 ... compatible, for example on this issue of computing the nominal requested line rectangle based on text 14:30:46 q+ 14:30:50 ... altitude and depth without taking into account the gap metric. 14:30:59 s/.../glenn: 14:31:17 glenn: I haven't looked at the code in FOP, which I can, but my guess is it is trying to be compatible with CSS 14:31:23 ... and using lineGap. 14:32:28 nigel: I have a colleague who used FOP and the output showed the background very tight to the text so I suspect 14:32:33 ... it does not use line gap. 14:32:35 ack atai 14:32:59 atai: I'm happy to check with existing FO implementations. Either way that we look, the content area that is reserved 14:33:16 ... just for the text is not the one that fully covers the height of the line that is also covered by lineHeight. 14:33:36 ... For example if you set lineHeight at 400% of the font size then the content area will not fill the full height of 14:34:00 ... the text in the line, independently of whether we're looking at CSS or FO. In general there's a more strategic 14:34:22 ... question of how to deal with it, to open up to implementation how background colour is painted in inline areas 14:34:39 ... in the block progression dimension, or do we see an immediate need to add some extra vocabulary to control 14:34:52 q+ 14:34:59 atai: that behaviour, and if we want extra vocab, in which spec it should be and how fast we can have that solution. 14:35:21 ... The first question is most important - do we want to restrict all implementations to follow a single interpretation 14:35:37 ... of TTML1 or do we want to allow room for further specification? 14:35:41 ack pal 14:36:09 pal: As a minimum, if there's a single way of stacking lines etc then that should be written down somewhere. 14:36:26 ... Secondly, if we need to control that strategy to allow for authorial control then we'll figure out a parameter or 14:36:44 ... way to do that. There may be a way to do that, but the first step I think is to explain the current strategy. 14:40:27 nigel: [explains thinking behind padding extension possibility, and ways to allow freedom without blocking TTML2] 14:40:53 glenn: In TTML1 padding is clearly defined as 0, so there is no ambiguity there now. Saying that padding could 14:40:54 q+ 14:41:33 glenn: be extended is I think the wrong approach because it does not address the ambiguity in content rectangle height. 14:42:01 ... My contention is that we can define the content rectangle height clearly and retain padding semantics independently. 14:42:18 ... The problem of using padding is that it mixes the semantics of content rectangle height and padding rectangle 14:42:24 ... in a way that is problematic in my view. 14:42:45 ... I think we should start with content rectangle height, and I have a proposal to do that. The way forward is to 14:42:52 ... drill down on that and see if it works or not. 14:44:15 nigel: That's fine - we should certainly clarify the content rectangle if we can. My thinking to use the padding 14:44:33 ... rectangle is that it's clearly specified that background areas are painted in the padding rectangle, so that is 14:44:46 ... the concept that most closely matches the problem. 14:44:49 ack atai 14:45:22 atai: We also need to check if there is any impact on positioning or other concepts if we adjust the content 14:45:25 ... rectangle. 14:45:44 ... I think there's another approach which is to specify the background area, leaving all the other concepts as they 14:46:03 ... are. This would also be a solution, for me, because it would describe the semantic for all implementations, 14:46:22 ... even those that do not use CSS or XSL-FO engines. We should possibly just consider the solution for drawing 14:46:26 ... backgrounds. 14:46:56 glenn: I think the first point from Andreas is about the impact of changing the content rectangle on the baseline 14:47:13 ... and that's something that came up in the discussion with Bert. In the simple case of using a single font for a 14:47:32 ... whole line isn't really an issue, but if a mix of fonts or scripts on the same line is used then it becomes more 14:47:48 ... complex. I agree that we shouldn't do anything that mucks up the standard model for baseline. I think we can 14:48:05 ... do it without mucking that up. On the second point about redefining where and how background color is 14:48:24 ... rendered, I don't think we can do it any other way than by making it the padding rectangle. The first point of 14:48:44 ... order is to see if changing the content rectangle definition will satisfy the problem. If not then we can consider 14:49:01 ... the padding rectangle solution, which I'm very reluctant to entertain because of the impact on TTML2. 14:50:00 glenn: In response to Andreas's comment at https://github.com/w3c/ttml1/issues/209#issuecomment-200822590 14:50:27 ... I don't think that the comment is quite accurate, because the height of the line area rectangle is determined by 14:50:52 ... taking the minimum height that encloses the expanded nominal requested rectangle of each inline area, based 14:51:29 ... on the font of the paragraph... If you expand this to include leading then you don't need to add leading. Maybe 14:51:34 ... we can continue that offline. 14:51:43 atai: I think so - that needs some further thought. 14:52:03 ... We've made some good progress over the last few weeks, but we cannot come to a conclusion today. I want 14:52:24 ... to go back to the question of the default behaviour and adding extra vocabulary. The default behaviour now is 14:52:49 ... not what is wanted. Still we have the option of using Glenn's solution and a default of "auto" is still implementation 14:53:05 ... dependent. It is good to rely on a solution that would fit now and also in the future on TTML2, but I wonder 14:53:21 ... if there is a way to get it into an IMSC publication before TTML2. For a lot of specs IMSC is now the core 14:53:55 ... reference, and we all want the sub-profiles that depend on IMSC. I see a solution based on a timel 14:54:12 glenn: I think we can do better than defining an arbitrary default. We can define in an errata for TTML1 a note that 14:54:29 ... elaborates the semantics of content rectangle heights more clearly, and that it doesn't need to mention say 14:54:45 ... "auto" specifically but could define the default behaviour in a way that allows for some flexibility. If the 14:55:05 ... implementation does not have an opinion on this then we can suggest that a default default applies, for example 14:55:32 ... one of the options that we define in TTML2, say text altitude + text depth + text gap, or an extension to the 14:55:47 ... line area. We could make a TTML1 errata very quickly to satisfy the immediate need and then pave the way for 14:56:03 ... a more elaborate solution in TTML2 and IMSC 2 presumably. IMSC 1 itself could simply adopt the TTML1 errata 14:56:18 ... in order to get to the default behaviour that we're looking for. 14:56:28 pal: I really like that proposal. 14:56:30 nigel: +1 14:56:56 pal: I think people may want the behaviour to be controllable, so we should make clear that the behaviour is 14:57:11 ... clearly parameterisable so that we can carry that forward into TTML2. 14:57:28 glenn: Since we cannot add new functionality to TTML1 the best we can do is suggest that a future version could 14:57:41 ... provide more authorial control, and indicate what that may be. 14:57:57 pal: That's what I had in mind. 14:58:06 nigel: The parameters could also be provided externally to the document. 14:58:22 glenn: That's what I was going to suggest, that the implementation could have a parameter that is outside of the 14:58:35 ... document, just like is the case for forced display semantics. 14:59:00 atai: I think that this errata proposal could be a good way out for immediate requirements because then if some 14:59:16 ... spec needs an immediate solution they possibly could add some extra vocabulary that tries to be inline with 14:59:29 ... what may come up, and this would then make it easier for the transition to TTML2. 14:59:47 glenn: The most important thing is for Andreas and me to continue our discussion, and if we can get consensus 15:00:03 ... then that will give me clear indication on what I can propose in an errata, so if we can reach that fairly quickly 15:00:14 ... then I'll propose an errata straight after that. 15:00:19 nigel: Sounds great to me. 15:01:50 q+ 15:02:18 pal: If there is an external group with an interest in this then it would be awesome to have communication from 15:02:30 ... that group to explain what they're wanting to do. 15:02:42 glenn: I agree but I would suggest that we do not request them to propose a solution. 15:03:15 ... We've already got a statement of the problem - as long as we give them that behaviour then that would be okay. 15:03:17 ack atai 15:03:46 atai: I would also support what Pierre says, that having the communications to make sure we are aligned would be really great. 15:06:26 atai has left #tt 15:06:50 nigel: Thanks everyone. We're out of time, so just summarising where I think we're up to: 15:07:13 ... There's an action on Andreas and Glenn to conclude on their current discussion; 15:07:35 ... And one on me to see if we can get communications from the groups that are interested in this behaviour; 15:08:09 ... And we have consensus on producing a TTML1 errata note to explain this. 15:08:28 ... Next week I won't be around, and Pierre has kindly volunteered to chair. 15:08:35 ... Thanks everyone! [adjourns meeting] 15:08:38 rrsagent. draft minutes 15:09:26 s/rrsagent. draft minutes// 15:09:29 rrsagent, draft minutes 15:09:29 I have made the request to generate http://www.w3.org/2016/03/24-tt-minutes.html nigel 15:16:51 s/ways to allow freedom/that it should be possible to do this 15:20:27 rrsagent, draft minutes 15:20:27 I have made the request to generate http://www.w3.org/2016/03/24-tt-minutes.html nigel 15:20:59 ScribeOptions: -final -noEmbedDiagnostics 15:21:00 rrsagent, draft minutes 15:21:00 I have made the request to generate http://www.w3.org/2016/03/24-tt-minutes.html nigel 17:10:31 Zakim has left #tt