14:00:25 RRSAgent has joined #tt 14:00:25 logging to https://www.w3.org/2018/08/30-tt-irc 14:00:27 RRSAgent, make logs public 14:00:27 Zakim has joined #tt 14:00:29 Meeting: Timed Text Working Group Teleconference 14:00:29 Date: 30 August 2018 14:01:25 Log: https://www.w3.org/2018/08/30-tt-irc 14:01:31 scribe: nigel 14:01:44 Present: Glenn, Cyril, Thierry, Pierre, Nigel 14:01:48 Regrets: Andreas 14:01:57 Chair: Nigel 14:03:30 Topic: This meeting 14:03:41 Nigel: Hi everyone, welcome back after our 2 week break from meetings. 14:04:41 .. For today, we have TTML1 3ED tests, TTML2 actions and tests, IMSC? 14:04:57 Pierre: If we have time it would be to discuss how to progress on rh and rw (not urgent). 14:05:06 NIgel: Ok, thank you, let's do that. 14:05:22 Pierre: I can give you an issue: imsc-tests#77. 14:05:34 s/NIgel/Nigel 14:05:55 Nigel: We also have some progress on IMSC vNext Reqs which we should try to get out of the door if we can. 14:06:17 .. On CSS, there's been a bit of progress on content box sizing to mention if there's time. 14:06:35 .. I'm not aware of anything on profile registry. 14:06:48 .. Any other specific points to raise or other business? 14:07:04 Pierre: Given we're about 1 month away from scheduled PR transition, it'd be good to 14:07:22 .. look at the TTML2 CR Exit Criteria and check we have consensus on what they mean. 14:07:32 .. It would be too late if we have a disagreement on October 4. 14:07:40 Nigel: OK let's do that in the TTML2 agenda section. 14:08:01 Glenn: I added 2 agenda PRs on TTML2 last night. 14:08:07 Nigel: Thank you, I didn't notice those. 14:08:13 .. We'll cover them in TTML2 also. 14:09:12 Nigel: Let's cover the agenda in order. 14:09:16 Topic: TTML1 14:09:38 Nigel: We have 3ED tests to review, thank you Pierre - https://github.com/w3c/ttml1/pull/361 14:10:15 .. I haven't managed to pick this up again since returning from vacation. Anything to discuss on this? 14:10:19 group: [silence] 14:10:32 Nigel: Okay let's review as normal on GitHub. 14:11:14 Glenn: On these tests, Pierre, do we have implementation support for them all at this point? 14:11:24 .. Is there any idea that we won't be able to produce implementation for ... 14:11:51 Pierre: The only one is 2-value relative font size, which imsc.js won't be able to demonstrate 14:11:57 .. for presentation. 14:12:08 Glenn: Okay TTPE can demonstrate that. That should be no problem. 14:12:15 Nigel: Is that only one implementation then? 14:12:30 Pierre: One validator and one presentation engine. 14:12:38 Nigel: Do we have an independent validator? 14:12:54 Pierre: Whatever validates TTML2 should validate those by extension. Whatever we do for 14:13:03 .. TTML2 will have to work with this, by definition. 14:13:29 Nigel: Okay we'll be needing two independent implementations for that test. 14:13:42 Pierre: Again, whatever scheme we come up with for TTML2 will apply. I'd focus on solving 14:13:50 .. the TTML2 challenge then we can talk about this. 14:14:26 Glenn: I haven't looked at the TTML1 3ED CR Exit criteria - is it the same as TTML2? 14:14:35 Pierre: No, slightly simpler, just 2 independent implementations. 14:14:50 Nigel: The whole profile validation semantic test requirement doesn't apply. 14:14:58 Glenn: Okay, thanks. 14:15:13 Pierre: By the way Glenn have you run TTXV on the files? 14:15:20 Glenn: I haven't had a chance to use it to validate them. 14:15:35 Pierre: I'll run them through it now. 14:16:08 Nigel: Please could you add a comment to the pull request when you've done that? 14:16:12 Pierre: Yep. 14:16:19 Nigel: Thank you 14:16:52 Topic: TTML2 14:16:56 action-443? 14:16:56 action-443 -- Glenn Adams to Prepare a document showing mapping arib ruby extension features to ttml2 for use as a liaison document to arib. -- due 2018-08-09 -- OPEN 14:16:56 https://www.w3.org/AudioVideo/TT/tracker/actions/443 14:17:18 Glenn: Nothing new to report there right now. 14:17:48 Nigel: Thank you Glenn for your note about completing the validation tests. 14:18:27 .. I guess that means folk can review the validation tests and we are moving ahead with 14:18:29 .. presentation tests? 14:18:51 Glenn: I first populated tests related to features involved in IMSC 1.1. 14:18:53 Nigel: Presentation tests? 14:19:07 Glenn: Yes. With the exception of #content-profiles I've already populated presentation 14:19:22 .. tests for all the features in IMSC1.1, and for each presentation test I am also including 14:19:36 .. a ZIP file that contains the output from TTPE to give a quasi-reference content to look at 14:19:49 .. for visual comparison. I will be adding some information to the README to describe that 14:20:01 .. information more over the next few weeks but it's basically the output from TTPE which 14:20:14 .. consists of one or more SVG files representing the output image and a manifest file which 14:20:29 .. associates time for a particular frame that the SVG represents. Those are being populated 14:20:41 .. together with the tests. Beyond those I have now populated about 100 presentation tests 14:20:57 .. altogether covering most of the new style features and I'm working through those. At this 14:21:08 .. point I'm only aware of one implementation working on satisfying the non-IMSC 1.1 14:21:23 .. tests for presentation, which is TTPE, so that work is progressing rapidly. I'm confident 14:21:38 .. we will have all the remaining tests in place in time for Sep 26 ahead of PR. 14:21:56 Nigel: We are still working on an implementation for the audio features, called "adhere" and 14:22:06 .. I have begun working on presentation tests for the audio style features. 14:22:17 .. Is that a duplication of effort? 14:22:34 Glenn: Thanks for mentioning that, no, we're not doing those features, nor disparity and luminanceGain 14:22:51 .. which imsc.js is doing. We're depending on adhere to satisfy the audio features. 14:22:57 Nigel: And producing tests also? 14:23:05 Glenn: Yes, if you can supply tests that would be great. 14:23:08 Nigel: I'll do that. 14:23:24 .. Thank you for the status update. 14:24:45 Nigel: Let's cover the requested discussion of exit criteria and then the pull requests 14:24:48 .. marked for agenda. 14:25:37 .. [reads the TTML2 CR exit criteria] 14:25:50 .. Pierre you wanted to clarify the interpretation? 14:26:03 Pierre: Thanks. Today based on Glenn's report it looks like we will have one presentation 14:26:18 .. processor for every feature, combining the BBC work, imsc.js and TTPE. Correct me if I'm 14:26:26 .. wrong but we're good on the presentation side. 14:26:31 Glenn: Modulo one of the opened issues. 14:26:48 Pierre: Now, validation. My understanding, for someone to disagree with or not, is that 14:27:01 .. TTV cannot be used because it is not independent of TTPE, and further, IRT will be offering 14:27:14 .. IRT SubCheck as an independent validating implementation, and that will cover all of 14:27:25 .. IMSC 1.1. And TTV can be used for audio features because TTPE does not implement 14:27:41 .. those, similarly for luminanceGain and disparity. That leaves the remaining TTML2 14:27:55 .. features. How do we deal with those? Do we need an independent implementation? 14:28:05 .. What are the requirements of such an implementation? 14:28:17 Nigel: My answer would be yes, we do need an independent implementation, and the 14:28:31 .. requirement for it would be that it is a transformation processor. 14:30:34 .. First point: every feature needs at least 2 independent implementations. 14:31:08 .. Second point: if there are any features that do not define both transformation and 14:31:29 .. presentation semantics, then TTV or TTPE can do one of those, and another independent 14:31:36 .. implementation is needed for one of those functions. 14:31:41 pal has joined #tt 14:31:59 .. Do we have any features that do not define both transformation and presentation semantics? 14:32:12 Glenn: The transformation output is application dependent. 14:32:42 Nigel: That's different - it's about what the spec defines. 14:32:50 Pierre: linebreak-uax14 is an exception. 14:32:58 Nigel: We can exclude that because it's a TTML1 feature. 14:33:36 Glenn: The #speech feature is dependent on the processor support only. 14:33:51 Nigel: Right, that has no transformation semantic. 14:34:33 .. In that case for #speech, both implementations must be presentation processors and 14:34:37 .. validation is not applicable. 14:34:56 .. For all the rest, of the new TTML2 features, we do need an independent implementation 14:36:34 .. that either validates or presents the features that are not covered by TTPE, since all 14:36:41 .. the validation tests are passed by TTV already. 14:36:55 Glenn: I didn't add a column for "both validating and presenting" processors. 14:37:27 Nigel: I don't think you need to. 14:37:44 Glenn: I consider TTV to be a transformation processor whose output indicates validity. 14:37:49 Nigel: I think that's right. 14:38:08 Glenn: It can be used independently of TTPE or as a pre-processor. 14:38:30 Nigel: Yes, but that independent running does not mean they are independent implementations. 14:38:49 Glenn: I wanted to mention that. The Charter and the Process don't define independence, 14:38:55 .. we should let the Director decide. 14:39:19 .. In that vain, in the current Google sheets document that we're populating, I've put a couple 14:39:34 .. of columns to count implementations. There's a #v column that counts validation implementations. 14:39:43 .. There's a #p column that counts presentation implementations. 14:39:55 .. Then #t is the total of those. It does not try to assess independence. 14:40:24 Nigel: I don't think that's correct that there's no definition of indepedence. 14:40:39 Glenn: I read the Process carefully last night and it doesn't say what is meant. 14:41:36 Nigel: Thierry, do you have a view on this? 14:41:44 Thierry: As usual, you have to make your case to the Director. 14:42:03 .. There is not a strict policy in W3C documents that says. 14:42:20 Glenn: Interestingly one of the questions is "are there implementations created by people 14:42:32 .. other than the authors of the specification?" ! 14:42:45 .. My opinion is we should count what we think are implementations and present that to 14:42:47 .. the Director. 14:42:56 Pierre: We can't wait until Oct 4 to find that assumption is wrong. 14:43:32 .. We should check tomorrow with the Director. 14:43:44 Glenn: I'm not arguing we should say TTV and TTPE are independent. I'm just saying we 14:43:58 .. should present the information. If we want to present background information about 14:44:37 .. the organisations that created the implementations we could do that. I'm just pointing 14:44:41 .. out that there's no definition. 14:44:46 Nigel: What about the Charter? 14:44:59 Cyril: It says "n order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each of feature defined in the specification." 14:45:06 .. I guess this was agreed by the Director. 14:45:16 Nigel: Yes, and it links back to the Process document for the section on independence. 14:46:08 .. I raised an issue with the Process group about this, which is closed at the moment: 14:46:17 -> https://github.com/w3c/w3process/issues/167 define "independent" #167 14:47:24 Thierry: This has been ongoing for years. My personal view which the Director usually 14:47:35 .. takes also is that if the implementations share code they are not independent. 14:47:56 Glenn: In the case of TTV and TTPE for example, one option for TTPE is to ingest the ISD 14:48:10 .. documents produced by TTX, so it doesn't need to start with the TTML document which 14:48:24 .. is then ingested through the validating process of TTV as a pre-processing module. 14:48:36 .. It can take the ISD documents from TTV or TTX or somewhere else as input. In that sense 14:48:47 .. one could potentially make the argument that they do not share the same code but it is 14:48:50 .. a processing option. 14:49:11 .. There is another question which is what it takes to satisfy Nigel's interpretation for the 14:49:15 .. transformation aspects. 14:49:29 Nigel: Thanks. There are two things I'd like to comment on: 14:49:40 .. 1. Transformation requirements. 14:49:54 .. 2. The case I will need to make to the Director that we have satisfied the exit criteria. 14:50:00 .. Taking them in order... 14:50:15 .. Transformation requirements - the implementation needs to do some kind of 14:50:31 .. transformation as per the feature designator's definition of the transformation semantics. 14:52:10 .. Take #bpd for example. The feature designator refers to the tts:bpd attribute, but 14:52:26 .. the spec does not define any transformation semantics. So in that case merely noting 14:52:42 .. the existence of tts:bpd in a document would satisfy the transformation requirement. 14:52:57 .. An implementation that gave a true/false or even a count of tts:bpd instances in the input 14:53:04 .. document instance would work for me. 14:53:24 Glenn: Another example: One type of transformation is the identity transformation. In our 14:53:38 .. case outputting the same document as was input, say, but stripping out all foreign 14:53:52 .. vocabulary, would be an example. Another would be, instead of counting #bpds, conut 14:53:57 s/conut/count 14:54:10 .. validities or invalidities, otherwise have no output. 14:54:22 .. We discussed this with TTML1 and tried not to define any transformation processing 14:54:34 .. output so it would be open-ended, which leads a lot of latitude. 14:54:50 Nigel: Yes, and I'm happy with any of the above, to answer your question Glenn. 14:54:58 tm has joined #tt 14:55:15 Pierre: There's an XML schema defined - would a schema transformation fall into that 14:55:17 .. category? 14:55:23 Nigel: What do you mean by a schema transformation? 14:55:30 Pierre: Like schema validation. 14:55:43 Glenn: I think if you have a shell script that runs a schema validation tool that uses as its 14:55:53 .. input a TTML2 document and the set of official schemas that we publish along with the 14:56:05 .. spec, even though they're not normative, would that satisfy the definition of a transformation 14:56:21 .. processor, the output of which is "yes it passes the schemas" or "no it does not"? I think 14:56:30 .. that's a reasonable transformation processor in our terms. 14:56:34 Nigel: I'd be happy with that. 14:57:10 .. Hopefully that's clarified the minimum requirements for a transformation processor. 14:57:26 .. Moving to the second part, what would I be happy to present to the Director as 14:57:30 .. being independent implementations? 14:57:53 .. My take on this is that the most valuable interpretation of the Process here is that the 14:58:08 .. implementations are produced either by two separate organisations, or, if they're 14:58:21 .. produced by the same organisation, that any queries regarding implementation were 14:58:27 .. dealt with in the scope of the WG. 14:58:49 .. Certainly I would not expect them to share code in general, but of course almost every 14:59:08 .. piece of software written in any one language shares some code with any other code 14:59:23 .. written in the same language, so at some point in the stack that can't always be true. 15:01:54 .. Pierre, does that clarify your query for raising this? 15:02:10 Pierre: Yes, I think so. Let's take a concrete example - #letterSpacing. If the two implementatinos 15:02:28 .. were a) TTPE and b) a script that runs the XML Schemas against all the valid and invalid 15:02:34 .. tests, that would be sufficient in your mind? 15:03:10 Nigel: Yes, because although as it happens Glenn mainly wrote the schemas and also 15:03:25 .. wrote TTPE, the schema work came via the WG and the implementation code executing 15:03:44 .. those schemas would be independent also. So I'd be happy to describe those as 15:03:46 .. independent. 15:04:05 Pierre: Okay, so, Thierry, any thoughts on this, reactions? 15:04:12 Thierry: No, I think that's how we should proceed. 15:04:25 Pierre: This has the potential of really saving an awful lot of time but I think it would be 15:04:38 .. really good to confirm with the Director that this would be acceptable before Oct 4. 15:04:47 Thierry: That's what transition requests are about. 15:05:05 Pierre: If this doesn't work, we don't have time to come up with an alternative. Is it 15:05:13 .. possible to check a priori if this is a valid approach? 15:05:53 Glenn: We can't have 2 transition requests. 15:06:04 Nigel: We can do something here, which is to inform the Director that this is our minimum 15:06:26 .. baseline for meeting the CR exit criteria and point out the time constraints, and offer him 15:06:38 .. the opportunity to tell us up front if that seems problematic with him. 15:06:48 Cyril: I approve of this approach to check we are going in the right direction. 15:07:01 Nigel: Thierry, is this best coming from you or me? 15:07:06 Thierry: I would prefer the Chair to do it. 15:07:10 Glenn: That was going to be my suggestion. 15:07:17 Nigel: Okay, I'll take that as an action. 15:07:52 .. I'll send it to an appropriately small group of people. 15:08:10 Glenn: By the way, getting the Director's approval in that regard, or giving them a chance 15:08:24 .. to input, doesn't mean that during the PR process we will not receive objections from 15:08:33 .. members about that process, so that's always a risk that we have to face. 15:08:36 Nigel: Good point. 15:09:00 Glenn: Before we go to the issues, I have a separate comment. 15:09:10 .. I have been describing the validation portion of the test suite in a particular way in terms 15:09:22 .. of what I believe it means to pass the test suite. I want to mention that and see what 15:09:33 .. the group thinks. I've been describing that if the implementation does not report a false 15:10:04 .. negative for any of the valid tests then it passes the test suite. So if it does not 15:10:22 .. produce an error for any of the invalid tests then it could still pass. We do not set a bar 15:10:40 .. for invalidity, but we have a note that not every implementation of a validator need 15:10:58 .. detect all potential invalidities. We can not force a validation implementation to check 15:11:21 .. every invalidity. It happens that TTV does detect and report every invalidity. Similarly it 15:11:33 .. does not report any errors in the valid tests. But another implementation will very likely 15:11:47 .. not detect all invalidities because the schemas are overly broad, for example they use 15:11:59 .. xs:string for complex types. The schemas by themselves as we publish them will not 15:12:13 .. detect all of the things that we call invalid. I want to check we have consensus on that 15:12:22 .. interpretation, somewhat separate from the previous conversation. 15:12:34 Pierre: It is related, because it means schema validation will not report some of the 15:12:39 .. invalid files as invalid. 15:12:52 Glenn: If we're reporting it as a transformation processor and are relying on TTV to satisfy 15:13:03 .. the requirement for a validation processor then we don't need to rely on those for 15:13:14 .. validation tests because the way the exit criteria are written the validation semantics 15:13:19 .. can be reported for either of the implementations. 15:13:34 Pierre: Right, what you're saying is that for the purpose of transformation processing 15:13:48 .. we can only run the schemas against the valid tests. 15:14:11 Glenn: Yes, or you could run them only on the presentation tests or only on the IMSC 1.1 tests. 15:14:25 Nigel: That (IMSC 1.1 test) wouldn't quite work, we need to get coverage of all the features. 15:14:48 Glenn: Right, if you ran it against all of the valid tests under the validation test suites and 15:14:59 .. all of the valid presentation tests then that would cover all the features. 15:15:02 Nigel: Sounds reasonable. 15:15:19 .. I don't think there's any harm in running against the invalid tests either - noting that 15:15:26 .. the output is not scrutinised in detail. 15:15:29 Glenn: I agree. 15:15:50 Nigel: That's right, it would count as transformation but not necessarily validation. 15:16:27 .. Playing with ideas about tranformation processors, you could write an XQuery that 15:16:37 .. outputs the locations of all the syntax referenced by a feature. 15:16:54 Glenn: Some of those are maybe challenging if they involve non-local context. 15:16:59 Nigel: That's true. 15:18:11 Nigel: Back to your question Glenn, I've not heard any objection to your definition of "pass" 15:18:25 .. when it comes to validation, but thank you for highlighting it - if anyone wants to comment 15:18:39 .. on this offline then please feel free to raise it on the reflector. 15:18:57 Glenn: Just for the record, ยง5.3.1.2 in the current spec has a note that I was referring to. 15:19:15 .. It sets the expectations about detecting invalidities and reporting false positives. 15:19:52 Topic: Clarify text combination semantics in a ruby container context (#978). ttml2#979 15:19:57 github: https://github.com/w3c/ttml2/pull/979 15:20:16 Glenn: For this item, when I was ingesting the IMSC 1.1 tests into the TTML2 test suite 15:20:37 .. I ran across a case when tts:textCombine was used inside a ruby context, in the base, 15:20:51 .. which apparently IMSC.js maps to CSS and one implementation, Firefox, does something 15:21:02 .. sensible with that. However nowhere in TTML2 did we mention the use of textCombine 15:21:18 .. in a ruby context or vice versa - not in textCombine or ruby sections. In CSS's own 15:21:31 .. version of text-combine and ruby you will not find it there either. My contention is that 15:21:45 .. that usage is not defined in TTML2. Certainly I did not consider it when I wrote those 15:21:59 .. sections. I had no use case for it at that time. I want to add an informative note in this PR 15:22:14 .. that this usage is not defined in this edition. We can't add normative text. I want to ward 15:22:27 .. off readers interpreting the current lack of language as carte blanche for using that and 15:22:43 .. expecting some output that works like Firefox. However Pierre thinks we shouldn't do 15:22:58 .. anything at this time. That is an option. I stand by the content of the note, factually. 15:23:33 Nigel: I haven't caught up with this yet and don't have a view. 15:24:04 Glenn: In the pull request it is an editorial change, by the way. 15:24:39 Pierre: I think in fact the semantics are defined today. 15:24:45 Glenn: We have a factual dispute over this. 15:24:57 Pierre: That's one point of dispute. Another is that the specific example used in the IMSC 1.1 15:25:09 .. test suite actually came from an implementor of Japanese subtitle and caption products 15:25:25 .. so it might be a used test case. Another data point is that this really deserves more 15:25:41 .. discussions and we don't have that time so I'm not objecting to that issue being resolved 15:25:50 .. at some point but I am objecting to trying to solve it before PR. 15:26:15 .. The note proposed is misleading because I think it is well defined. It is implemented in 15:26:22 .. at least one implementation, for what its worth. 15:26:42 Glenn: I assert that it is not defined. Others opinions can be various. I assert that it is not 15:26:54 .. defined in CSS either. The fact that one implementation has done something does not 15:27:08 .. mean that it is sanctioned by CSS. It is not supported by Safari or Chrome, I haven't tested 15:27:22 .. with Edge. The intent of the note was not to resolve the larger issue of how to define it 15:27:34 .. semantically. I agree that needs further treatment and it is not appropriate to address that 15:27:47 .. at this time. There's nothing wrong with putting a note in that is informative to say it 15:28:04 .. is not sufficiently well defined. In fact it is implementation dependent. I view this as almost 15:28:23 .. the same as putting extent or origin on p or div. Some implementers chose to read between 15:28:41 .. the lines and implement some interpretation. We pointed out it was undefined by the spec. 15:29:04 .. I view this as in exactly the same category. The syntactic possibility does not imply that 15:29:08 .. we have defined it. 15:29:23 Pierre: It is different because in that case it was clear that extent and origin do not apply 15:29:45 .. to div and p. In this case the two things are independent. For example nowhere does it 15:29:58 .. say that italics are allowed in a base, but that's correct I guess. 15:30:51 Nigel: I'm hearing two views: 15:30:55 .. 1. Do not add the note. 15:31:01 .. 2. We should add the note but it's okay not to. 15:31:06 .. In that case we should not add the note. 15:31:19 Glenn: Okay, I can accept that, but may say I told you so later. 15:31:39 Pierre: I think we should record this on a thread and allow implementers to work out what 15:31:43 .. to do based on that discussion. 15:32:04 Glenn: I pointed out an inconsistency with rubyAlign. 15:32:19 Pierre: Right, so that issue will not be resolved so an implementer can see it. 15:32:25 Glenn: I will close it and mark as TTML.next. 15:32:36 Pierre: I don't agree with that. It should remain open so implementers can look at the 15:32:50 .. open issues and see that and decide to get involved or tread carefully. I think we should 15:33:00 .. keep it open and change the milestone to 2nd Ed. 15:33:18 Glenn: I have avoided doing that. It's my intention, as soon as we have published 1st Ed, 15:33:25 .. to resurrect those issues and mark them as 2nd Ed. 15:33:40 Pierre: I move that we open them and set the milestone. I think it was wrong to do that. 15:33:45 .. You don't close issues in backlog. 15:33:55 Glenn: That's what we've done. It's a process that works for me. 15:34:07 Pierre: Yes but it doesn't encourage people to get involved or warn implementers. 15:34:22 Glenn: I want to avoid giving the impression that there are unresolved 1st Ed issues. 15:34:32 Pierre: That's why there's a milestone. That's how bug trackers work. 15:35:24 Nigel: I support the proposal to open them. We can use milestones for filtering and I am 15:35:39 .. not concerned about revealing open issues to the Director when they're appropriately 15:35:42 .. labelled with a milestone. 15:36:04 Glenn: Okay I can do that, I will reopen all the issues marked ttml.next and assign them 15:36:11 .. to a 2nd ed milestone which I will create. 15:36:15 .. It doesn't exist yet. 15:36:25 .. I'll mark this issue as 2nd Ed and close the pull request without merging. 15:36:45 Pierre: There are 2 distinct milestones, TTML2 vnext and 2nd Ed. 15:36:50 Glenn: They're the same in my view. 15:37:09 Pierre: It's fair sometimes to set no milestone for backlog issues, in other cases we as a 15:37:20 .. group can have scheduled them for a particular edition. 15:37:48 Nigel: I think that will work, taking the point that we could be more precise about the 15:37:59 .. target for resolution. 15:38:22 .. I think I've identified consensus to close this pull request and move the issue to 2nd Ed. 15:38:25 .. Any objections? 15:38:32 group: [silence] 15:38:48 RESOLUTION: Close this pull request without merging, and move the issue to 2nd Edition milestone. 15:39:20 Topic: Remove #textOrientation-sideways-LR and related semantics (#980). ttml2#981 15:39:26 github: https://github.com/w3c/ttml2/pull/981 15:40:14 Glenn: Summary here is that sideways-left is not well defined and problematic because 15:40:27 .. in our top to bottom inline progression direction vertical writing directions, if you turn 15:40:40 .. English text on the side to the left, then the first letter of the sentence appears at the 15:40:55 .. bottom of the screen and proceeds from bottom to top. The alternative is to do them 15:41:07 .. top to bottom and have a partial mirror image of the text vertically, which would be 15:41:40 .. hard to read. When I reviewed CSS writing modes level 3 and UTR50 the conclusion I 15:41:53 .. reached is that sideways-left is not well defined. I could implement it but it wouldn't 15:42:08 .. make any sense and it would be a waste of effort. If I implemented it so it starts at the 15:42:25 .. bottom and goes to the top then it contradicts the writing mode definition, without 15:42:40 .. introducing a new bottom to top writing mode. This is marked as at risk so my response 15:43:00 .. is to remove this and improve the consistency with CSS. It's substantive because it takes 15:43:15 .. out both sideways-left and sideways-right, leaving mixed, upright and sideways, where 15:43:32 .. sideways always means clockwise, which matches CSS. If we are going to make this 15:43:46 .. substantive change we have to do it under the rubrick of changing or removing an at 15:43:53 .. risk feature. I need someone to review it. 15:44:13 .. TTPE is not going to implement it so at the end we will end up with a red box in the 15:44:16 .. implementation matrix. 15:45:16 Nigel: Thank you for raising this, and for inviting @r12a to review it. I'd be interested to 15:45:19 .. hear his comments. 15:45:28 .. I can't recall how this got in to our spec. 15:45:51 Glenn: It was in a previous version of a CSS spec but was removed, probably because it 15:46:01 .. doesn't make any sense for top to bottom layout. 15:46:13 Pierre: Digital Cinema implementations support left and right rotation, but that does not 15:46:24 .. mean it is used. I'm not objecting to the removal, just adding a data point as to why we 15:46:31 .. may have ended up with this. 15:46:42 Glenn: That's fired a neuron in my mind, so it's probably the case. 15:47:14 Nigel: I see Pierre just approved it. We have time to let this pull request run its course in 15:47:21 .. terms of review so I suggest we allow that. 15:47:38 SUMMARY: Pull request review to continue. 15:47:46 github-bot, end topic 15:48:03 rrsagent, make minutes 15:48:03 I have made the request to generate https://www.w3.org/2018/08/30-tt-minutes.html nigel 15:49:37 Topic: IMSC rh and rw units 15:49:50 Pierre: Raising awareness that we have to make progress on this. The feature is a mix-in 15:50:03 .. in TTML2, so by permitting it in IMSC 1.1 we've permitted it everywhere, which has 15:50:21 .. surprised some folks. Since Nigel and Cyril were the proponents I'd like your view on 15:50:33 .. where it is really useful. It is an at risk feature in the CR so we have the opportunity to 15:50:37 .. make changes. 15:51:08 github: https://github.com/w3c/imsc-tests/issues/77 15:51:28 tmichel__ has joined #tt 15:51:30 Pierre: #77 itself can be fixed by removing the test because the test is invalid per the spec. 15:51:45 .. This brings up the bigger issue of what rw and rh should apply to. I had an action to 15:52:00 .. raise an issue, but I need Nigel's and Cyril's input about what they are useful for, then 15:52:12 .. I can raise the issue. I wouldn't be surprised if others have an opinion, but this would be 15:52:15 .. a good place to start. 15:52:28 Cyril: I think I explained our use case which was related to anamorphic fonts. 15:52:31 Pierre: That helps. 15:52:49 Cyril: We have found a workaround to using anamorphic fonts in IMSC so I don't think 15:52:54 .. we need rw and rh any more. 15:52:56 Nigel: Not at all? 15:53:00 Cyril: Not at all. 15:53:22 Nigel: I think I also stated the main motivation, which was to avoid the confusion seen in 15:53:39 .. real world scenarios when specifying font size, by allowing an "absolute relative" size 15:53:59 .. to be defined, i.e. rw or rh. There are implications there about which lengths would 15:54:15 .. need to support those units, but I'm not averse to constraining their use to make 15:54:22 .. implementation more straightforward. 15:54:39 .. I think the big question is if rw units are needed in vertical contexts and rh units in 15:54:59 .. horizontal contexts, and I don't have any concrete examples where they would be needed. 15:55:22 .. However for vertical writing modes, it would make sense to use rw units for font size. 15:55:50 .. I sense that it might add complexity though, rather than removing it! 15:55:57 Pierre: It's implemented completely in imsc.js. 15:56:13 Glenn: TTPE supports use of rw and rh in any context that supports that length. 15:56:40 Nigel: Okay, it's at risk but also implemented twice. Why do we need an issue for it? 15:57:07 Pierre: tts:position specifically allows rw and rh but ... [checks the spec] 15:57:17 .. ... tts:origin does not allow it. 15:57:20 Nigel: That's right. 15:57:31 Pierre: So it's weird but not fatal. 15:57:55 .. Basically, rw and rh are allowed everywhere but origin, and a few other exceptions like 15:58:18 .. ebutts:linePadding. Anyway it's weird but... 15:58:25 Nigel: It seems like no action is needed? 15:58:38 Pierre: We could add an issue in the backlog to say root container relative units are not 15:59:20 .. permitted on origin. 15:59:47 Nigel: I think that's correct and as it should be, because origin and position are not both 16:00:31 .. permitted, and if someone wants to use origin for backwards compatibility then allowing 16:00:42 .. rw and rh units on them would be even more weird. I think no change is needed. 16:01:17 Pierre: The other thing we probably want to do, under position, if you use rh in a horizontal 16:01:46 .. context you can get root container regions that are too big. That we could specifically 16:01:58 .. prohibit in tts:position to avoid people getting into trouble. Or note that if they do that 16:02:06 .. then they better set aspect ratio. 16:02:17 Nigel: I agree that's a practical issue that we should raise. 16:02:39 Pierre: It applies to extent also. 16:03:22 Nigel: Yes it's worth warning about. We already prohibit regions outside the root container region. 16:03:35 Pierre: The question is if we should syntactically prohibit it. 16:03:41 Nigel: Yes that's an issue to raise. 16:03:52 Pierre: Thanks for working through that, I'll raise it as a real issue. 16:03:56 Nigel: Great, thank you. 16:04:21 SUMMARY: Raise an issue about syntactic prohibition of rw and rh on extent and position 16:04:25 github-bot, end topic 16:04:25 tmichel has joined #tt 16:04:57 Topic: Meeting close 16:05:10 Nigel: Thanks for your time today everyone. [adjourns meeting] 16:05:44 .. Postscript: I forgot to thank Thierry for getting the updated CRs published since the 16:05:48 .. last meeting. Thank you Thierry! 16:05:52 rrsagent, make minutes 16:05:52 I have made the request to generate https://www.w3.org/2018/08/30-tt-minutes.html nigel 16:13:14 s/github-bot, end topic//g 16:15:39 s/in that vain/in that vein 16:24:59 Zakim has left #tt 16:38:41 rrsagent, make minutes 16:38:41 I have made the request to generate https://www.w3.org/2018/08/30-tt-minutes.html nigel 16:39:56 s|s/in that vain/in that vein|| 16:40:05 s/In that vain/In that vein 16:40:09 rrsagent, make minutes 16:40:09 I have made the request to generate https://www.w3.org/2018/08/30-tt-minutes.html nigel 16:40:35 scribeOptions: -final -noEmbedDiagnostics 16:40:37 rrsagent, make minutes 16:40:37 I have made the request to generate https://www.w3.org/2018/08/30-tt-minutes.html nigel 16:49:55 nigel has changed the topic to: TTWG meetings Thursdays 1400 UTC. Minutes for most recent meeting: https://www.w3.org/2018/08/30-tt-minutes.html Agenda for the next call will be issued on Tuesday.