15:00:55 RRSAgent has joined #tt 15:00:55 logging to https://www.w3.org/2021/03/18-tt-irc 15:01:01 RRSAgent, make logs Public 15:01:03 Meeting: Timed Text Working Group Teleconference 15:01:13 Present: Pierre, Nigel 15:01:16 scribe: nigel 15:01:21 Chair: Nigel 15:01:27 Regrets: Atsushi, Gary 15:01:40 Previous meeting: https://www.w3.org/2021/03/04-tt-minutes.html 15:01:46 Agenda: https://github.com/w3c/ttwg/issues/176 15:03:47 Present+ Glenn 15:05:05 Topic: This meeting 15:05:39 Present+ Cyril 15:06:01 Nigel: Today's a TTML2 focused call. 15:06:18 .. For the agenda I have CR2 publication, and unresolved HR issues 15:06:23 .. Is there any other business? 15:06:43 group: [no other business] 15:07:01 Cyril: If we have time to talk about shear calculation? 15:07:05 Nigel: We can add that to the agenda 15:07:23 Topic: Publication of updated CR 15:07:35 Nigel: Good news - we got there with CR2, at https://www.w3.org/TR/2021/CR-ttml2-20210309/ 15:07:58 .. I noticed too late that we forgot to put a history link in at the top. 15:08:03 cyril has joined #tt 15:08:14 .. That can go in later, at PR or a CRD if we do one. 15:08:34 Topic: Unresolved horizontal review issues 15:08:56 Nigel: Ralph, in reviewing the CR transition request, noted that there are open HR issues. 15:09:20 Glenn: I closed one of the HR issues after publication had occurred, which was just some clean up work I was doing 15:09:37 .. to create the release entries in GitHub, and clean up any of the milestones for TTML2 CR2. 15:09:55 .. I noticed that there was one review issue that was still logged against that milestone, 15:10:10 .. that seemed to be covered by material we added under the privacy section on fonts, 15:10:23 .. and I see that Nigel reached out to the original commenters to see if they want to add anything further. 15:10:27 .. Are there others? 15:10:41 .. There may be some that were not associated with that milestone. 15:11:26 Nigel: Yes there are. I added them to the agenda. 15:11:54 .. #1211 was split into #1212 and #1213, about writingMode, direction and unicodeBidi on the p element. 15:12:04 .. We tried to resolve that before, and it didn't go well. 15:12:08 .. But it remains open. 15:12:58 .. The other one just to complete the list is #1201 which is above security and privacy risks of insecure transport / mixed content. 15:13:18 .. I have a feeling that is only editorial and is asking to replace any http:// URLs in examples with https:// ones. 15:13:55 .. I think we may have a hard time going to PR if we haven't at least tried to address these in some way. 15:14:15 Glenn: On the first, #1211, it will depend on whether the proposed resolution entails a substantive change or not, 15:14:31 .. as to whether it applies in 2nd Ed. Particularly if there is a change that breaks backwards compatibility. 15:14:55 .. I still have some TBDs to progress some PRs on these after we finished our last round of in-depth discussion on these. 15:15:03 .. I guess the ball is in my court to get some PRs out on them. 15:16:36 Nigel: That would be great if you could. Pierre tried before but we didn't have consensus to merge. 15:16:51 Glenn: It could be that a substantive change needs to go to TTML3. 15:17:10 Nigel: Yes, if it's a breaking change, but I think where we go to is we didn't need that. 15:17:19 Glenn: Okay, I will try to devote some time to opening PRs on this topic. 15:17:27 Nigel: Thank you, I really appreciate that. 15:18:43 .. On #1201, the proposed resolutions are to note non-normatively the risks to confidentiality and integrity, and to change the scheme to https in the examples. 15:18:48 .. Those things both seem achievable. 15:19:02 .. Any volunteers to open a pull request to address that? 15:19:45 Glenn: It would be an easy editorial change to use https in the examples throughout the spec. 15:20:28 Nigel: I may try to pick up this as a PR, but not until the end of next week. 15:20:34 .. If anyone else can, that'd be great too. 15:21:24 .. To me, the non-normative note about risks is the appropriate fix here because we don't talk about transport protocols at all. 15:21:27 Glenn: Yes, agreed. 15:22:52 Nigel: The tool linked below is really helpful - when I reviewed, those issues are the only ones we have to deal with in TTML2 2nd Ed, 15:23:14 .. but if there are any listed as for a later version that we can solve that's okay too of course. 15:23:30 -> https://www.w3.org/PM/horizontal/review.html?shortname=ttml TTML horizontal review issues (all versions) 15:24:20 Topic: Shear calculations and origin of coordinate system. w3c/ttml2#1199 15:24:27 github: https://github.com/w3c/ttml2/issues/1199 15:24:49 Cyril: To explain what happened, on this issue I opened a year ago (and then forgot about): 15:25:07 .. We are now implementing support for TTML2 / IMSC 1.1 on Android came to me independently with the same questions. 15:25:27 .. One question: Is the behaviour of shear influenced by the inline progression direction or the block progression direction? 15:25:45 .. You can ask the question in different ways. Another is: what is a +ve or -ve angle in different writing modes? 15:25:57 .. So 2 days ago I updated the issue with the same question in more details. 15:26:08 .. My conclusion is that we should clarify what is the intention of the shear. 15:26:24 .. It can be done visually with examples for different writing modes if that has an impact. 15:26:40 .. Or we could be more precise mathematically and provide the centre of the orientation and the angle. 15:26:56 Nigel: Note Pierre's useful comment about CSS. 15:27:13 Glenn: What CSS does is irrelevant in this case - it's a skew transformation, so forget about that. 15:27:32 .. I started looking at it and made some progress on drafting an answer to Cyril but I haven't finished it 15:27:44 .. because I wanted to study in detail more the various combinatorics involved. 15:28:00 .. To your question on block shear or paragraph level shear, i.e. tts:shear, at least the origin here was intended 15:28:11 .. to be the origin of the block areas generated by the paragraph. 15:28:25 .. Normally the paragraph will generate one or more outer block areas with line area children. 15:28:41 .. In some implementations it might forgo the intermediate outer block area and just have line area block children. 15:28:57 .. In any case the overall intent, reflected in the sample image that is included in the definition of that property, 15:29:10 .. was that the origin of the generated block area be the origin of the shear transformation, not the centre. 15:29:15 Cyril: Where would the origin be? 15:29:22 .. The top left, the top right corner? 15:29:50 Glenn: In horizontal writing modes and it's left to right as the paragraph level bidi assignment then it would be the top left. 15:30:21 .. If it's horizontal writing mode with right to left as the paragraph level bidi (or an odd number by the bidi algo for the outer p embedding level) 15:30:38 .. then it would be the top right of the block area since you're filling from right to left. At least that was my intention. 15:31:00 .. Then for tblr it would be top left corner, and tbrl it would be top right corner. 15:31:10 .. Does that makes sense or not? 15:31:17 Cyril: I just care about it being clear in the spec. 15:31:29 Glenn: I understand that clarifying the spec is your main goal and I agree with that. 15:31:40 .. But we also probably ought to agree what the correct answer would be as well. 15:31:49 .. I'm open to other possible definitions than the one I just gave. 15:32:05 .. That's the one I happen to have implemented. Others might feel like it's better to argue for a different definition. 15:32:22 Cyril: Another clarifying q. For tbrl, you said the origin would be the top right corner? 15:32:24 Glenn: Correct 15:32:25 pal has joined #tt 15:32:52 Cyril: And the spec says if the ipd corresponds to the y axis then the 2d shear matrix is [...] 15:33:04 .. What would be the x axis in this case, the ipd or as usual pointing to the right? 15:33:30 Glenn: The answer I just gave would have it match the bpd, so if it is right to left then it would be the top right corner. 15:34:04 Cyril: That makes sense because the +ve angle goes from the y axis to the x axis so it looks consistent to me. 15:34:35 Glenn: That's how most implementations would tend to lay out block areas and I believe (haven't verified it) that if we were to go back 15:34:57 .. to look at the definitions of placement of block areas in XSL-FO that would correspond to its model of the origin of those block areas as well. 15:36:06 Nigel: Glenn you dismissed CSS very quickly earlier, but it's surely an important data point. 15:36:18 q+ 15:36:30 Glenn: Not really, in CSS there's a post-processing mapping from shear to skew, and the skew transformation could be used to implement it 15:36:36 .. but as we define the semantics. 15:37:00 Pierre: I'm shocked by this; The spec says the semantic basis for tts:shear is CSS skew, so you can't say that wasn't intended. 15:37:13 Glenn: You have a good point. I don't have the text of the spec in front of me right now. 15:37:35 Pierre: It's under semantic basis for shear derivation it points to skew-x and skew-y. 15:37:49 Glenn: That's something Nigel did, I never looked at that. 15:37:51 q+ 15:37:55 ack p 15:37:58 q- 15:38:12 Pierre: That's what the spec says and what people implemented. 15:38:32 q+ 15:38:32 Glenn: If we inadvertently wrote that then we need to clarify what the derivation means, it could mean "can be mapped to". 15:40:16 Nigel: I don't believe credit or blame is due my way for the mapping from shear to skew. I rearranged the semantic derivation but I don't 15:40:31 .. recall inventing any mappings. 15:40:49 q? 15:40:53 q+ 15:40:56 ack ni 15:40:59 ack p 15:41:09 Pierre: I think the spec is actually quite clear, whether it is right or not. 15:41:18 .. It says semantic derivation and points to skew-x and skew-y 15:41:48 Cyril: I agree with Glenn here, the semantic derivation gives a link, but if you ignore it altogether you can't implement anything! 15:41:54 Pierre: Exactly 15:42:24 Nigel: I think the question here is what should the spec say, and does it say it? 15:42:45 Cyril: The key question is whether the shear direction depends on writing mode. At the moment the spec doesn't say that at all. 15:43:07 .. Since it was not clear, it is unlikely that the implementations are interoperable. We may want to make it match CSS or not. 15:43:28 Glenn: I agree. I think I would try to oppose employing the CSS definition which would be the centre of the block area. 15:43:33 q+ 15:43:49 .. It is clear that one can map a semantic that is based on an origin that is not centre based to a semantic derivation of skew in CSS that 15:44:04 .. is based on centre. But I view that as part of the implementation process of mapping our semantics to CSS in this regard. 15:44:33 .. In my mind, the question, and what I read between the lines is Pierre's suggestion to adopt the CSS semantic of a block centre skew transformation 15:44:39 .. then that would be problematic in my opinion. 15:44:47 q+ 15:45:09 ack p 15:45:31 Pierre: I plan to object strongly to changing the origin to anything other than centre. 15:45:47 Glenn: Until we define it, it is currently undefined. 15:45:57 Pierre: I don't agree with that assessment and I think it is clear what it says in the spec today. 15:46:05 Glenn: You think it is the centre of the block? 15:46:25 Pierre: Yes absolutely. For the record, unless using centre for skew cannot be used in the context of timed text in general my 15:46:32 .. position is that it should be used in general. 15:46:52 Cyril: If you look at the tts:shear example image, I don't know how the centre of the block could be the centre of the transformation 15:46:55 .. in that example. 15:47:27 .. If you take the right side of the image and apply the transformation around the centre without doing any translation, then the right hand 15:47:34 .. kanji would be outside of the region. 15:47:44 Pierre: It's not possible to tell where the origin was in that illustration. 15:47:56 Cyril: I agree there's some ambiguity, but it's not clear. 15:48:09 Pierre: That's why I go back to the semantic derivation. 15:48:31 .. My question is why is centre wrong? It seems to work. Unless there is an argument why it is not good then we should stick with it. 15:48:46 Cyril: To get the example image you'd have to apply some translation (or padding) 15:48:59 Pierre: You'd have to do that regardless to avoid overflowing (loosely) the region. 15:49:44 Nigel: There are two questions: first is the origin of transformation, but the other is the direction of transformation. 15:50:10 .. Do we have any info from CSS on direction? 15:50:18 Pierre: No, on that one, it is much more ambiguous. 15:50:43 Glenn: Another issue: while it is feasible to define the shear in terms of centre for p or line shear, it cannot be used for font shear. 15:51:03 .. You're intent is going to break down at that point, to define a centre based shear model based on skew in CSS. The origin cannot be 15:51:23 .. the centre of the glyph. One could take the semantics we need to define, which is an origin based on its placement on the baseline, 15:51:42 .. and translate that to a centre based skew transformation by appropriate matrix multiplication, but it will make the explanation of it 15:51:53 q+ 15:52:04 .. more complicated if we define it in those terms and at that point we're instructing on how to implement based on CSS which we have 15:52:13 .. not tried to do in general. 15:52:14 ack n 15:52:15 ack p 15:52:30 Pierre: Ideally here the solution is to get a discussion with CSS and find a common acceptable solution. 15:52:49 Glenn: Unless we have nailed down our intended semantics and have a way of documenting that first it will muddy the waters to 15:53:06 .. get involved with CSS. They're not defining shear semantics as far as we know. Are they? 15:54:28 Nigel: I haven't checked JLReq and all the gap documents published by the internationalisation activity, but I would speculate that 15:54:52 .. this would be one of the gaps that would need solving across the web platform, so they likely do want to solve it. 15:55:08 Cyril: I think we should identify what we want for how shear should work and then how to map it onto CSS. 15:55:33 .. One problem I see is we have one way to do block, font or line shear, but to map onto CSS you cannot use the same mechanism for each. 15:55:48 .. For fonts you have to use font-style: oblique; I'm not sure it behaves the same. 15:55:53 Glenn: Does it take an angle? 15:55:59 Cyril: Yes oblique takes an angle parameter 15:56:05 Glenn: Ok I wasn't aware of that 15:56:21 Cyril: That's implemented in Chrome and Firefox and is in CSS, not sure if it is level 3 or 4. 15:56:41 Glenn: I think it's nice to have for people who are basing implementation on CSS, but it's not a necessary part of our semantics as 15:56:50 .. far as I'm concerned, in terms of defining our intentions. 15:57:15 Pierre: My interest is in interoperability and compatibility with the web platform. 15:58:18 Nigel: If we think about this from an authorial and user perspective, rather than a spec-partisan perspective, then we should surely come 15:58:21 .. to the same conclusion. 15:58:39 Glenn: I agree, and did offer to consider other options. 15:59:13 Cyril: In the comments on the issue, the image at the bottom shows a possibility for defining shear not in consistent mathematical terms, 15:59:32 .. depending on the writing mode, another approach is to say "here is what we want to achieve", which could be like italics, where 15:59:57 .. positive shear behaves like italics in horizontal modes, and we can do what we want for vertical, then we can derive the math. 16:00:19 .. Can we agree, forgetting for the time being about tbrl, that the three images are what we want? 16:00:29 .. tbrl has positive shear pointing to bottom left. 16:00:37 .. lr has positive shear pointing to top right 16:00:45 .. rl has positive shear pointing to top left. 16:01:00 .. If we can agree on that then we can decide if we need translation or scaling or padding or whatever. 16:02:09 Nigel: My assumption is that shear line layout occurs post-shear not pre-shear. Is that controversial? 16:02:23 Glenn: I think that's an implementation issue. We should review. 16:02:45 .. The semantics of laying out the line areas in XSL-FO, close to CSS 2.1, is based on a non-shear model, so the packing or stacking of 16:03:09 .. blocks and inline areas with glyph areas assume a certain model but different implementations can take different approaches. 16:03:22 atai has joined #tt 16:03:35 .. For example one implementation might compute and create state information for laying out the glyphs in a line area based on advances 16:03:44 .. alone possibly in association with baseline shifts. 16:04:06 .. But when they actually paint those glyphs they might paint them from one or the other direction by recalculating those advances. 16:04:33 .. For example if you're painting a paragraph that's rtl you might output the glyphs in rtl display order which might match reading order 16:04:52 .. or you might output them in ltr order opposite to reading order. As long as the eventual position of the glyphs match up. 16:05:11 .. This has an impact on how things like PDF files store information for accessibility purposes, when those glyphs are recombined for 16:05:20 .. operations like find. It is implementation dependent. 16:05:21 q? 16:05:45 Cyril: Implementations can certainly do different things. The question is the interoperability. How do we achieve it? 16:06:10 .. We should specify something but the question Nigel raised is important because if you apply layout first and then shear you might have 16:06:33 .. overlap in terms of glyphs. So Nigel I think we should agree on the visual aspects of the transformation, how it should look, then agree 16:06:54 .. on the layout, how is it placed with respect to other text or objects, and then translate that into specification math. 16:07:16 .. For example in terms of layout one big difference between using the centre vs a corner for transformation, unless you apply padding or 16:07:33 .. scaling, if you use the centre of the block you may have glyphs moving outside the original box. And that affects layout. 16:07:58 Glenn: Even if you use a corner, if you do not reduce your line measure and adjust accordingly then you may overflow on one side or the other 16:08:07 .. of the line areas. 16:08:11 Nigel: I was about to say that 16:08:16 Cyril: Only on one edge, right? 16:08:56 Glenn: In the implementation I did I take the shear into account of the length of the original line area, and reduce it in order to keep the 16:09:16 .. aligned measure within the outer block area, without overflowing. I don't take into account any other consideration at that point. 16:09:36 .. Then I lay out without shear, mark the line area as having shear applied, and then apply the skew transformation when rendering the line. 16:09:47 .. In my case I apply the skew not based on the centre. 16:10:36 SUMMARY: We need to work out what we want it to do before any detailed specification. 16:10:57 Glenn: It gets more complicated if different segments on a line have different shear direction. To prevent them from colliding you need to 16:11:19 .. temporarily increase the space between them in order to avoid collision. Since we can specify font-shear on a character by character basis 16:12:54 .. that means that different characters on a line may have different shears and spacing. 16:13:19 Topic: Meeting close 16:13:41 Nigel: Thanks everyone, apologies if there was some confusion about the timing of this meeting. We're out of time so I'll adjourn now. 16:13:45 .. [adjourns meeting] 16:13:51 rrsagent, make minutes v2 16:13:51 I have made the request to generate https://www.w3.org/2021/03/18-tt-minutes.html nigel 16:13:55 ahhhh, sorry I forgot that! 17:14:52 scribeOptions: -final -noEmbedDiagnostics 17:14:56 zakim, end meeting 17:14:56 As of this point the attendees have been Pierre, Nigel, Glenn, Cyril 17:14:57 RRSAgent, please draft minutes v2 17:14:57 I have made the request to generate https://www.w3.org/2021/03/18-tt-minutes.html Zakim 17:15:01 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 17:15:05 Zakim has left #tt 17:49:42 rrsagent, excuse us 17:49:42 I see no action items