14:00:22 RRSAgent has joined #tt 14:00:22 logging to https://www.w3.org/2018/06/07-tt-irc 14:00:24 RRSAgent, make logs public 14:00:24 Zakim has joined #tt 14:00:25 cyril has joined #tt 14:00:26 Meeting: Timed Text Working Group Teleconference 14:00:26 Date: 07 June 2018 14:03:10 Log: https://www.w3.org/2018/06/07-tt-irc 14:03:22 Present: Nigel, Cyril, Pierre 14:03:25 Regrets: Andreas 14:03:36 Chair: Nigel 14:03:38 scribe: nigel 14:04:05 Topic: This meeting 14:04:51 pal has joined #tt 14:04:52 Present+ Glenn 14:05:37 Nigel: For today I think we mainly will focus on TTML2 - there are a few marked for the agenda, which we need to close off 14:05:42 .. today if we possibly can. 14:06:06 .. There has been activity on IMSC too - anything to discuss there today? 14:06:20 Pierre: It's not urgent so can wait in the light of other things. 14:06:35 Nigel: Is there any other business that isn't TTML2, or particular points to mention? 14:06:43 group: [silence] 14:06:50 Nigel: Okay let's dive into TTML2 issues and pull requests. 14:07:20 -> https://github.com/w3c/ttml2/labels/agenda Agenda topics for TTML2 14:07:57 Topic: Update requirements for claim of document (content) compliance (#495). ttml2#651 14:08:03 github: https://github.com/w3c/ttml2/pull/651 14:10:19 Glenn: TTML1 didn't have content profiles and referred to an abstract document type. So it uses the profile attribute to 14:10:22 .. drive. 14:11:24 Nigel: This is different. Oh wait, maybe it isn't. [thinks again] 14:11:58 Glenn: The portion in item 2 of the claims section is already in TTML1 regarding the ttp:profile attribute. Here we just added 14:12:12 .. the ttp:processorProfiles attribute and made a reference to effective processor profiles. 14:12:48 Nigel: Ok I think I may have been misreading this. 14:13:20 Glenn: The goal of this as pointed out by Pierre is to address the fact that it did not take into account the new profile mechanism. 14:13:41 Nigel: Okay I see we are not talking about processor conformance claims at all, just about document conformance, and all 14:13:52 .. that is required is to associate it with a content profile or a processor profile. 14:15:55 .. OK you've persuaded me, I'll approve this one. Apologies the delay. 14:16:05 SUMMARY: @nigelmegitt to approve changes 14:16:19 github-bot, end topic 14:16:59 Nigel: Pierre was requested to review - are you okay for us to go ahead with this? 14:17:02 Pierre: Yes, no objection. 14:17:22 Topic: Resolve confusion between default and implicit (#590). ttml2#652 14:17:28 github: https://github.com/w3c/ttml2/pull/652 14:17:45 Glenn: It's good to remind ourselves that the reason for this issue in the pull request is that some time ago we added a note 14:17:58 .. because a point was made that nowhere did we say anything about the default value for begin. When we got into the long 14:18:14 .. discussion about timelines and so forth that you initiated Nigel that came out of the discussion. But the language of the 14:18:41 .. note had some language "a default (implicit) value" and someone asked about the (implicit) and it was clear that it could 14:19:00 .. confuse the reader since SMIL mentions implicit, so we took out the implicit and tweaked the wording to make it more clear 14:19:19 .. that it was specifying a default value a bit like in a DTD. We could have everywhere we put begin, in the element information 14:19:33 .. item syntax, specified a default value that would be compatible with the other places we've done that for attributes but 14:19:49 .. we didn't do that, probably because SVG and SMIL didn't do it, they built the default into their processor. That was the only 14:20:10 .. real intent of this. Then Nigel pointed out that the value 0 is not syntactically correct and it needs to be something like 0s 14:20:29 .. so we made that change. The current text, if you look at the ED today, the paragraph already says the semantics of the 14:21:02 .. begin attribute are defined by [SMIL 3.0] §5.4.3 ... so we already define that. In the note we lead off with "As defined by 14:21:41 .. [SMIL 3.0] ... " which is not inconsistent. The most recent suggestion by @palemieux to refer to SMIL when no begin 14:21:57 .. attribute is specified merely repeats what was in the previous normative paragraph although it focuses on "when no begin 14:22:19 .. attribute" but we've already said that those semantics apply. In my mind it does not clarify for the reader what the default 14:22:38 .. value is without considering the interpretation of the semantics of that value. I carefully wrote the note to avoid saying 14:22:53 .. anything about what the semantics of the default value are. For such a simple change of a non-normative note we have 14:23:12 .. spent a lot of energy on that one. The no-op is to do nothing and leave the note as is with the word (implicit) in and with 14:23:29 .. the value of 0 without the s on it. We should at least clarify that because if you follow through what the SMIL document 14:23:46 .. says you would eventually get a value of 0 which is not compatible. At a minimum we need to say something but we could 14:24:02 .. go ahead and merge as is. 14:24:27 Pierre: My take on this is driven by the many hours spent trying to understand how TTML and SMIL work together. There is 14:24:41 .. already a sentence in SMIL that says that children of a par begin equivalent to 0 seconds. 14:24:47 Glenn: SMIL is inconsistent there. 14:25:09 Pierre: It's a note in SMIL 3. I would either just point to that note, or copy it verbatim. I would not try to reinvent things here. 14:25:23 Glenn: Why does SMIL say in the normative text 0 and then have a note that says 0s? 14:25:38 Pierre: I don't know. My encouragement is to copy and paste the informative note that we like in SMIL because then we're 14:25:46 .. consistent with SMIL and don't invent a third way. 14:25:56 Glenn: Do you think what's proposed here is inconsistent with SMIL 3? 14:26:13 Pierre: What I don't like is the notion of a default value, which is not a defined term in SMIL. There's no default as far as I can tell. 14:27:25 Glenn: The text in §5.4.4 defines the default value. 14:27:35 -> https://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-ParSyntax SMIL3 definition of default for begin 14:27:48 Pierre: I think this is really unfortunate. We should copy the informative note that says what we want. 14:28:07 Glenn: I think the note says what we want and is not inconsistent with SMIL in that it does not override the semantics of SMIL. 14:28:41 .. It does the job for the reader. I noted a while ago that it requires the reader to chase down text in SMIL 3 - even you [pierre] 14:28:44 .. hadn't found that yet. 14:29:14 .. [summarises https://github.com/w3c/ttml2/pull/652#issuecomment-395288250 ] 14:29:27 .. The point of this was to help out the reader not to make them do this chasing and miss information. 14:29:37 Pierre: The issue is that saying the default value is 0s is not the full story. 14:29:48 Glenn: Of course, and that's why I don't want to paraphrase what it means to say 0s. 14:30:52 Pierre: I think the note is unhelpful. 14:31:00 Nigel: Is it misleading or wrong? 14:31:07 Pierre: It oversimplifies something that's a lot more complex. 14:31:31 .. Clearly removing (implicit) corrected the defect in the ticket, so that's essential. 14:31:49 Glenn: Right, and the second change was to change 0 to 0s after Nigel noted that it was inconsistent with TTML. 14:32:20 Pierre: I think it's a bad note. 14:32:44 Nigel: I'm hearing that it corrects the defect but that Pierre's concern is that it doesn't direct the reader to see that there's more 14:32:52 .. to it than just the default value. 14:33:14 Pierre: Right, I don't want to paraphrase what SMIL already says. 14:33:31 .. I don't want to change the normative text. If nobody else thinks its a bad note then go ahead. 14:33:42 .. I'll remove my review that blocks this. 14:35:27 SUMMARY: Pull request resolves the defects in the issue, so proceeding. Concern registered that the note may not direct the reader to the full complexities, however they are normatively present. 14:35:51 github-bot, end topic 14:36:59 Topic: Add features for standard and high dynamic range PNG images (#694, #6… ttml2#770 14:37:06 github: https://github.com/w3c/ttml2/pull/770 14:38:42 Nigel: #796 has pull #810 open with two approvals and no changes requested so for the purpose of discussion I think it 14:38:46 .. can be considered resolved. 14:39:01 .. That pull request modifies the behaviour of luminanceGain. 14:39:33 Glenn: The only issue in my mind at this point is if we can refer to a WG note normatively. 14:39:43 Nigel: We simply don't need to. 14:40:24 .. There's an ITU ref for HDR. 14:40:33 Pierre: This is for HDR PNG. 14:41:36 .. My suggestion is we split into two. 14:41:47 Nigel: luminanceGain does not need PNG 14:42:06 Pierre: That's why I don't mind pushing the png hdr feature into a separate pull request that may not be approved in time. 14:42:19 Glenn: If we're going to make the decision to take out the feature we should close the issue. 14:42:34 Pierre: I can take the action item to reach out to Mike to see how to make progress on #695. In the meantime 14:42:39 .. we can close #694. 14:43:00 Glenn: Okay so I will just remove the aspects of this pull request that deal with #695 and comment it in the notes of the pull 14:43:08 .. request. Then we should be able to approve that right away I hope? 14:43:12 Pierre: The PNG part, absolutely. 14:43:23 Glenn: Then we can consider whether to close #695 without further action separately. 14:43:27 Pierre: That's what I'm proposing. 14:43:31 Glenn: I'm fine with that. 14:43:43 .. I want to wrap up #695 in the next day or two. 14:44:01 Pierre: We're waiting to hear back from @plhegar 14:44:12 Glenn: The issue is do we want the feature at all. 14:44:23 Pierre: Mike Dolan wants one, and I think it's in use today so it would be useful. 14:44:30 Glenn: I think so, and it's in IMSC 1.1, right? 14:44:34 Pierre: Just informatively. 14:44:45 Glenn: Maybe it is in the requirements document for IMSC vNext. 14:45:08 Pierre: I don't know, I can follow up with Mike and others possibly regardless in a sense of what Philippe comes back with. 14:45:22 .. Maybe there's a way to mention it informatively. We can close #694 today. 14:45:34 Glenn: Okay I have to do a little work but I can do that right away after the meeting. 14:46:00 Nigel: +1 to this suggestion from me. 14:46:14 .. Objections to closing #694 with this pull request and dealing with #695 separately? 14:46:33 RESOLUTION: Modify this pull request to deal with #694 only. 14:46:46 github-bot, end topic 14:47:19 Topic: tts:rubyReserve length component semantics ttml2#779 14:47:25 github: https://github.com/w3c/ttml2/issues/779 14:47:50 Glenn: We don't have a pull request for this issue. The lingering question from Pierre is how does an author come up with 14:48:09 .. a value for length in rubyReserve. I pointed out that in my opinion it is the same issue with a length for lineHeight, and 14:48:23 .. if you do specify a length then the language is clear and the implementation aspects are clear for what that means. I don't 14:48:34 .. believe there's any substantive issue in using an actual length value there. 14:48:43 .. Then Nigel had a follow-on comment to Pierre earlier today. 14:49:01 Pierre: On the first point I think it is different than lineHeight because lineHeight does not set the inter-line distance, as we 14:49:09 .. have discussed many times before, whereas this sets a hard value. 14:49:24 Cyril: About the fact that lineHeight does not set the inter-line distance, is that agreed? 14:49:55 Glenn: It goes to the definition of per-inline-height-rectangle in the section on line areas in XSL and whether or not one 14:50:12 .. increases the line height on a per line basis if something is larger than the line height value. If you look at the way that 14:50:33 .. line height is implemented in browsers, if you do specify a line height then it sets it only once so it is the inter-line distance 14:50:37 .. effectively. 14:50:48 Pierre: That's not my experience with ruby, the line height changes. 14:51:09 Cyril: In Burlingame @fantasai said that you have to increase the line height because CSS does not do that. 14:51:15 Pierre: Not in Firefox. 14:51:31 Cyril: If you don't specify lineHeight then the distance between lines is implementation-dependent, right? 14:51:52 Glenn: We have an algorithm in lineHeight for computing the nominal inline rectangle height associated with every line, then 14:52:08 .. on top of that you have the application of the line stacking strategy that we say applies in the flow transformation section, 14:52:30 .. which says per-inline-height and XSL says that translates to what CSS does and I believe that's true although some implementations 14:52:46 .. of CSS might not follow that exactly. Some things are implementation dependent but it depends what version of CSS you 14:53:03 .. look at. Going back to CSS2 there was discussion of how you discuss the nominal inline height rectangle based on the 14:53:20 .. paragraph and the font metrics from the list of font families that you resolve to. That text from 1998 has been progressively 14:53:38 .. elaborated and extended to make it more clear. The latest CSS 2.2 ED is much closer to what is more carefully articulated 14:53:49 .. in XSL so if anything it is getting closer to XSL not further away. 14:54:08 .. That doesn't mean that implementations are consistent in this matter. Even putting ruby aside, which is not really specced 14:54:29 .. out and there's not much in the way of implementations, there are still differences in how CSS browsers like Chrome vs 14:54:39 .. Firefox are handling the most simple aspects of lineHeight. 14:54:52 .. There's still more variation in terms of CSS implementations. 14:55:21 Nigel: Rewinding the stack, Cyril are you clear? 14:55:28 Cyril: As much as I'm going to be. 14:55:42 Pierre: My second point was already covered. If ultimately the only way to do this is to specify an absolute additional space, 14:56:07 .. (the value "normal" should be left completely to implementations because right now the computed length is related to the 14:56:27 .. used line height value and that's not available in a CSS implementation where line-height is normal) 14:56:57 Glenn: One solution would be to say that if the length is not specified in rubyReserve then it is implementation dependent. 14:57:19 Pierre: That would address my second point. I'd like to go back to the first point and see if we can think of a way to 14:57:24 .. help the user. 14:57:46 .. When there's an explicit length, I'm trying to avoid having the author need to play with values until it "kind of works". 14:57:56 Glenn: Don't you have to do the same for lineHeight? 14:58:15 Pierre: Most authors use "normal" and are happy with what they get - it "just looks good", literally. 14:58:50 Nigel: Can we stick to rubyReserve for now - the fact there may be a problem with lineHeight too is separate. 14:58:58 Pierre: Can we think of a better way of doing this 14:59:04 s/this/this? 14:59:09 Glenn: I don't mind but after TTML2 14:59:18 Pierre: This is going to be a real obstacle for authors. 14:59:43 Glenn: I understand about dealing with length when it is explicitly specified, from a CSS perspective, but TTPE just increases 15:00:02 .. the line height above or below by the specified amount, depending. You have to take into account the ascender and descender 15:00:30 .. and half-leading for the inline areas. It's easy to figure out the maximum and add it above for ascenders and below for descenders. 15:00:35 Pierre: you can't do that in CSS 15:00:49 Glenn: I agree we have specced out things that can't be done easily or at all in CSS. That's a different issue. 15:01:03 Pierre: It's an important data point - if it can't be mapped to CSS then it won't be used. 15:01:33 .. There are other features that are painful to implement but can be done. This here just can't be done. 15:02:06 Nigel: Do we need to support it, in which case we need an issue on CSS, or does CSS do it a different way that we should 15:02:07 .. adopt. 15:02:12 s/t./t? 15:02:31 Pierre: CSS doesn't consider this, the only suggestion is to reserve space by increasing the line height. CSS does not have 15:02:38 .. anything resembling rubyReserve. 15:03:08 Glenn: If you can divide your paragraph into multiple lines like you are already doing [in imsc.js]... 15:03:16 Pierre: That's different lines not different paragraphs. 15:03:38 Glenn: I think you can implement this in CSS by doing line breaking then you divide into multiple paragraphs CSS-wise and 15:03:52 .. specify the line-height on each of those differently for rubyReserve. 15:04:02 Pierre: You can't set above or below. 15:04:10 Cyril: Yes you'd have to change the baseline alignment also. 15:04:26 Glenn: There is a way to change the baseline offset in XSL, I'm pretty sure that can be done in CSS. 15:04:30 Pierre: I've not seen it. 15:04:51 Glenn: If the result is that some space is reserved so that if you add or subtract ruby it does not change the line spacing, then 15:04:59 .. it might not look the greatest but it would work. 15:05:15 Pierre: I've implemented it by putting an empty ruby container at the beginning of each line. 15:05:23 Glenn: you insert `
`s? 15:05:31 Pierre: Yes 15:05:37 Glenn: So it's a ruby container with a strut? 15:05:50 Pierre: Exactly. That guarantees it is exactly as if a ruby were present. 15:06:05 Glenn: It sounds like you could support it then using that technique. 15:06:27 Pierre: Right, but if the language for absolute length were worded where it was the length of the strut in the ruby text line 15:06:38 .. area, then that would work. 15:06:55 .. I still think that even if it were possible to do this in CSS I'm still not happy with the fact that the author has to pick this 15:07:04 .. absolute length. I'm trying to see if there is a better way of doing it. 15:07:15 Glenn: One thing we could do is take out `` completely. 15:07:30 Pierre: Yes, the only downside to that is that you can today override the "default" font size on ruby annotations. 15:07:40 Glenn: That was the intent of having `` in the first place. 15:08:01 Pierre: My first inclination, in the spirit of exploration, is to change `` for a font size. That does not take into account 15:08:18 .. the exact font, decorations etc but that's closer to what the author can specify. That was one thought. 15:08:32 Cyril: I don't understand about overriding the default size of ruby annotations. 15:08:51 Pierre: On the ruby text container you can set fontSize=200% and the ruby ends up twice as big as the base. 15:08:56 Cyril: Yes, and... 15:09:11 Pierre: That changes the size of the ruby text and therefore the amount of space that has to be reserved. 15:09:27 Glenn: I can see how this can be handled for the default value, but not how it would help if you specify an explicit length. 15:09:43 .. If you would like to change an explicit length from being an absolute value to being .. 15:09:49 Pierre: An 'em' 15:10:06 Glenn: Right, and act accordingly, then that would not work if you had different font sizes or different fonts generating 15:10:12 .. different ruby text container. 15:10:20 Pierre: Or use emphasis on your ruby text. 15:10:48 Cyril: The way I'm using rubyReserve at the moment is I'm setting it on div. You're saying if the ruby font size is changed then 15:10:56 .. that value would be wrong? 15:11:08 Pierre: Yes, I'm exploring how to make it easy for the user not to make a mistake. 15:11:45 Glenn: I'm willing to change the semantics of length so that if you specify an absolute value then have length not be absolute 15:12:04 .. but pretend that this was the ruby font size used with all ruby text in this paragraph and do it as though that were the case. 15:12:07 Cyril: The maximum 15:12:11 Pierre: exactly. 15:12:25 Glenn: Then I would need to change the semantics of `` as well. 15:12:31 Pierre: And the default has to be implementation dependent. 15:12:43 Glenn: Yeah... I'd like at least a note that suggests some approach. 15:13:03 Pierre: The reason I'm bringing this up is I implemented the exact lineHeight="normal" algorithm specified and the overwhelming 15:13:21 .. feedback from users is that it was stupid and they preferred what browsers do when line-height is normal. 15:13:30 .. I like the idea of a note but unfortunately it should be left to implementations. 15:13:48 Glenn: Even for lineHeight we have an algorithm that ascribes meaning to "normal". 15:14:13 Pierre: In practice that does not work. People expect normal to just look good, to have enough space for text. That's the bottom line. 15:14:22 Glenn: The note is "it's implementation dependent but make it look good" 15:14:42 Pierre: It's unfortunate. I don't know how to fix it. rubyReserve should be worded to give leeway to implementations. 15:15:17 Glenn: I'm interested to know if this would cause an implementation problem. 15:15:23 Cyril: I'll check with our guys. 15:15:40 Glenn: I'm happy to make a pass at making that change so implementers can review what Pierre is proposing. 15:15:57 Pierre: I'm happy to implement a straw man in imsc.js 15:16:09 Glenn: I'll get something substantive out today or tomorrow. 15:16:28 .. If we do this as a substantive change in TTML2 I expect to ask for permission to merge at our next meeting. 15:16:47 .. We have a publishing moratorium coming up, and that could push us out even further. 15:17:12 Cyril: I'd like to ask that we do an early merge of all the pending merges, it is hard to review the final spec. 15:17:23 Glenn: I second that. 15:18:29 Nigel: I'm unclear of the status of this proposal - are we saying we will prepare it and make this a resolution, or have a go 15:18:39 .. at doing it and then an implementation play before confirming? 15:18:44 Glenn: We could do the former. 15:19:10 s/c/sh 15:21:16 RESOLUTION: Change the interpretation of the length component of rubyReserve to mean the font size of ruby text for which reserved space is created. 15:22:51 RESOLUTION: If the rubyReserve length component is not specified use the default value of the ruby text font size computed from the paragraph font size. 15:22:56 github-bot, end topic 15:23:27 Topic: Add tts:lineShear and tts:shear style attributes (#784). ttml2#807 15:23:32 github: https://github.com/w3c/ttml2/pull/807 15:23:47 Glenn: As far as I can tell this is wrapped up but Nigel you want to talk about fontShear. 15:24:37 Nigel: The reason I haven't approved this is because I took it that we were tidying up all of fontShear, lineShear and shear 15:24:44 .. and it looked as though we weren't there yet. 15:26:09 Nigel: One of the things I took from the discussion is that nobody wants fontShear and that it cannot be done in CSS so 15:26:36 .. it seems like the easiest fix is to remove fontShear. 15:26:49 Glenn: As I pointed out in lambdaCap there is a requirement for this. 15:27:02 Nigel: And you cannot shear a word individually in CSS, right? 15:27:06 Pierre: No you cannot. 15:27:28 Glenn: Popular word processors provide a way to do this and it is not dependent on lines or blocks but is on a per character 15:27:30 .. basis. 15:27:48 Cyril: It is weird because they export CSS, so I wonder how they do that. 15:27:56 Pierre: What I've seen is they just use oblique 15:28:02 Glenn: Use of oblique could be a fallback. 15:28:12 Pierre: I don't know of anyone who will use fontShear for subtitles and captions. 15:28:31 Glenn: I have real world examples of Japanese captions that do it on a per-character basis, where some characters on a line 15:28:37 .. have shear and some have no shear. 15:28:56 Pierre: Everyone I've asked has been unable to provide a practical example, so I would love (not facetiously) to see a real 15:29:00 .. world practical example. 15:29:33 Cyril: We're trying to see if we are removing a feature because it might not be used. It is harmless to keep it. 15:29:46 Pierre: Yes, put it at risk and move on. 15:30:10 Glenn: I expect us to have two implementations. 15:30:22 Pierre: I don't mind keeping fontShear in TTML2. 15:30:29 Nigel: Okay, let's keep it. 15:32:38 glenn has joined #tt 15:32:38 https://github.com/w3c/ttml2/issues/784#issuecomment-390849465 15:33:08 Nigel: Now moving to the example, am I incorrect in thinking that glyph area fontShear should result in glyph areas being 15:33:11 .. spaced apart? 15:33:34 Glenn: The link I just added makes that clear from the lambdaCap spec. 15:33:51 .. It is true that if you have a boundary between different shear values then to make it look good you have to do something 15:34:16 .. with spacing between that boundary. TTPE uses some heuristics. Say you go from +ve shear to 0 shear. In a horizontal 15:34:36 .. layout you have slant to the right. If you did nothing then there would be overlap at the boundary. In TTPE for glyph or 15:34:52 .. character widths it computes a different width just to handle the boundary cases. 15:34:56 Nigel: Ok I see. 15:35:06 Glenn: I didn't want to dive that deep in the spec. 15:35:24 Nigel: Fine, so we're happy that the examples are not incorrect. 15:36:12 .. In that case all my comments are resolved so I'll approve. 15:36:36 Cyril: I made one comment once that the way we resolve the shear transformation is that 100% translates to 90º and that 15:36:47 .. resolves to an unresolved calculation. I suggested using a formula instead. 15:37:06 Glenn: I didn't see that. Can we take that offline? That's a potential bug with the shear transformation section. 15:37:15 Cyril: It's purely editorial, I will send you the comment. 15:37:26 Glenn: I suggest you create an issue for that and we handle it as an editorial change. 15:37:59 SUMMARY: Following discussion, Nigel's change requests have been resolved. 15:38:06 github-bot, end topic 15:38:35 Topic: Further refinement of features (#814). ttml2#815 15:38:41 github: https://github.com/w3c/ttml2/pull/815 15:38:45 Nigel: Why is this on the agenda? 15:38:53 Glenn: Because there are comments but no approval. 15:39:23 .. The last comment is to add a note - I wouldn't object to such a note but I don't think it's necessary. In the interests of 15:39:30 .. moving on I'd prefer to get this approved now. 15:39:46 .. We could add such a note in PR. 15:39:53 .. It is strictly editorial. 15:41:11 Nigel: The more important comment is https://github.com/w3c/ttml2/pull/815#discussion_r193401615 15:41:36 Glenn: I wanted to say you could support #extent-image without supporting #extent-auto-version-2. 15:42:10 .. I didn't want to force you to support all the values. 15:42:28 Nigel: Right, we're agreed on that, but it's not clear at the moment, so I wanted to split out auto on region from auto on image 15:42:31 .. as two separate featuers. 15:42:39 s/uer/ure 15:42:58 Pierre: Yes please. The semantics are so different that it really makes sense. 15:43:48 Glenn: I was thinking of #auto-version-2 as a mix-in feature - if you did not support extent-image but you turned on 15:44:02 .. auto-version-2 then that would apply to region and tt but not image since image is not supported. 15:45:11 Nigel: But you have no way to say you support auto extent on image but not on tt and region. 15:45:32 Glenn: That's true, and we have that situation in other places too, for example length-measure implies support wherever a 15:45:44 .. length is supported. All the length features are basically mix-ins. 15:46:55 Nigel: I think it's a minor editorial task to do what I'm suggesting here. 15:47:06 Glenn: OK, I can do that. 15:47:18 .. If we do that is there anything else on this that needs more wor. 15:47:24 s/wor./work. 15:48:10 Nigel: If we do that then it's particularly apposite to add the note I propose in https://github.com/w3c/ttml2/pull/815#discussion_r193402545 15:48:31 Glenn: How about we create `#extent-region-version-2` that implies auto support? 15:48:51 Nigel: That could work. 15:49:06 Glenn: I have enough to proceed. 15:49:30 .. If I get the pull request fixed today maybe you guys can review it before the weekend. 15:49:33 Nigel: okay, thanks. 15:49:57 SUMMARY: @skynavga to address outstanding comments as discussed above. 15:50:00 github-bot, end topic 15:50:37 Topic: TTML2 Pull Request early merges 15:50:55 Glenn: Cyril proposed that we do an early merge of outstanding pull requests. 15:51:03 .. If we agree then I'll do it in the next couple of days. 15:51:14 Pierre: Can I propose that we go for a new CR in two weeks. 15:51:32 .. And issue a Call for Consensus today. 15:51:47 Nigel: We can't do that because there's work to be done. 15:51:53 Pierre: Can we make it contingent? 15:52:26 Glenn: I'm hearing a suggestion to run our review in parallel with the CfC for CR2. 15:52:42 Nigel: We have precedence for that, but I can't issue a CfC for something that does not exist yet. 15:55:13 .. Can I suggest that the changes we agreed today are done and we try to move all PRs by Monday, at which point I can issue 15:55:16 .. a call for consensus. 15:55:44 Pierre: That's okay. 15:55:57 .. What we're saying is we're freezing the issues as of today. 15:56:06 Glenn: Freezing them and still allowing new PRs on those issue. 15:56:23 Pierre: Right, and if all those PRs are merged on Monday, then initiate a consensus. 15:56:35 Glenn: And Nigel would make the call on Monday. 15:56:39 Nigel: That's right. 15:56:55 Cyril: I'm fine with that. Just to make sure, if we find editorial issues we can still address them during CR2, right? 15:59:02 Nigel: We have two windows here: during CfC if issues arise as a result of the early merges then they need to be addressed 15:59:50 .. and could cause us to stop. After CR2 is published substantive changes can only be made on the way to PR if they are 16:00:01 .. removal of at risk features, otherwise we need a CR3. 16:00:14 Pierre: I think it's important to go to CR2 as soon as possible. 16:00:17 Glenn: I agree 16:01:13 PROPOSAL: Merge outstanding pull requests on Monday with the intent of the Chair issuing a CfC for transition to CR2. 16:01:42 Nigel: Any objections? 16:01:45 RESOLUTION: Merge outstanding pull requests on or before Monday with the intent of the Chair issuing a CfC for transition to CR2. 16:01:56 Glenn: Thanks everyone for helping get through the issues. 16:02:06 Pierre: I'm available to help with the rubyReserve stuff. 16:02:12 Topic: Meeting Close 16:04:49 Nigel: Thanks everyone! [adjourns meeting] 16:04:52 rrsagent, make minutes 16:04:52 I have made the request to generate https://www.w3.org/2018/06/07-tt-minutes.html nigel 16:09:42 Regrets+ Thierry 16:09:52 ScribeOptions: -final -noEmbedDiagnostics 16:09:54 rrsagent, make minutes 16:09:54 I have made the request to generate https://www.w3.org/2018/06/07-tt-minutes.html nigel 16:29:03 Zakim has left #tt