15:01:33 RRSAgent has joined #tt 15:01:33 logging to https://www.w3.org/2018/02/01-tt-irc 15:01:35 RRSAgent, make logs public 15:01:35 Zakim has joined #tt 15:01:37 Meeting: Timed Text Working Group Teleconference 15:01:37 Date: 01 February 2018 15:01:45 log: https://www.w3.org/2018/02/01-tt-irc 15:01:48 scribe: nigel 15:01:52 Present: Nigel 15:01:54 Chair: Nigel 15:01:56 Regrets: Pierre 15:02:42 Present+ Thierry, Glenn 15:03:37 Present+ Andreas 15:04:03 tmichel has joined #tt 15:04:09 Topic: This Meeting 15:04:10 glenn has joined #tt 15:04:15 atai2 has joined #tt 15:04:17 present+ 15:04:44 Topic: Today is for me the Big Day for TTML2, being effectively the last day for opening 15:05:01 .. substantive pull requests. 15:05:18 Glenn: If any more are opened, the Group will have to decide what to do. 15:05:50 Nigel: The 2 week review period is derived from the group's Decision Policy in the Charter. 15:06:00 Present+ Cyril 15:06:20 cyril has joined #tt 15:06:26 Nigel: I just sent round a summary, and I propose that we prioritise the issues marked for 15:06:42 .. the agenda as usual, and also scan through all the "blocks CR" issues. 15:07:44 Nigel: So I propose to do TTML2, then TTML1 - I don't think there are any IMSC issues 15:07:48 .. that need urgent discussion today. 15:08:10 .. Any other business or points to discuss? 15:08:48 Cyril: What about the duration of the review period? 15:09:11 Nigel: I don't really want to open that discussion up right now. 15:09:58 .. I see 13 TTML2 issues and pull requests marked for agenda right now. 15:10:12 -> https://github.com/w3c/ttml2/labels/agenda Issues and pull requests marked Agenda 15:11:51 group: [no other business] 15:12:17 Topic: Incorporate resolutions of additional TTML1 Issues. ttml2#358 15:12:22 github: https://github.com/w3c/ttml2/issues/358 15:12:34 Cyril: I explained by email what is happening in this one. There are two TTML1 issues 15:12:55 .. that should be incorporated in TTML2. One of them has been progressed by Pierre, w3c/ttml1#320, 15:13:12 .. so that should be fine. The other is w3c/ttml1#317 on chained referential styling. 15:14:25 Nigel: I opened that ttml1 issue. 15:14:39 Cyril: I want to close that issue or defer it. We should possibly open an issue for TTML2 15:14:47 .. and mark it as ttml.next or post CR1. 15:16:00 Nigel: I've marked the TTML1 issue as editorial and don't mind removing it from this issue, 15:16:05 .. since there's no action to take. 15:16:21 Cyril: Okay, then I just need to implement w3c/ttml1#320 here and then we can close this. 15:17:51 SUMMARY: Cyril has what he needs to complete this today. 15:17:55 github-bot, end topic 15:18:19 Topic: A single length value for tts:fontSize specifies both height and width. ttml2#548 15:18:25 github: https://github.com/w3c/ttml2/issues/548 15:19:52 Nigel: I'm requesting consistency here between "applies" and "expresses" - and replacing all 15:20:01 .. in this sentence with "defines". Is that okay, Editors? 15:20:04 Cyril: Fine for me 15:21:55 Glenn: We use applies, expresses in various places, so I have no problem with the current language. 15:22:07 .. I would rather change "expresses" to "applies to" for consistency. 15:23:25 Nigel: That would be inconsistent with, for example, the way that "applies" defines the 15:23:33 .. significance of a style attribute on an element. 15:23:46 Glenn: If you review use of these terms you'll find they are approximately synonyms. 15:23:59 .. Changing this here seems unnecessary without reviewing all the other cases. 15:24:12 .. "defines" implies "fully defines" to me, in my mind. 15:24:18 Nigel: "determines", then? 15:25:35 .. I see "applies" as meaning "is relevant to". 15:25:49 Glenn: If you want to change "applies to" to "determines" and "expresses" to "determines" 15:25:55 .. then I would be okay with that. 15:26:02 Nigel: Okay, that works for me. 15:26:37 RESOLUTION: Replace "applies to" and "expresses" with "determines". 15:28:17 Ok for me 15:28:25 github-bot, end topic 15:29:35 Topic: clarify use of tts:textCombine ttml2#619 (pull request) 15:29:58 Cyril: This requires a bit of work. It is related to a set of comments from r12a about 15:30:18 .. internationalisation. There are three issues related, on textOrientation, writingMode and 15:31:08 .. resolving issues #277, #280 and #281. 15:31:19 Glenn: Do you have a sense of whether the resolutions will be editorial or substantive? 15:31:25 Cyril: Substantive I think. 15:31:46 .. It's about adding clarification - maybe a significant number of lines will be changed. 15:31:57 Glenn: My sense is that all of Richard's comments can be resolved editorially. 15:32:21 Topic: Incorporate CSS advances into TTML vertical text handling ttml2#277 15:32:28 github: https://github.com/w3c/ttml2/issues/277 15:33:08 Cyril: My problem with this is, at least at Netflix, we want to align better with CSS in the future, 15:33:20 .. and I wouldn't want to make changes in TTML2 that make such alignment impossible in the future. 15:33:21 Nigel: +1 15:33:35 Glenn: We have some study of mapping of TTML and CSS, and for writingMode we had 15:33:42 .. concluded that there is a mapping available. 15:33:44 Nigel: I believe so. 15:34:04 Cyril: Writing Mode in CSS has additional values we don't have. 15:34:13 Glenn: But we do have all of them. We just have different keywords. 15:34:31 Nigel: Do we have sideways-left and sideways-right that weren't in XSL-FO? 15:34:41 Glenn: Yes, you use writingMode and textOrientation together. 15:35:19 Cyril: I think it's okay for writingMode, because CSS defines how to map the old values to 15:35:43 .. the new ones for writing-mode. 15:35:58 .. In CSS level 3 or 4, the spec defines the interaction between writing-mode, text-orientation, 15:36:18 .. direction, text-combine and so on. I have no idea what the interaction between those 15:36:30 .. properties are, for example textCombine and textOrientation. 15:36:34 Glenn: They are independent. 15:36:44 Cyril: They cannot be, or what's the order in which they are applied? 15:37:46 Glenn: textCombine only applies potentially when some segment of text does not have the 15:37:59 .. same text orientation as its surrounding text. 15:38:07 Cyril: When horizontal text is upright in vertical text. 15:38:26 Glenn: Yes, so if textOrientation were sideways then it would never apply. If you put 15:38:38 .. Japanese text inside English text for example, and the outer portion is sideways, then I 15:38:51 .. guess in that case you would set the Japanese text sideways as well so textCombine would 15:38:54 .. not apply either. 15:39:07 Cyril: We can find examples - my general question is I don't know how to fix the spec without 15:39:14 .. referring to CSS and saying do what they say. 15:39:22 Glenn: I don't think there's anything broken right now. 15:39:33 Cyril: There's nothing in the spec that defines the processing model for textCombine and 15:39:42 .. writingMode. 15:39:47 Glenn: There's a great deal not defined. 15:39:52 Cyril: Exactly. 15:40:05 Glenn: Over time we can add more language to the spec, but we won't need additional keywords. 15:40:19 .. So one issue it that Richard's comment is asking to add two additional values to writingMode. 15:40:28 Cyril: I can say we won't do this now but might do it alter. 15:40:32 s/alter/later 15:40:37 Glenn: That's appropriate. 15:40:49 Cyril: Then can we resolve this? 15:42:08 RESOLUTION: We are willing to evaluate the use case for the new writing-mode values but will defer this to a future version of TTML. 15:42:47 github-bot, end topic 15:43:54 Topic: Sideways shouldn't be tied to tblr vs tbrl ttml2#280 15:43:58 github: https://github.com/w3c/ttml2/issues/280 15:44:33 Cyril: As per #277, I don't know how to clarify or change this without making a lot of changes. 15:45:44 Glenn: The fact that the derivation was originally based on a version of CSS that has 15:46:25 .. since been changed doesn't change it. 15:46:40 Nigel: I just moved the basis across to appendix N. 15:46:55 Glenn: We could review the accuracy of that and add notes here if we want to. I don't have any in mind right now. 15:47:49 Cyril: CSS Level 3 and Level 4 Writing Modes are the same for text-orientation. 15:49:10 Glenn: The CSS application to 'vertical script' characters can be seen as a superset of what 15:49:24 .. we have implemented. I'm not aware of a use case for that off-hand. I don't believe we 15:49:38 .. are inconsistent, but possibly a subset of some expanded semantics that allows vertical 15:49:46 .. script characters to have sideways applied to them. 15:51:13 Nigel: He's worried about correct progression of text along the line for Latin text when 15:51:19 .. tblr is the writing-mode value. 15:51:51 Glenn: One way to address this would be to remove the keyword "sideways" entirely and 15:52:04 .. just leave sideways-lr and sideways-rl. 15:52:12 Cyril: I think that's the opposite of what he wants. 15:52:33 Glenn: The only reason I added sideways in the first place was because it was listed in CSS. 15:52:55 .. That language came from earlier versions of the CSS spec language. Then they made changes. 15:53:06 .. If we take sideways out then we don't have to clarify anything. 15:53:22 Nigel: Why would we not just adopt the updated language from the current CSS spec? 15:53:28 Glenn: I haven't reviewed it yet. 15:54:51 -> https://www.w3.org/TR/css-writing-modes-4/ CSS Writing Modes Level 4 WD 15:55:28 Nigel: Level 4 marks sideways-lr and sideways-rl as at risk! 15:55:38 Glenn: Oh boy! 15:57:04 Cyril: It's a FPWD and they're already talking about at risk features - this could be a hangover from L3 CR that's not been cleaned up (speculating). 15:57:12 .. Glenn, you propose to remove sideways? 15:57:40 Glenn: I see there's another comment, about "unless this behaviour..." - that's in fact the 15:58:02 .. only place where we intend to use it. Actually for mixed scripts. 15:58:29 Present+ Pierre 15:58:51 Glenn: It seems like the resolution may be similar to #277. We said we would 15:58:54 Nigel: You're proposing no change? 15:59:00 Glenn: Yes, as for #277. 15:59:37 Cyril: textOrientation is new in TTML2, derived from CSS, but does not have a 1:1 mapping 15:59:42 .. to CSS. That's an issue to me. 16:00:01 .. Level 3 is in CR now, and nothing is marked as at risk. Could we align with L3? 16:00:48 .. Just in terms of keywords - they don't have sideways-left and sideways-right. 16:01:01 -> https://www.w3.org/TR/css-writing-modes-3/#text-orientation CSS Writing Modes L3 text-orientation 16:01:23 Nigel: [observes that this is really late to be making this change] 16:01:34 Glenn: [agrees, especially since it has already been implemented] 16:01:49 .. I notice they have a sentence "UAs may accept sideways-right as a value that computes to sideways if needed for backward compatibility reasons." 16:02:06 .. So they've said they don't like sideways-left. 16:03:10 .. If you're doing tblr and sideways, then Latin text would start at the bottom and go up. 16:03:31 .. It sounds like they have no use case for that scenario. 16:03:43 Cyril: Why don't we mark sideways-left and sideways-right as at risk? 16:03:46 Glenn: Good proposal. 16:05:40 RESOLUTION: We will mark sidewaysLeft and sidewaysRight as at risk for CR and continue to review the need for those features and their alignment with CSS. 16:05:43 Cyril: +1 16:05:44 Glenn: +1 16:05:52 Cyril: I'll propose a pull request to mark them as at risk. 16:06:07 Topic: Upright orientation involves more than just glyph orientation ttml2#281 16:06:13 github: https://github.com/w3c/ttml2/issues/281 16:07:58 Nigel: It looks like Richard's proposals are certainly missing right now and would make a 16:08:12 .. big difference to readability for the scripts he mentions. 16:08:40 Glenn: You would never set arabic in upright form as he describes there... Actually there's 16:08:55 .. a language in one of the Maldive islands that uses arabic letters only in their isolated form 16:09:00 .. to write their language. 16:09:45 Glenn: Right now we don't say the things he proposes but that doesn't mean that 16:09:51 .. processors couldn't do it. 16:09:59 Nigel: We talk about individual glyphs, which is the problem. 16:10:15 Glenn: I think the language came from an earlier version of Writing Modes, and they've 16:10:29 .. refined those but we haven't updated ours accordingly. 16:10:42 Nigel: Is the task therefore to update TTML2 to match the more up to date CSS language? 16:10:57 Glenn: I've avoided using grapheme cluster so far but there were other questions about Ruby 16:11:08 .. that mention them, so I think we may not be able to avoid them. It's a really complex 16:11:20 .. concept and very few people understand it. I'm not sure of the value of introducing it 16:11:37 .. here. I prefer to leave it under-specified and let implementations do the right thing. 16:12:17 .. We can resolve it editorially with notes later. 16:12:25 Nigel: We refer to glyphs and don't allow for groups of glyphs. 16:12:29 Glenn: We do allow for that. 16:12:34 Nigel: How do we do that? 16:12:57 Glenn: "glyphs from horizontal scripts" is in my mind ambiguous - scripts do not have 16:13:07 .. glyphs, they have characters, and glyphs are the result of a complex mapping from characters 16:14:11 .. to glyphs. 16:14:27 Nigel: We already defined "glyph area" - why don't we just substitute "glyph" for "glyph area"? 16:14:36 Glenn: That would work for me. That's in fact exactly what would happen. 16:15:33 .. I anticipate Richard will come back with some questions. 16:17:51 RESOLUTION: Change "glyph" to "glyph area" in the quoted text. 16:17:59 Cyril: I will prepare that pull request. 16:18:29 github-bot, end topic 16:19:20 Topic: How to handle mismatched sequences in complex ruby ttml2#247 16:19:25 github: https://github.com/w3c/ttml2/issues/247 16:19:36 Cyril: I could not find how the mapping is done between the container and the base text 16:19:48 .. if there are multiple bases. Is a 1:1 mapping needed? 16:20:04 Glenn: I believe the answer is yes. I think he's asking if RT items != RB items. 16:20:26 .. TTPE implements code to handle that case and probably applies however many RTs to 16:20:38 .. the available RBs and if there are more then they are ignored. We don't say anything in 16:20:42 .. the spec text right now. 16:21:00 Cyril: I think we should. In #246 he is proposing to change the example but not the base 16:21:13 .. text, which I think is not correct. This is the "complex ruby" example. The first part 16:21:28 .. is a base container, containing one base element, and the second part has only one text 16:21:41 .. element, and he wants to change to two separate spans with ruby text, but if you do that 16:22:06 .. you have to change the [scribe lost track]. 16:23:07 .. I think if we say mapping has to be 1:1 then ... [look at the complex ruby example in the spec] 16:24:02 .. He wants to split the "before" into two sets of two characters each, with each pair 16:24:13 .. corresponding to a single base character. 16:24:31 Glenn: The rendered output would be the same either way. 16:24:44 Cyril: That clarifies my question to #246, that's fine. If I do what he says, and split the 16:24:58 .. span for before annotation into two, how do you know that the first one applies to the 16:25:02 .. first character? 16:25:18 Glenn: Good question. This goes back to the previous question whether there's a different 16:25:26 .. number of text to base units in the case of... 16:25:42 Cyril: If there's only one text, then it is group ruby and applies to all bases. If there's the 16:25:54 .. same number, I also understand it means mono ruby. I don't understand if there are 16:25:57 .. other permutations. 16:26:16 .. We could say you have two choices: text containers = base containers or text container = 1 16:26:24 .. (i.e. number of them) 16:26:40 Glenn: Yeah, right now I don't see any way to specify both before and after cases and 16:26:43 .. separate the bases. 16:26:53 Cyril: There's nothing to prevent it, it's just not specified. 16:28:18 Glenn: I would need to look at the current CSS Ruby spec which is actually quite old. 16:29:01 Nigel: We need a resolution to this issue. 16:29:13 Pierre: Does this ambiguity arise in a use case that Netflix has? 16:29:20 Cyril: At the moment we don't have this use case. 16:29:37 Pierre: One possibility is to try to specify the behaviour in the complex cases, another is 16:29:50 .. to eliminate those complex cases by prohibiting them. A third is to ignore them in TTML2 16:30:07 .. and leave them deliberately underspecified. We might just not have time to specify the behaviour. 16:30:26 Glenn: I tend to agree with leaving it underspecified. But will Richard be able to accept that? 16:30:39 Pierre: How does HTML do it? Do they simply not support those complex cases? 16:30:54 Cyril: They do support it. This example looks complex but it isn't uncommon. 16:31:16 .. My proposal would be to add constraints about texts = bases or texts = 1. 16:31:19 Pierre: In TTML2? 16:31:33 Pierre: Fine with me. You could constrain that in a feature. 16:31:47 Glenn: I'm not prepared to accept that. It's related to the other issue, which is if there is a 16:32:01 .. different number of texts from bases, how is that resolved? That is independent of before 16:32:05 .. and after. 16:32:07 Cyril: Yes 16:32:35 Cyril: If you don't have the after then you just use container, base and text, and have two 16:32:44 .. consecutive ruby containers. 16:33:43 Glenn: My preference would be to resolve this post-CR with clarification comments. 16:33:52 Cyril: No we have to resolve it before CR, it is not editorial. 16:33:54 Nigel: +1 16:34:10 Glenn: If I'm forced to answer, I'm going to say defer it to the future. 16:35:18 Nigel: I would propose to keep the syntactic flexibility but apply Cyril's proposed constraints 16:35:34 .. as a feature, which provides something that we can test sensibly. 16:35:40 .. That allows us to add further semantics later. 16:40:03 Glenn: That's terrible. I would say right now, normatively, that if the number of base items 16:40:14 .. and the number of text items are not matched then the behaviour is implementation 16:40:15 .. dependent. 16:40:23 Cyril: That's fine by me. 16:40:47 .. But also allow group ruby? 16:40:51 Glenn: Yes. 16:41:13 Cyril: This is enough for me to move forward. 16:42:02 RESOLUTION: Add a normative statement that the behaviour for mismatched rb and rt numbers (other than a single rt) is implementation dependent. 16:42:13 github-bot, end topic 16:43:22 Topic: Complex ruby is usually both mono and group ruby ttml2#246 16:43:27 github: https://github.com/w3c/ttml2/issues/246 16:44:18 Cyril: I will change the example as requested and modulo the resolution for #247 16:44:47 .. When it is a single rt then it is group ruby, when the number of rt is equal to the number of rb 16:44:56 .. then that's mono ruby. The other cases are not defined. 16:45:55 Glenn: Where do we specify that a single rt applies to multiple bases? 16:46:07 .. For that mismatch, where do we define it? 16:46:22 Cyril: I'm going to add that to the text. 16:46:34 .. That's group ruby, right? 16:46:56 Glenn: We haven't discussed the work to do that. 16:48:05 .. We don't have any language on group ruby in the spec, and introducing this now would 16:48:13 .. require a lot of elaboration at this time. 16:48:22 Cyril: It is nothing new. 16:48:40 Glenn: I want to leave it unspecified, rather than the exception clause for the mismatch. 16:50:16 .. There's no example of group ruby in the spec right now. 16:50:36 Cyril: The "Complex Ruby" example uses group ruby, and the request in this issue is to 16:50:40 .. introduce a mismatch. 16:50:52 Pierre: Then we can simply say "mismatches are not defined" and remove the example. 16:50:59 Glenn: The example right now does not have a mismatch. 16:51:16 .. We should not introduce the change, and say that doing what the request asks would 16:51:23 .. introduce undefined behaviour. 16:51:52 Pierre: Since we don't have a use case for mismatch, we can leave that out in all cases, 16:52:21 .. and tell the reporter that we don't define behaviour so won't do it. 16:52:42 Cyril: We have use cases for mono ruby and group ruby, but not for complex ruby mixing 16:52:45 .. mono and group. 16:52:55 Glenn: In your use of group, you don't have mismatch? 16:53:15 Cyril: Right, unless we have 1:1. Actually the "simple ruby" example is a group. 16:53:48 Glenn: That's right. There'a a one to one match in both current cases. 16:54:04 .. The comment here requests introducing a mismatch, which we want to avoid. So here 16:54:09 .. we cannot simply accept the proposed change. 16:55:23 RESOLUTION: We will not make the requested change because it would introduce a mismatch between the number of texts and bases, and we currently do not define the behaviour in that case. 16:55:28 github-bot, end topic 16:55:50 Topic: How to handle mismatched sequences in complex ruby ttml2#247 16:55:55 github: https://github.com/w3c/ttml2/issues/247 16:56:26 RESOLUTION: (updated following further discussion) All mismatches will be left as implementation dependent behaviour, even if the number of texts is 1. 16:57:17 github-bot, end topic 16:59:01 Topic: rubyOffset and line-spacing ttml2#252 16:59:08 github: https://github.com/w3c/ttml2/issues/252 16:59:29 Glenn: I can accept deferring rubyOffset to the next version 16:59:45 RESOLUTION: Remove rubyOffset and defer it to ttml.next 17:00:00 Glenn: I put it in for thoroughness, not because I knew a particular use case in subtitling and captioning. 17:00:17 .. Since CSS doesn't have ruby offset either we can wait. 17:00:27 github-bot, end topic 17:02:02 Topic: Remove animate, begin, dur, end, region and timeContainer of br elements (#552). ttml2#570 17:02:10 github: https://github.com/w3c/ttml2/pull/570 17:03:13 s/570/570 (pull request) 17:05:10 Glenn: I think we had record to include timing etc on br before in a change proposal. 17:05:25 Pierre: We resolved this differently more recently. The safest thing at this point is to match 17:05:34 .. TTML1. We can deal with this later on by extending TTML2. 17:06:25 Glenn: We could simply mark this as at risk. 17:06:56 I need to drop now. Bye. 17:08:15 Pierre: We don't know of any use case that requires these features on br 17:08:23 Glenn: And your proposal is to use span to style and time a br? 17:08:26 Pierre: Yes 17:08:42 Glenn: It maintains an inconsistency. The options are: 17:08:50 .. 1. Leave it in and add that display applies to br 17:08:54 .. 2. Take it out 17:09:05 .. 3. Mark as at risk 17:09:18 .. Marking it as at risk allows us to get to CR and deal with it afterwards. 17:09:30 Pierre: It requires a new feature too, because we're acknowledging it was not there before. 17:09:44 Glenn: That's true, something like break-2 which would require content-2. 17:10:03 Pierre: I don't disagree that the lack of symmetry is not awesome and the fact that tts:display 17:10:17 .. is mentioned in br but does not apply to it is not great, but given the time we have the 17:10:22 .. simplest thing to do is to add it to TTML1. 17:10:36 Glenn: If we remove it I would like to add a note that some presentation processors may 17:10:47 .. apply display styling. 17:11:03 Pierre: What about saying explicitly that it's important not to specify tts:display because 17:11:10 .. some interpretations may misinterpret it? 17:11:48 Glenn: Technically right now it's a non-standard extension, which would need some parameterisation on the processor to switch it off for strict conformance. 17:12:03 .. I haven't checked if TTV points it out as a conformance error right now. 17:13:47 Pierre: tts:display is not inheritable, so I think you don't want people to specify tts:display 17:14:01 .. on br because it might have an impact in TTPE where it might not elsewhere. I'm suggesting 17:14:20 .. we encourage authors not to add tts:display to br, which avoids the problem because 17:14:25 .. tts:display is not inheritable. 17:15:16 Glenn: [looks for test cases] I don't think I have any test cases... 17:15:36 .. I may regret this, but I'll remove my comment and objection. I don't want to put a negative 17:15:39 .. requirement in right now. 17:15:42 Pierre: Fine with me. 17:15:47 Nigel: Fine with me. 17:15:50 .. Thanks Glenn. 17:29:31 Topic: APA comments 17:29:44 Pierre: I plan to have proposed resolutions to the APA comments on IMSC 1.1 by next week 17:37:19 Topic: Meeting close 17:37:26 Nigel: Thanks everyone [adjourns meeting] 17:37:30 Regrets: None 17:37:34 rrsagent, make minutes 17:37:34 I have made the request to generate https://www.w3.org/2018/02/01-tt-minutes.html nigel 17:40:57 s/Topic: Today is for me/Nigel: Today is for me 17:40:59 rrsagent, make minutes 17:40:59 I have made the request to generate https://www.w3.org/2018/02/01-tt-minutes.html nigel 17:42:01 ScribeOptions: -final -noEmbedDiagnostics 17:42:02 rrsagent, make minutes 17:42:02 I have made the request to generate https://www.w3.org/2018/02/01-tt-minutes.html nigel 18:10:58 Zakim has left #tt