15:01:44 RRSAgent has joined #tt 15:01:44 logging to https://www.w3.org/2021/04/01-tt-irc 15:01:47 RRSAgent, make logs Public 15:01:48 Meeting: Timed Text Working Group Teleconference 15:02:06 Previous meeting: https://www.w3.org/2021/03/18-tt-minutes.html 15:02:14 Agenda: https://github.com/w3c/ttwg/issues/177 15:02:27 nigel has changed the topic to: TTWG Teleconference 2021-04-01. Agenda: https://github.com/w3c/ttwg/issues/177 15:05:12 Present: Nigel, Andreas, Gary 15:05:17 Chair: Gary, Nigel 15:05:32 Regrets: Cyril, Glenn 15:05:44 Present+ Atsushi 15:06:37 Topic: This meeting 15:06:40 scribe: nigel 15:06:58 Nigel: Today we have 2 TTML2 issues, and a WebVTT issue. 15:07:15 .. and I'd like to agree the cadence of our upcoming meetings, and 15:07:25 .. I have some AOB about Audio Description. 15:07:31 .. Any other business? 15:07:45 group: [no other business] 15:08:30 Topic: WebVTT - Added unbounded TextTrackCue.endTime w3c/webvtt#493 15:08:38 github: https://github.com/w3c/webvtt/pull/493 15:09:16 Gary: Two issues that are discussed in the pull request. I think we should be clear on what the PR is 15:09:29 .. and whether there are any objections about that progressing and then we can talk about the other part. 15:09:45 .. The PR is about updating the VTTCue API to be able to have an unbounded end time, i.e. set to infinity. 15:10:05 .. It lines up with the HTML spec for TextTrackCue, and was brought up mostly as a way for metadata but I think it makes sense for anything. 15:10:32 .. Since this PR only covers that, are there any objections for that part of it? 15:11:36 Nigel: Note we discussed this 28 days ago at https://github.com/w3c/webvtt/pull/493#issuecomment-790758189 15:11:46 .. We wanted tests, and to ask if a syntax change is needed. 15:12:33 .. Formally, I think it is _not_ required to have a syntax change to agree to this change. 15:12:48 Gary: Yes, and as the discussion brought up, there are a lot of complications to doing that, and what it would mean, 15:13:04 .. so it is good to decouple it so we are not holding up this change elsewhere while we figure out the syntax. 15:13:44 .. As David Singer said, even in ISOBMFF, they don't really specify how these unbounded cues might come to be. 15:14:34 Nigel: We need to be careful - ISOBMFF is only a file format wrapper, so for them to be even considering unbounded VTT cues without 15:14:42 .. any syntax to represent them is a bit disturbing. 15:16:03 Gary: I think there are use cases for the syntax change but figuring them all out and the semantics is definitely not just slapping a change in 15:16:13 .. to the cue settings - it's probably not good enough on its own. 15:16:29 Nigel: Are there any tests? 15:16:48 Gary: I don't know if there are yet. Rob Smith did say he would write some. I don't know if he's got around to it yet. 15:17:02 .. I think we can wait for tests, and that can be the only blocker for this PR. 15:17:21 Nigel: Makes sense. 15:18:02 Gary: Do we want to discuss syntax, or punt on it for now? 15:18:07 Nigel: I think raise it as a separate issue. 15:18:11 Gary: Yes, makes sense. 15:18:22 .. If Rob doesn't make that issue then I will make one. 15:19:33 SUMMARY: 1. No objections to this PR as is, though we are blocked on tests. 2. Move the unbounded cue syntax question into a separate issue. 15:20:08 Topic: TTML2 Mention fingerprinting vectors in privacy considerations. #1189 15:20:15 github: https://github.com/w3c/ttml2/issues/1189 15:20:40 Nigel: This issue has been closed, but was closed without confirmation from the issue raiser that they were satisfied. 15:22:41 .. @jyasskin responded to say that he considers some parts of the original issue not to have been addressed. 15:23:40 .. The original analysis from Glenn was that most of the issues are already in TTML1 and several are covered in general by the 15:23:47 .. appendix on security and privacy considerations. 15:24:17 .. What we need to decide is if we think the current text is adequate given this Horizontal Review comment, or if we can and should 15:24:27 .. call out specific possibilities as per the issue. 15:24:49 .. I'd suggest if we do call out the possibilities we do them as "for example" style notes. 15:24:55 .. Any views? 15:26:44 .. Looking at the current CRS Privacy section, I think some of the vectors are already covered but maybe not in detail. 15:27:17 .. I'll go through each of the listed vectors and show where it is, or if it is not mentioned, and come up with a proposal for addressing the resulting gaps. 15:27:22 .. Make sense? 15:27:43 Pierre: I suspect we're going to have this discussion again where the commenter wants us to be more explicit than we have wanted to be in the past. 15:28:04 .. I'm not sure how we resolve it. It is a larger architecture issue. What you're proposing is a good idea, but we have to be prepared to 15:28:24 .. have the broader discussion again about whether every single W3C specification has really specific implementation recommendations or 15:28:29 .. if there should be a central spec. 15:29:13 Nigel: I'm comfortable listing the considerations that apply specific to the domain of TTML, and I don't think this issue is asking for more than that. 15:29:45 SUMMARY: @nigelmegitt to review the vectors in detail and propose how to resolve any gaps. 15:29:58 Nigel: I will also reopen this issue. 15:30:36 Topic: Shear calculations and origin of coordinate system. w3c/ttml2#1199 15:30:41 github: https://github.com/w3c/ttml2/issues/1199 15:32:00 Nigel: This is about block shear. Cyril raised a comment recently about the formula for reducing the inline progression dimension 15:32:07 .. prior to shear transformation. 15:32:20 .. Has anyone been able to review that comment? 15:32:30 Pierre: No 15:32:45 Nigel: That would be a substantive issue if it is wrong. 15:33:02 .. I weighed in a couple of weeks ago with something that's possibly more concerning 15:34:56 .. if people are implementing now. 15:35:05 .. There's a computational impact that I don't think we realised. 15:35:24 .. Unless there's a strong requirement I think we should consider dropping the feature. 15:35:48 Pierre: What saves us here is that it is always possible for the author to give sufficient space to guarantee that 15:36:06 .. line wrapping will not happen because it is really undesirable in the case of Japanese, especially if there are rubys involved. 15:36:13 .. In practice it has not been a big issue. 15:36:30 .. A more complicated answer is that CSS cannot support line shear today, which is a huge limitation. 15:36:41 .. More importantly there's an ongoing debate. I've seen arguments on both sides. 15:36:58 .. If you shear ruby annotations and ruby base text how should they be arranged? 15:37:12 .. It can change the alignment if you shear separately from shearing together. 15:37:25 .. I've heard strong opinions both ways that you must shear them separately or together. 15:37:47 Atsushi: On the point, i18n WG Japanese task force reached out to someone working in typography but there was 15:37:55 .. no consensus or good suggestion. 15:38:21 Pierre: In fact, if you don't care about the relationship of alignment between ruby annotations and ruby base then you can 15:38:35 .. just use fontShear, but that does not work for tate chu yoko. 15:38:54 .. It is complicated. The potential for overflow or line wrappign in block shear has not been a problem so far. 15:39:03 .. The potential is really terrible. 15:39:22 .. Font shear would work great but in the case of ta te chu yoko you need block shear or line shear. 15:39:29 s/pign/ping 15:39:49 .. And another aspect, which is somewhat arbitrary but needs thinking about: do we want block shear or line shear to 15:40:09 .. change if you're writing rtl or ltr for Hebrew vs English for instance. One could argue you should never use them 15:40:15 .. but we still need to specify what happens. 15:40:27 .. So far in imscJS just as a data point nobody has complained about block shear. 15:41:17 Nigel: In imscJS does the resulting parallelogram from the shear go outside the boundaries of the original block area? 15:41:41 Pierre: Yes, the CSS skew just allows it to go outside the boundaries. 15:42:10 Nigel: And it's only in the inline progression direction that you get an overflow? 15:42:12 Pierre: Correct. 15:42:35 .. In Japanese it isn't really an issue in practice, because the authoring guarantees that lines won't wrap, and there's 15:42:45 .. plenty of padding and no background, so in practice it seems to work. 15:42:59 .. Line shear would be awesome and solves all problems but is not possible to implement in CSS today. 15:43:16 .. And some people might object to it. As pointed out I'm not sure there's a consensus. 15:43:33 Nigel: And my assumption is line shear would include the rubys on the line? 15:43:46 Pierre: Yes absolutely, and the tate chu yoko when that's used. 15:44:04 Nigel: That feels like the answer - doesn't everyone just want that? 15:44:19 Pierre: If supported in CSS, maybe. We would need to go back to the original issue. 15:44:30 .. The reason it was not picked for IMSC is the lack of support in CSS. 15:46:11 Nigel: Going back to the Japanese language task force, my understanding is that shear is mostly used in electronic displays, and very little 15:46:16 .. on paper? 15:46:39 Atsushi: In daily life I very rarely see shear in daily life, on either kind of display. I don't think I saw anything this week. 15:46:55 .. The consensus in the Japanese task force is that it is an interesting question but who cares? 15:47:39 Nigel: This came to us because of its use in captions - is that an aspect you would notice in daily life? 15:48:12 Atsushi: I think there is use in captions for some scenarios in movies, say, but for television captions I think it is still quite rare. 15:48:17 Nigel: Okay, thanks. 15:48:37 .. Nevertheless we clearly have a requirement for it, certainly from Netflix. 15:49:10 Atsushi: Captions in movies import styling meanings from western languages so they import the same semantic meaning as italics, 15:50:19 .. but I believe using shearing or italic case is quite a specific use case, say for non-on-screen communications perhaps. 15:50:25 Nigel: But a real one. 15:50:28 Atsushi: Yes, that's correct. 15:50:55 .. To be honest, some older typographic designers say there's no italic in Japanese so they don't want to implement it even in fonts. 15:51:14 Pierre: It is in widespread use in cinemas. 15:51:37 Atsushi: In other words, there is no widely used common standard for how to shear or how to make italics. 15:51:42 Pierre: There's a cinema standard. 15:52:10 Atsushi: If cinema standard is well written, and has well considered definitions it may be possible to borrow it but I'm not sure if it is or not. 15:52:19 Pierre: This was already provided by the way, to W3C. 15:52:24 .. The cinema standard. 15:52:26 .. In an issue. 15:53:07 Nigel: We have sources for this so it might be worth going back and reminding ourselves what they say. 15:54:16 .. I think the easy thing to do here, the direction question aside, is to say that the shear may result in an overflow in the inline progression 15:54:37 .. direction, and it's then up to implementations to try to do anything more complicated, and authors can apply padding as needed to avoid 15:54:40 .. it if they like. 15:54:55 .. It may not be entirely interoperable, but it is at least implementable. 15:56:17 SUMMARY: Outstanding questions remain, regarding direction, and scaling. Real world computational issues have not yet arisen. 15:56:32 Topic: Cadence of future meetings 15:56:43 Nigel: Is the 2 weekly cadence working for everyone? 15:56:48 Pierre: Seems right to me. 15:56:52 Atsushi: I will follow you 15:56:56 Gary: No objections 15:57:00 Andreas: Fine for me. 15:57:32 Nigel: Great, I will set up a recurring meeting in the new calendar system, so we don't need ICS files, 15:58:00 .. and I will also open the GitHub issues which continue to work well in managing the agenda and conversation. 15:58:18 Topic: Implementation news regarding the AD profile of TTML2 15:58:40 Nigel: Hot off the press, I just pressed the button this afternoon, to open up our adhere AD profile of TTML2 to be open source. 15:58:55 -> https://github.com/bbc/adhere-lib Adhere library 15:59:11 -> https://bbc.github.io/Adhere/ Demo page 15:59:41 .. We split out the core underlying code from the demo page to be in a separate library. 15:59:50 .. This means you can play with it as you see fit! 16:00:11 .. Hopefully that will unlock other implementations as well. 16:00:44 .. I'll send a separate message to the implementers I think are waiting on this. 16:00:53 Andreas: Thanks Nigel that's really good news. 16:01:02 Nigel: Yes, it's taken a long time and it's far from perfect! 16:01:33 Topic: Meeting close 16:01:53 Nigel: Thanks everyone, regrets for me for 2 weeks time, I'll leave this call in your capable hands everyone! 16:01:58 .. [adjourns meeting] 16:02:01 rrsagent, make minutes v2 16:02:01 I have made the request to generate https://www.w3.org/2021/04/01-tt-minutes.html nigel 16:06:35 Present+ Pierre 16:08:13 s/that apply specific to/that apply specifically to 16:10:07 s/But a real one./But a real one? 16:11:02 rrsagent, make minutes v2 16:11:02 I have made the request to generate https://www.w3.org/2021/04/01-tt-minutes.html nigel 16:12:09 scribeOptions: -final -noEmbedDiagnostics 16:12:13 zakim, end meeting 16:12:13 As of this point the attendees have been Nigel, Andreas, Gary, Atsushi, Pierre 16:12:16 RRSAgent, please draft minutes v2 16:12:16 I have made the request to generate https://www.w3.org/2021/04/01-tt-minutes.html Zakim 16:12:19 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:12:23 Zakim has left #tt 16:17:27 rrsagent, excuse us 16:17:27 I see no action items