IRC log of tt on 2021-03-18

Timestamps are in UTC.

15:00:55 [RRSAgent]
RRSAgent has joined #tt
15:00:55 [RRSAgent]
logging to https://www.w3.org/2021/03/18-tt-irc
15:01:01 [Zakim]
RRSAgent, make logs Public
15:01:03 [Zakim]
Meeting: Timed Text Working Group Teleconference
15:01:13 [nigel]
Present: Pierre, Nigel
15:01:16 [nigel]
scribe: nigel
15:01:21 [nigel]
Chair: Nigel
15:01:27 [nigel]
Regrets: Atsushi, Gary
15:01:40 [nigel]
Previous meeting: https://www.w3.org/2021/03/04-tt-minutes.html
15:01:46 [nigel]
Agenda: https://github.com/w3c/ttwg/issues/176
15:03:47 [nigel]
Present+ Glenn
15:05:05 [nigel]
Topic: This meeting
15:05:39 [nigel]
Present+ Cyril
15:06:01 [nigel]
Nigel: Today's a TTML2 focused call.
15:06:18 [nigel]
.. For the agenda I have CR2 publication, and unresolved HR issues
15:06:23 [nigel]
.. Is there any other business?
15:06:43 [nigel]
group: [no other business]
15:07:01 [nigel]
Cyril: If we have time to talk about shear calculation?
15:07:05 [nigel]
Nigel: We can add that to the agenda
15:07:23 [nigel]
Topic: Publication of updated CR
15:07:35 [nigel]
Nigel: Good news - we got there with CR2, at https://www.w3.org/TR/2021/CR-ttml2-20210309/
15:07:58 [nigel]
.. I noticed too late that we forgot to put a history link in at the top.
15:08:03 [cyril]
cyril has joined #tt
15:08:14 [nigel]
.. That can go in later, at PR or a CRD if we do one.
15:08:34 [nigel]
Topic: Unresolved horizontal review issues
15:08:56 [nigel]
Nigel: Ralph, in reviewing the CR transition request, noted that there are open HR issues.
15:09:20 [nigel]
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 [nigel]
.. to create the release entries in GitHub, and clean up any of the milestones for TTML2 CR2.
15:09:55 [nigel]
.. I noticed that there was one review issue that was still logged against that milestone,
15:10:10 [nigel]
.. that seemed to be covered by material we added under the privacy section on fonts,
15:10:23 [nigel]
.. and I see that Nigel reached out to the original commenters to see if they want to add anything further.
15:10:27 [nigel]
.. Are there others?
15:10:41 [nigel]
.. There may be some that were not associated with that milestone.
15:11:26 [nigel]
Nigel: Yes there are. I added them to the agenda.
15:11:54 [nigel]
.. #1211 was split into #1212 and #1213, about writingMode, direction and unicodeBidi on the p element.
15:12:04 [nigel]
.. We tried to resolve that before, and it didn't go well.
15:12:08 [nigel]
.. But it remains open.
15:12:58 [nigel]
.. 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 [nigel]
.. I have a feeling that is only editorial and is asking to replace any http:// URLs in examples with https:// ones.
15:13:55 [nigel]
.. 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 [nigel]
Glenn: On the first, #1211, it will depend on whether the proposed resolution entails a substantive change or not,
15:14:31 [nigel]
.. as to whether it applies in 2nd Ed. Particularly if there is a change that breaks backwards compatibility.
15:14:55 [nigel]
.. 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 [nigel]
.. I guess the ball is in my court to get some PRs out on them.
15:16:36 [nigel]
Nigel: That would be great if you could. Pierre tried before but we didn't have consensus to merge.
15:16:51 [nigel]
Glenn: It could be that a substantive change needs to go to TTML3.
15:17:10 [nigel]
Nigel: Yes, if it's a breaking change, but I think where we go to is we didn't need that.
15:17:19 [nigel]
Glenn: Okay, I will try to devote some time to opening PRs on this topic.
15:17:27 [nigel]
Nigel: Thank you, I really appreciate that.
15:18:43 [nigel]
.. 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 [nigel]
.. Those things both seem achievable.
15:19:02 [nigel]
.. Any volunteers to open a pull request to address that?
15:19:45 [nigel]
Glenn: It would be an easy editorial change to use https in the examples throughout the spec.
15:20:28 [nigel]
Nigel: I may try to pick up this as a PR, but not until the end of next week.
15:20:34 [nigel]
.. If anyone else can, that'd be great too.
15:21:24 [nigel]
.. 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 [nigel]
Glenn: Yes, agreed.
15:22:52 [nigel]
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 [nigel]
.. but if there are any listed as for a later version that we can solve that's okay too of course.
15:23:30 [nigel]
-> https://www.w3.org/PM/horizontal/review.html?shortname=ttml TTML horizontal review issues (all versions)
15:24:20 [nigel]
Topic: Shear calculations and origin of coordinate system. w3c/ttml2#1199
15:24:27 [nigel]
github: https://github.com/w3c/ttml2/issues/1199
15:24:49 [nigel]
Cyril: To explain what happened, on this issue I opened a year ago (and then forgot about):
15:25:07 [nigel]
.. We are now implementing support for TTML2 / IMSC 1.1 on Android came to me independently with the same questions.
15:25:27 [nigel]
.. One question: Is the behaviour of shear influenced by the inline progression direction or the block progression direction?
15:25:45 [nigel]
.. You can ask the question in different ways. Another is: what is a +ve or -ve angle in different writing modes?
15:25:57 [nigel]
.. So 2 days ago I updated the issue with the same question in more details.
15:26:08 [nigel]
.. My conclusion is that we should clarify what is the intention of the shear.
15:26:24 [nigel]
.. It can be done visually with examples for different writing modes if that has an impact.
15:26:40 [nigel]
.. Or we could be more precise mathematically and provide the centre of the orientation and the angle.
15:26:56 [nigel]
Nigel: Note Pierre's useful comment about CSS.
15:27:13 [nigel]
Glenn: What CSS does is irrelevant in this case - it's a skew transformation, so forget about that.
15:27:32 [nigel]
.. I started looking at it and made some progress on drafting an answer to Cyril but I haven't finished it
15:27:44 [nigel]
.. because I wanted to study in detail more the various combinatorics involved.
15:28:00 [nigel]
.. To your question on block shear or paragraph level shear, i.e. tts:shear, at least the origin here was intended
15:28:11 [nigel]
.. to be the origin of the block areas generated by the paragraph.
15:28:25 [nigel]
.. Normally the paragraph will generate one or more outer block areas with line area children.
15:28:41 [nigel]
.. In some implementations it might forgo the intermediate outer block area and just have line area block children.
15:28:57 [nigel]
.. In any case the overall intent, reflected in the sample image that is included in the definition of that property,
15:29:10 [nigel]
.. was that the origin of the generated block area be the origin of the shear transformation, not the centre.
15:29:15 [nigel]
Cyril: Where would the origin be?
15:29:22 [nigel]
.. The top left, the top right corner?
15:29:50 [nigel]
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 [nigel]
.. 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 [nigel]
.. 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 [nigel]
.. Then for tblr it would be top left corner, and tbrl it would be top right corner.
15:31:10 [nigel]
.. Does that makes sense or not?
15:31:17 [nigel]
Cyril: I just care about it being clear in the spec.
15:31:29 [nigel]
Glenn: I understand that clarifying the spec is your main goal and I agree with that.
15:31:40 [nigel]
.. But we also probably ought to agree what the correct answer would be as well.
15:31:49 [nigel]
.. I'm open to other possible definitions than the one I just gave.
15:32:05 [nigel]
.. 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 [nigel]
Cyril: Another clarifying q. For tbrl, you said the origin would be the top right corner?
15:32:24 [nigel]
Glenn: Correct
15:32:25 [pal]
pal has joined #tt
15:32:52 [nigel]
Cyril: And the spec says if the ipd corresponds to the y axis then the 2d shear matrix is [...]
15:33:04 [nigel]
.. What would be the x axis in this case, the ipd or as usual pointing to the right?
15:33:30 [nigel]
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 [nigel]
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 [nigel]
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 [nigel]
.. 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]
Nigel: Glenn you dismissed CSS very quickly earlier, but it's surely an important data point.
15:36:18 [pal]
q+
15:36:30 [nigel]
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 [nigel]
.. but as we define the semantics.
15:37:00 [nigel]
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 [nigel]
Glenn: You have a good point. I don't have the text of the spec in front of me right now.
15:37:35 [nigel]
Pierre: It's under semantic basis for shear derivation it points to skew-x and skew-y.
15:37:49 [nigel]
Glenn: That's something Nigel did, I never looked at that.
15:37:51 [nigel]
q+
15:37:55 [nigel]
ack p
15:37:58 [pal]
q-
15:38:12 [nigel]
Pierre: That's what the spec says and what people implemented.
15:38:32 [pal]
q+
15:38:32 [nigel]
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]
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 [nigel]
.. recall inventing any mappings.
15:40:49 [nigel]
q?
15:40:53 [pal]
q+
15:40:56 [nigel]
ack ni
15:40:59 [nigel]
ack p
15:41:09 [nigel]
Pierre: I think the spec is actually quite clear, whether it is right or not.
15:41:18 [nigel]
.. It says semantic derivation and points to skew-x and skew-y
15:41:48 [nigel]
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 [nigel]
Pierre: Exactly
15:42:24 [nigel]
Nigel: I think the question here is what should the spec say, and does it say it?
15:42:45 [nigel]
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 [nigel]
.. 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 [nigel]
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 [pal]
q+
15:43:49 [nigel]
.. 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 [nigel]
.. 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 [nigel]
.. 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 [nigel]
.. then that would be problematic in my opinion.
15:44:47 [nigel]
q+
15:45:09 [nigel]
ack p
15:45:31 [nigel]
Pierre: I plan to object strongly to changing the origin to anything other than centre.
15:45:47 [nigel]
Glenn: Until we define it, it is currently undefined.
15:45:57 [nigel]
Pierre: I don't agree with that assessment and I think it is clear what it says in the spec today.
15:46:05 [nigel]
Glenn: You think it is the centre of the block?
15:46:25 [nigel]
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 [nigel]
.. position is that it should be used in general.
15:46:52 [nigel]
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 [nigel]
.. in that example.
15:47:27 [nigel]
.. 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 [nigel]
.. kanji would be outside of the region.
15:47:44 [nigel]
Pierre: It's not possible to tell where the origin was in that illustration.
15:47:56 [nigel]
Cyril: I agree there's some ambiguity, but it's not clear.
15:48:09 [nigel]
Pierre: That's why I go back to the semantic derivation.
15:48:31 [nigel]
.. 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 [nigel]
Cyril: To get the example image you'd have to apply some translation (or padding)
15:48:59 [nigel]
Pierre: You'd have to do that regardless to avoid overflowing (loosely) the region.
15:49:44 [nigel]
Nigel: There are two questions: first is the origin of transformation, but the other is the direction of transformation.
15:50:10 [nigel]
.. Do we have any info from CSS on direction?
15:50:18 [nigel]
Pierre: No, on that one, it is much more ambiguous.
15:50:43 [nigel]
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 [nigel]
.. 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 [nigel]
.. 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 [nigel]
.. and translate that to a centre based skew transformation by appropriate matrix multiplication, but it will make the explanation of it
15:51:53 [pal]
q+
15:52:04 [nigel]
.. 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 [nigel]
.. not tried to do in general.
15:52:14 [nigel]
ack n
15:52:15 [nigel]
ack p
15:52:30 [nigel]
Pierre: Ideally here the solution is to get a discussion with CSS and find a common acceptable solution.
15:52:49 [nigel]
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 [nigel]
.. get involved with CSS. They're not defining shear semantics as far as we know. Are they?
15:54:28 [nigel]
Nigel: I haven't checked JLReq and all the gap documents published by the internationalisation activity, but I would speculate that
15:54:52 [nigel]
.. 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 [nigel]
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 [nigel]
.. 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 [nigel]
.. For fonts you have to use font-style: oblique; I'm not sure it behaves the same.
15:55:53 [nigel]
Glenn: Does it take an angle?
15:55:59 [nigel]
Cyril: Yes oblique takes an angle parameter
15:56:05 [nigel]
Glenn: Ok I wasn't aware of that
15:56:21 [nigel]
Cyril: That's implemented in Chrome and Firefox and is in CSS, not sure if it is level 3 or 4.
15:56:41 [nigel]
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 [nigel]
.. far as I'm concerned, in terms of defining our intentions.
15:57:15 [nigel]
Pierre: My interest is in interoperability and compatibility with the web platform.
15:58:18 [nigel]
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 [nigel]
.. to the same conclusion.
15:58:39 [nigel]
Glenn: I agree, and did offer to consider other options.
15:59:13 [nigel]
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 [nigel]
.. 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 [nigel]
.. 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 [nigel]
.. Can we agree, forgetting for the time being about tbrl, that the three images are what we want?
16:00:29 [nigel]
.. tbrl has positive shear pointing to bottom left.
16:00:37 [nigel]
.. lr has positive shear pointing to top right
16:00:45 [nigel]
.. rl has positive shear pointing to top left.
16:01:00 [nigel]
.. If we can agree on that then we can decide if we need translation or scaling or padding or whatever.
16:02:09 [nigel]
Nigel: My assumption is that shear line layout occurs post-shear not pre-shear. Is that controversial?
16:02:23 [nigel]
Glenn: I think that's an implementation issue. We should review.
16:02:45 [nigel]
.. 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 [nigel]
.. blocks and inline areas with glyph areas assume a certain model but different implementations can take different approaches.
16:03:22 [atai]
atai has joined #tt
16:03:35 [nigel]
.. 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 [nigel]
.. alone possibly in association with baseline shifts.
16:04:06 [nigel]
.. But when they actually paint those glyphs they might paint them from one or the other direction by recalculating those advances.
16:04:33 [nigel]
.. 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 [nigel]
.. 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 [nigel]
.. This has an impact on how things like PDF files store information for accessibility purposes, when those glyphs are recombined for
16:05:20 [nigel]
.. operations like find. It is implementation dependent.
16:05:21 [nigel]
q?
16:05:45 [nigel]
Cyril: Implementations can certainly do different things. The question is the interoperability. How do we achieve it?
16:06:10 [nigel]
.. 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 [nigel]
.. 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 [nigel]
.. on the layout, how is it placed with respect to other text or objects, and then translate that into specification math.
16:07:16 [nigel]
.. 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 [nigel]
.. 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 [nigel]
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 [nigel]
.. of the line areas.
16:08:11 [nigel]
Nigel: I was about to say that
16:08:16 [nigel]
Cyril: Only on one edge, right?
16:08:56 [nigel]
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 [nigel]
.. aligned measure within the outer block area, without overflowing. I don't take into account any other consideration at that point.
16:09:36 [nigel]
.. 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 [nigel]
.. In my case I apply the skew not based on the centre.
16:10:36 [nigel]
SUMMARY: We need to work out what we want it to do before any detailed specification.
16:10:57 [nigel]
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 [nigel]
.. 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 [nigel]
.. that means that different characters on a line may have different shears and spacing.
16:13:19 [nigel]
Topic: Meeting close
16:13:41 [nigel]
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 [nigel]
.. [adjourns meeting]
16:13:51 [nigel]
rrsagent, make minutes v2
16:13:51 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/03/18-tt-minutes.html nigel
16:13:55 [atsushi]
ahhhh, sorry I forgot that!
17:14:52 [nigel]
scribeOptions: -final -noEmbedDiagnostics
17:14:56 [nigel]
zakim, end meeting
17:14:56 [Zakim]
As of this point the attendees have been Pierre, Nigel, Glenn, Cyril
17:14:57 [Zakim]
RRSAgent, please draft minutes v2
17:14:57 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/03/18-tt-minutes.html Zakim
17:15:01 [Zakim]
I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye
17:15:05 [Zakim]
Zakim has left #tt
17:49:42 [nigel]
rrsagent, excuse us
17:49:42 [RRSAgent]
I see no action items