14:01:14 RRSAgent has joined #tt 14:01:14 logging to https://www.w3.org/2018/05/31-tt-irc 14:01:16 RRSAgent, make logs public 14:01:16 Zakim has joined #tt 14:01:18 Meeting: Timed Text Working Group Teleconference 14:01:18 Date: 31 May 2018 14:01:24 Log: https://www.w3.org/2018/05/31-tt-irc 14:02:09 Present: Nigel, Glenn, Cyril 14:02:15 Regrets: Pierre, Andreas, Thierry 14:02:21 Chair: Nigel 14:02:25 scribe: nigel 14:02:29 Topic: This Meeting 14:02:44 Glenn: The main thing I want to do today is review #794 with a view to merging early. 14:03:41 Nigel: Today we have some regrets, so let's make what progress we can. 14:04:02 .. On the agenda is TTWG Charter, TTML2, and I'm not sure what else we can cover. 14:04:19 .. Aside from #794 is there anything else you'd like to make sure we look at, or any other 14:04:20 .. business? 14:04:31 Glenn: #770. 14:04:32 Nigel: OK 14:04:49 Glenn: In the remainder of the time I'd like to go over the ones ready to go pending 14:05:00 .. approval of recent updates to address comments, that are marked as pending re-review 14:05:23 .. in the pull request list for TTML2. There are a couple of older ones with Nigel's name on 14:05:27 .. that maybe we can do in realtime. 14:05:30 Nigel: OK 14:05:49 Glenn: #703 and #755 I think. 14:06:06 Cyril: Nothing more from me. 14:06:11 Topic: TTWG Charter 14:06:22 Nigel: Just to note for the minutes we are now operating under a new Charter: 14:06:38 -> https://www.w3.org/2018/05/timed-text-charter.html TTWG Charter 2018 14:06:50 Nigel: Thanks everyone for contributing to that and working on it. 14:06:53 Glenn: When does it go to? 14:06:57 Nigel: 31 May 2020. 14:07:33 .. One other thing for the notes only given the attendees today: there's no change in scope 14:07:56 .. so any invited experts should _not_ be ejected and need to request re-invitation. If that 14:08:01 .. does happen please let me know ASAP. 14:08:41 Topic: Clean up and refactor features (#688, #763, #789, #790, #791, #792, #… ttml2#794 14:08:46 github: https://github.com/w3c/ttml2/pull/794 14:09:20 Glenn: Summarising the changes, there were some comments on how to factor the condition 14:09:35 .. features and I adopted as you suggested, pretty much exactly, and also for the rubyAlign-withBase 14:09:48 .. I adopted your proposal. On the animate you had a question about if animate covers 14:10:00 .. everything, and it was ambiguous to me as well. In a previous meeting we had discussed 14:10:13 .. animate-related features and I said I would do some work to tie it to the calculation mode 14:10:25 .. and that discrete and linear would be in the minimal features, and paced and spline would 14:10:36 .. be separate features. I refactored animate to do that and to make sure that the animate 14:11:02 .. feature did include those things. I took out the `#animate-calcMode`, `#animate-keySplines` 14:11:36 .. and `#animate-calcMode` and added `#animate-minimal` which includes discrete 14:11:55 .. and linear calc modes and by virtue of that implies support for keyTimes attribute. 14:12:04 .. We don't need a separate feature for keyTimes since it is in the minimal set. 14:12:25 .. The second thing I added was `#animate-paced` for paced mode. 14:12:44 .. And I added `#animate-spline` which implies supporting the keySpline attribute. 14:13:01 .. I redefined the `#animate` feature to include all those features plus `#animate-fill` and `#animate-repeat`. 14:13:13 .. In my mind at this point animate is all wrapped up and doesn't make use of any negative 14:13:16 .. definitions. 14:13:40 .. And then the final comment is you had expected language about processor profiles and 14:13:55 .. I commented that it doesn't work because there's no such thing as prohibiting a feature 14:14:07 .. in a processor profile. If you don't require support then it is optional. If you require some 14:14:21 .. superset of a set of features then it implies that all are present, and making them optional 14:14:34 .. does not take them out so to speak. So there's no need to add something for processor 14:14:37 .. profiles by my reading. 14:15:01 .. I have a set of pulls stacked up pending this and Pierre suggested that we merge it ASAP. 14:15:07 .. So I need it to go out quickly. 14:15:27 Nigel: Thank you for that, good summary, it's substantive, and 8 days old. 14:15:48 Nigel: [looks at the changes] 14:16:26 Nigel: Did you fix `#display-version-2` too? 14:16:35 Glenn: Yes, and I spotted and fixed a typo in one of the links too. 14:16:39 Nigel: Thank you! 14:17:20 Nigel: I have some concerns about merging early, because of the nature of the changes, 14:17:27 .. but it's reasonable to ask in the circumstances. 14:17:43 Cyril: I'm fine with it since it is early but not very early. It's been more than a week. 14:19:09 Nigel: There's a lot to review here - I'm happy in principle with what you've described but 14:20:00 .. need to look at the detail - if we can close the call early today then I will complete that 14:20:02 glenn has joined #tt 14:20:08 .. review, but don't foresee any problems. 14:20:49 SUMMARY: @nigelmegitt to complete review and add updated review status 14:21:21 Topic: Add features for standard and high dynamic range PNG images (#694, #6… ttml2#770 14:21:28 github: https://github.com/w3c/ttml2/pull/770 14:21:53 Glenn: The only outstanding piece on this is the reference. My opinion is we should make 14:22:08 .. a normative ref to the WG Note. Given the loosening of policies from HTML5 I'm pretty 14:22:24 .. sure that it is no longer a no-no. We can't define an HDR feature unless we can point 14:22:40 .. to a normative reference to a format. There's no generic format. We either put it in with 14:23:00 .. the WG Note as a normative ref or we don't include any HDR PNG feature. 14:23:25 Nigel: Ok, @plhegar didn't get back to me. 14:23:39 Glenn: It's been more than 14 days and we have @nigelmegitt's approval but nothing from 14:23:53 .. Pierre or Mike. Since this is still hanging I didn't want to merge it without group input. 14:25:34 Nigel: This is also related to a separate issue that I am not up to date on where I began 14:25:46 .. working on a pull request and realised that we probably do not want luminanceGain 14:26:21 .. to apply to PQ HDR image at all. 14:26:37 Glenn: It sounds like we can't resolve this until that's worked through. 14:26:39 Nigel: +1 14:27:28 Nigel: I've dismissed my review. 14:27:45 Glenn: Does IMSC 1.1 use this? 14:27:51 Nigel: IMSC 1.1 will need to be updated too. 14:31:22 Glenn: Is it really orthogonal? 14:32:23 Nigel: The impact comes from the comment you made Glenn about testing luminanceGain 14:32:33 .. without supporting PQ PNG images. 14:32:53 .. (also there's no way to make luminanceGain have no effect, i.e. be unity, where it is known 14:33:06 .. that images generate PQ pixels already). 14:33:29 Glenn: If we don't resolve this soon then there's a risk of needing a CR3 which I'm wary of 14:33:35 .. because of the time implications. 14:33:49 Nigel: Yes me too, I hope to be able to process this by the end of tomorrow so we can progress. 14:35:14 Nigel: Back to this particular topic, I think we may not need the png pq hdr feature at all, 14:35:35 .. though we might need a processor feature that can support identification of pq pixels 14:35:48 .. output from image processing, as defined by the ITU spec. That would get around the 14:37:04 .. need to reference the WG Note. 14:38:20 SUMMARY: Resolve #796 and then revisit this based on the conclusion to that issue. 14:39:05 Topic: Remove @style from animate and set (#703). ttml2#707 14:39:14 github: https://github.com/w3c/ttml2/pull/707 14:39:31 Glenn: Nigel you asked for minimum two values in an animation-value-list and I did that. 14:39:38 .. I changed the * to a + in the syntax. 14:41:11 Nigel: Great, and I see that I made a later comment that if you do that then it would be 14:41:25 .. consistent to complete the resolution of the issue by removing @style from the animate element. 14:41:31 .. Did you do that as part of #707? 14:41:36 Glenn: I did it in the schemas... 14:41:43 .. Yes, it's been removed from both set and animate. 14:42:19 Nigel: Looks good to me, I'll approve the pull request. 14:43:18 SUMMARY: Discussed and agreed. 14:43:21 github-bot, end topic 14:43:47 Topic: Describe generically compliant processors that support only external … ttml2#755 14:43:53 github: https://github.com/w3c/ttml2/pull/755 14:44:45 Glenn: It's tricky - in some places we have to use TTML without qualification and in others 14:44:52 .. it is relevant to qualify as TTML2. 14:44:54 Nigel: Yes! 14:46:11 .. I need a bit of offline time to check through that but I think it's fine. 14:46:23 SUMMARY: Review to continue offline 14:46:27 github-bot, end topic 14:46:58 Topic: Exclude vertical length offset as 1st component in 2 component positi… ttml2#769 14:47:03 github: https://github.com/w3c/ttml2/pull/769 14:47:36 Glenn: I made a change in the syntax as Pierre suggested. 14:53:08 .. Either we need to dismiss his review or wait on him for a few days. I'm willing to wait. 14:53:21 Nigel: I assume he'll do that, and that seems like the right approach. 14:53:47 Glenn: Basically the change was to match the CSS exclusions to syntactical combinations, 14:53:54 .. by not allowing the excluded syntax at all. 14:53:58 Nigel: Makes sense to me. 14:54:26 SUMMARY: DIscussed in WG meeting, review to continue offline 14:54:29 github-bot, end topic 14:54:47 Topic: Add explicit exceptions to ignoring element semantics with condition … ttml2#772 14:54:51 github: https://github.com/w3c/ttml2/pull/772 14:54:59 Glenn: I just did a commit last night to address comments. 14:55:14 .. Nigel you pointed out that the use of content element wasn't sufficiently inclusive and 14:55:25 .. suggested that we bring in all timed elements including region, so I introduced the 14:55:38 .. term timed element. I had to review all the candidates for timed elements and decide 14:55:54 .. what the distinguishing features were. I first thought timeContainer, but animate and set 14:56:03 .. have begin and end but not timeContainer, since they don't have timed children. 14:56:20 .. On the other hand everything had a begin, dur and end and I picked begin as a criterion. 14:56:31 .. Then I changed content element ref to timed element so that should address your last 14:56:36 .. comment and this should be ready to go. 14:56:40 Nigel: Sounds good to me. 14:57:06 Glenn: This just needs an approval - we've already passed 14 days on this one. 14:57:56 Nigel: OK, interesting we don't have a class that corresponds to these. 14:58:11 Glenn: Not in the spec - in TTV we have an IsTimedElement that does that, so implementations 14:58:22 .. have to do it. I'm loathe to add another class just for this purpose. A definition should 14:58:23 .. suffice. 14:59:42 Nigel: Okay, I'll review. 14:59:48 .. There are 16 uses of "timed element" in the spec. 14:59:54 Glenn: I just noticed that, I'll update to add links to it. 15:00:30 Nigel: Since we refer to this before, was it deemed to be an obvious concept or did we 15:00:33 .. inherit it from SMIL? 15:00:45 Glenn: I don't recall inheriting it from SMIL, but our usage would be different anyway. 15:00:52 Cyril: Timed Element is a concept in SMIL I think. 15:01:05 Glenn: It could be but the glossary section is very weak. In any case now that we have 15:01:16 .. introduced timed element we should link those 16 places back to the definition now that 15:01:19 .. we've added a term. 15:01:20 Nigel: +1 15:02:08 Nigel: Notices we should take care with 12.4 15:02:34 Glenn: Yes 15:02:41 Nigel: Aside from that, I think this looks good. 15:03:00 SUMMARY: @skynavga to update to include references to the timed element term, then review to continue. 15:03:02 github-bot, end topic 15:03:26 Topic: Clarify distinction between validation processing, validation process… ttml2#777 15:03:31 github: https://github.com/w3c/ttml2/pull/777 15:03:50 Glenn: I did a commit last night in which I think I addressed Nigel's comments. 15:03:53 https://github.com/w3c/ttml2/pull/777/commits/4aaf65d902fc70f374e31751074a18d26389f6f2 15:04:57 Nigel: [reviews in real time] Looks good to me. 15:05:28 .. I've approved. 15:05:44 SUMMARY: Pull request satisfies merge requirements. 15:06:04 Topic: Collapse language for style application to paragraph text nodes; add … ttml2#803 15:06:10 github: https://github.com/w3c/ttml2/pull/803 15:06:39 Glenn: I added a comment to this. 15:09:17 Cyril: Can we add a link from the sentence in 8.1.5 to the process for creating anonymous spans? 15:09:33 Glenn: Yes, and come to think of it we should add the same text to the span element to 15:09:37 .. make it complete. Right now it is incomplete. 15:10:31 Cyril: I don't want it to look like there's a separate procedure. 15:10:41 Glenn: That gives me a tbd on this before you sign off on it Nigel 15:10:44 Nigel: OK 15:12:31 .. Should we add a note pointing the reader to anonymous spans beneath the new text? 15:12:56 Glenn: I don't want another place where we paraphrase what the construct anonymous span 15:12:58 .. procedure does. 15:13:07 Nigel: I was thinking of a note with a reference, but I take your point. 15:13:36 Glenn: The terms anonymous span and span already take you to the right definitions. 15:13:54 Nigel: Yes, if you add that anonymous span text from p to span then yes, I'm okay with that. 15:14:43 SUMMARY: Duplicate anonymous span text from p element into span element (for @skynavga) and reference the [create anonymous span] procedure from both. 15:15:02 Topic: Add xml:base to core vocabulary (#804). ttml2#808 15:15:07 github: https://github.com/w3c/ttml2/pull/808 15:15:27 Glenn: This adds `xml:base`. Previously in TTML1 the `features` and `extensions` elements 15:15:41 .. admitted `xml:base` and those were unusual in that we defined a default value in the 15:16:01 .. element information item that specifies using the TTML feature namespace and the extensions 15:16:17 .. namespace respectively. Those were kind of special uses that had a default. 15:16:29 .. This PR and issue is for, now that we have URLs in a variety of other places such as 15:16:51 .. xlink:href and the source element and audio, data and image, we potentially have some 15:17:14 .. uses that are related to the media query support in the condition function for media functions, 15:17:41 .. my conclusion was we need to add `xml:base` to the core attributes list so it is everywhere. 15:18:00 .. Now `xml:base` is hierarchical so you can have multiple relative levels. It can build up 15:18:17 .. hierarchically from the most nested reference to the root level element. You need to 15:18:31 .. populate it everywhere (ability to populate). 15:18:49 .. Especially if you're embedding content that has some URLs in it you might nest that in 15:19:05 .. another document and put a relative base on it at the highest level node. It turns out to 15:19:14 .. be quite useful and is supported in SVG and SMIL as well. 15:19:50 Nigel: Did you fix Cyril's issue about isd:css and isd:region too? 15:20:03 Glenn: Yes. I know Cyril had suggested just supporting on the root level but as you see that 15:20:06 .. won't quite work. 15:20:20 Cyril: I understand the feature, I don't think it's a priority. You could default it to the base 15:20:24 .. of the document itself. 15:20:42 Glenn: That is the default default if there are relative URLs in the document with no xml:base specified. 15:20:48 .. We don't have to say anything to support that. 15:21:02 Cyril: I don't have a strong preference. It's mainly useful for images and audio content right? 15:21:07 Glenn: Exactly. 15:21:51 Nigel: I don't have strong view either, but don't have a particular use case. I don't think it 15:21:58 .. is especially harmful. Is there a profile feature for it? 15:22:09 Cyril: There is #base and #base-version-2 15:22:12 Nigel: Ok 15:22:13 https://rawgit.com/w3c/ttml2/0c93c4dfa88e85a61d1c2cf1bae9a530c1e7e25c/index.html 15:22:27 Glenn: I defined it that way because we already had base in TTML1 but with no feature so 15:22:40 .. I defined in TTML2 a feature that mapped to the original TTML1 support for base and then 15:22:45 .. extended it with the version-2. 15:22:49 Nigel: Makes sense. 15:23:29 Cyril: I think we should move on from this - it was opened yesterday. 15:23:42 .. Seems consistent, not harmful, we should approve if there's no objection. I would like 15:23:56 .. some input from the SMPTE image users to see if they have any views on this. 15:24:03 Glenn: Yes, I'm not asking for early merger on this. 15:24:14 SUMMARY: Offline review to continue. 15:24:16 github-bot, end topic 15:24:38 Topic: Add #unicodeBidi-version-2 feature designator (#679). ttml2#759 15:24:49 github: https://github.com/w3c/ttml2/pull/759 15:25:47 Glenn: Nigel you made a statement about this but did not approve. 15:25:58 Nigel: Yes, that was 2 weeks ago, pending a discussion of the approach to defining features 15:26:10 .. by reference to their TTML1 definition. We had that discussion and agreed to proceed 15:26:24 .. on that basis so I can now complete the review of this pull request. 15:27:50 .. [does a rescan] Looks good to me. 15:28:29 .. I've approved it. 15:28:54 SUMMARY: Pull request meets criteria for merging 15:29:13 Topic: Add and update element derivations (#380). ttml2#805 15:29:21 github: https://github.com/w3c/ttml2/pull/805 15:29:26 Glenn: I don't have any reviews on this yet. 15:29:39 Cyril: The reason I didn't review it is I don't really consider it necessary. There's no impact 15:29:43 .. if there's a bug in this one. 15:29:51 Glenn: Exactly, this is a non-normative appendix. 15:30:03 Cyril: I can approve it if you want but I thought Nigel was best placed to do it. 15:31:02 Nigel: I need more time to review this. 15:31:21 Glenn: That's fine with me - I just need a review. It's an editorial pull request that's only 2 15:31:30 .. days old, so there's a day to go minimally before merge anyway. 15:32:37 Nigel: OK I'll take a look. 15:32:44 SUMMARY: Offline review to continue 15:32:49 https://github.com/w3c/ttml2/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+milestone%3ACR2+-label%3A%22pr+open%22 15:32:49 github-bot, end topic 15:33:23 Topic: CR2 issues with no pr open label on them 15:33:29 -> https://github.com/w3c/ttml2/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+milestone%3ACR2+-label%3A%22pr+open%22 15:33:37 Glenn: I've marked a couple of them for agenda 15:34:31 Topic: Time containment semantics for smpte time base. ttml2#377 15:34:39 github: https://github.com/w3c/ttml2/issues/377 15:34:55 Glenn: Nigel, you're original complaint was that we prematurely deprecated the use of 15:35:16 .. the sequential time containment in smpte discontinuous mode and you have argued that 15:35:29 .. there is a potential interpretation of that. I argue that even if that is the case then it 15:35:38 .. doesn't make any sense to use it and it shouldn't be used anyway. 15:36:05 .. In my mind smpte discontinuous indicates that there is no time container at all. 15:36:18 Nigel: I don't think there's no time containment. 15:36:42 Glenn: For example if you have a span in a p and the span says begin=0s and the p says begin=10s 15:36:57 .. for me the 0s on the begin relates to the document timeline not to the p. 15:37:32 .. Any time you find a time in a smpte discontinuous document then it relates to the 15:37:58 .. document context. This is from markerMode. The problem with what you're suggesting 15:38:24 .. Nigel is that it backs out that. Under markerMode it says that time expressions must not 15:38:46 .. be calculated etc. in discontinuous mode. All time expressions are interpreted as time 15:39:01 .. events which cause a temporal interval to begin or end accordingly. 15:42:33 Nigel: I don't disagree with that but my point is that time expression calculation is orthogonal 15:44:18 .. to time containment, and that there is a logical processing model for sequential time 15:45:22 .. containment with smpte discontinuous, treating the time expressions as events. 15:45:39 .. I don't believe that there is any data presented to deprecate this potential usage. 15:45:56 Glenn: If we take out the deprecation, I don't really want to tweak this language or add 15:46:27 .. more language? 15:47:42 Nigel: I don't think we need to do anything particular to the spec and I wouldn't prioritise 15:48:08 .. this niche use case, just back out the deprecation. 15:48:12 Glenn: Is this editorial? 15:48:28 Nigel: Although we apparently did not have consensus for this when #647 was merged 15:48:44 .. in February, this is a substantive change relative to CR1 unfortunately. 15:48:55 Glenn: Okay I can accept backing out the deprecation, I may ask for early merge next week. 15:49:49 SUMMARY: Back out the deprecation of seq time containment in smpte discontinuous 15:50:31 Topic: Negative feature designators aren't future proof. ttml2#697 15:50:36 github: https://github.com/w3c/ttml2/issues/697 15:50:40 Nigel: I still have the action on this. 15:50:51 Glenn: To some extent #794 overtakes this because we are already backing out some 15:51:04 .. negative feature designations. I'm not sure if there are potential action items. 15:51:15 Nigel: Let me keep it and think further on this please. 15:52:14 .. The action on me is to demonstrate that there is a specific problem. 15:52:31 Glenn: The only remark I have is that one of the reasons we use the phrase "all defined values" 15:52:44 .. is that not all values are enumerable, e.g. floating point values, and the primary condition 15:52:58 .. expressions are infinite in their number of possibilities, so we can't enumerate every 15:53:01 .. value set. 15:53:09 Nigel: There are ways to group value sets finitely. 15:53:50 Glenn: In the condition refactoring, where you suggested using "non-function" expressions, 15:53:57 .. there probably isn't any other way to do it. 15:54:05 Nigel: Ok the action is still with me. 15:54:20 Glenn: My point is even if you think we'd like to do this I don't think we can completely 15:55:22 .. do what you're suggesting, in the case of some infinite value sets. 15:55:57 Topic: tts:rubyReserve length component semantics ttml2#779 15:56:02 github: https://github.com/w3c/ttml2/issues/779 15:56:17 Cyril: Glenn can you clarify that we harmonised rubyReserve with rubyPosition using 15:56:34 .. ``? Looking at the CR spec I couldn't find it. 15:56:50 Glenn: There's an optional length component in rubyReserve. 15:57:06 .. The set of keywords that are defined there are equal to or a subset of ``. 15:57:11 .. We took out around and between. 15:57:35 Cyril: Did we change the examples? 15:58:49 Nigel: [checks spec] There's no mismatch between the examples in rubyReserve and the syntax. 15:58:58 Cyril: OK, sorry, I was looking at the wrong version. 15:59:33 Glenn: The example does need to be updated - around and between have gone. 15:59:42 Nigel: Sorry, I also looked at the wrong version. 15:59:52 Glenn: It looks like I just need to remove the around and between examples. 16:00:11 Cyril: OK, now about the behaviour or ruby, line area and lineHeight. 16:00:27 .. You clarified that the rubyReserve area is parented to the line area. 16:00:30 Glenn: Correct. 16:00:48 Cyril: But I remember that the CSS WG said that you also had to set the line-height and that 16:00:59 .. ruby-reserve did not affect the line height. Is that the case in TTML2 as well? 16:01:10 Glenn: I avoided going into the details of this in the spec. 16:01:15 Cyril: so it's implementation specific? 16:01:18 Glenn: Yes. 16:01:25 Cyril: Why don't we do the same with rubyReserve? 16:01:41 Glenn: TTP for example increases the line height based on the concept that the definition 16:01:52 .. of normal under line height maps to the per inline height rectangle in XSL-FO and that 16:02:06 .. is defined in such a way as to increase the line height on the per line area basis based on 16:02:19 .. the glyph areas contained in that so that the ascender, descender and half leadings on 16:02:31 .. both sides of every glyph area are included in the line height for that particular line. 16:02:46 .. The height of individual areas in "normal" varies based on what is inside them. The model 16:03:04 .. there is to extend the line height to enclose the descendants. I use the same model, if 16:03:18 .. lineHeight="normal" (including default) it will increase the line height of a box that has 16:03:32 .. ruby to include the ruby annotation inline areas. I avoided writing this into the spec at 16:03:44 .. this point. One thing you are suggesting is that we add a note maybe that it is implementation 16:03:55 .. dependent what effect rubyReserve has on lineHeight? 16:04:06 Cyril: I'm not sure if that is what I am suggesting. I am trying to understand how it works. 16:04:19 .. If I cannot understand it probably other readers cannot understand how it works. 16:04:43 Glenn: Interestingly Pierre is just mapping to CSS and letting CSS do it. What I implemented 16:04:57 .. is basically compatible with that. CSS doesn't define those details. It's basically what is 16:05:10 .. implemented in the wild is the de facto standard. 16:05:17 .. It would take a lot of work to define those requirements. 16:05:32 Cyril: I'm fine with not specifying it and maybe in a future version doing that when we have 16:05:40 .. converged on a processing model. 16:05:58 .. Pierre is saying that the length field is over-specified? 16:06:04 Nigel: I think we need Pierre here for that. 16:06:18 Glenn: My interpretation is that he has some issue with how we define the default value 16:06:46 .. for length. 16:09:08 Glenn: We have the problem of length with lineHeight too, which is not dependent on font size either. 16:09:20 Nigel: OK so now we have the problem in two places! 16:09:38 .. Given the time and that this issue was raised by Pierre who is absent, we should not 16:09:41 .. continue with this issue. 16:09:46 github-bot, end topic 16:10:16 Topic: Use of maximum descendant font size in normal line height computation. ttml2#806 16:10:21 github: https://github.com/w3c/ttml2/issues/806 16:10:31 Glenn: I would like to spend 5 minutes on this for the record 16:10:44 .. The issue is lineHeight - what does "normal" mean? 16:11:00 .. We had some language in TTML1 that said the computed value is no less than the font 16:11:12 .. size that applies to the element and its descendant elements. When we recast that in TTML2 16:11:31 .. we inadvertently omitted mention of the descendant elements. 16:11:39 Nigel: No, we discussed it and decided that we didn't need it. 16:11:47 Glenn: Thanks for reminding me, I need to go back to the notes on that. 16:12:05 .. I decided to re-review the way that XSL-FO defines this, and the CSS semantics, and I 16:12:16 .. concluded that TTML1 semantics do not match CSS 2 or XSL-FO and TTML2 semantics 16:12:31 .. match none of them as defined. I marked this as a bug and something we need to deal with. 16:12:44 .. I was going to maybe today or tomorrow post a pull request to deal with this. The main 16:12:57 .. problem is that the current algorithm leads you to the conclusion that you can set a 16:13:12 .. uniform line height that is resolved from normal and that it applies to every line 16:13:24 .. irrespective of the inline areas on each line. In the XSL-FO language it says it should be 16:13:41 .. the minimum required to enclose the paragraph's requested line height and the line height 16:13:55 .. for each of the inline areas within the line area. In other words different line areas may 16:14:18 .. have different heights based on lineHeight="normal". The current text does not do what 16:14:23 .. CSS2 does or what XSL-FO says. 16:16:24 .. We're inconsistent. 16:16:39 Nigel: I recall Andreas making a presentation to us in a face to face meeting about this, 16:16:50 .. and pointing out that the line stacking strategy we use in TTML means that lines can 16:16:53 .. never overlap each other. 16:17:05 Glenn: I dispute that, and will have to go back and check. 16:17:27 .. "normal" is the most used value, and I'm pretty sure that the expectation would be the 16:17:37 .. same as in CSS, but that is not how it is specified now. 16:17:50 .. I don't know if say imsc.js would be able to do what the new language says. 16:19:45 Nigel: I would advocate looking for line stacking strategy and go back to where we discussed this before. 16:20:18 Glenn: In the case of "normal" you don't get bleed over between lines, but you might with a number. 16:20:33 Nigel: I thought the same line stacking strategy applies even with a number. 16:20:51 Glenn: If that's the case then XSL-FO would be inconsistent with CSS2. I would need to look at that. 16:22:07 Nigel: The line-stacking-strategy is line-height, regardless of the value of tts:lineHeight. 16:22:55 SUMMARY: @skynavga to continue investigating 16:22:59 github-bot, end topic 16:23:02 Topic: Meeting close 16:23:16 Glenn: We covered a lot today so thank you for that. I look forward to the pull request reviews. 16:23:26 .. #794 is my highest priority if you can take that into account. 16:23:41 Nigel: OK, thanks both, next meeting same time next week. [adjourns meeting] 16:23:54 rrsagent, make minutes 16:23:54 I have made the request to generate https://www.w3.org/2018/05/31-tt-minutes.html nigel 16:31:00 Zakim has left #tt 16:44:48 scribeOptions -final -noEmbedDiagnostics 16:44:52 rrsagent, make minutes 16:44:52 I have made the request to generate https://www.w3.org/2018/05/31-tt-minutes.html nigel 16:46:16 s/scribeOptions -final -noEmbedDiagnostics// 16:46:22 scribeOptions: -final -noEmbedDiagnostics 16:46:27 rrsagent, make minutes 16:46:27 I have made the request to generate https://www.w3.org/2018/05/31-tt-minutes.html nigel 16:47:47 nigel has changed the topic to: TTWG meetings Thursdays 1000 Boston time. Minutes for most recent meeting: https://www.w3.org/2018/05/31-tt-minutes.html