Meeting minutes
This meeting
Nigel: Today's a TTML2 focused call.
… For the agenda I have CR2 publication, and unresolved HR issues
… Is there any other business?
group: [no other business]
Cyril: If we have time to talk about shear calculation?
Nigel: We can add that to the agenda
Publication of updated CR
Nigel: Good news - we got there with CR2, at https://
… I noticed too late that we forgot to put a history link in at the top.
… That can go in later, at PR or a CRD if we do one.
Unresolved horizontal review issues
Nigel: Ralph, in reviewing the CR transition request, noted that there are open HR issues.
Glenn: I closed one of the HR issues after publication had occurred, which was just some clean up work I was doing
… to create the release entries in GitHub, and clean up any of the milestones for TTML2 CR2.
… I noticed that there was one review issue that was still logged against that milestone,
… that seemed to be covered by material we added under the privacy section on fonts,
… and I see that Nigel reached out to the original commenters to see if they want to add anything further.
… Are there others?
… There may be some that were not associated with that milestone.
Nigel: Yes there are. I added them to the agenda.
… #1211 was split into #1212 and #1213, about writingMode, direction and unicodeBidi on the p element.
… We tried to resolve that before, and it didn't go well.
… But it remains open.
… The other one just to complete the list is #1201 which is above security and privacy risks of insecure transport / mixed content.
… I have a feeling that is only editorial and is asking to replace any http:// URLs in examples with https:// ones.
… I think we may have a hard time going to PR if we haven't at least tried to address these in some way.
Glenn: On the first, #1211, it will depend on whether the proposed resolution entails a substantive change or not,
… as to whether it applies in 2nd Ed. Particularly if there is a change that breaks backwards compatibility.
… I still have some TBDs to progress some PRs on these after we finished our last round of in-depth discussion on these.
… I guess the ball is in my court to get some PRs out on them.
Nigel: That would be great if you could. Pierre tried before but we didn't have consensus to merge.
Glenn: It could be that a substantive change needs to go to TTML3.
Nigel: Yes, if it's a breaking change, but I think where we go to is we didn't need that.
Glenn: Okay, I will try to devote some time to opening PRs on this topic.
Nigel: Thank you, I really appreciate that.
… 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.
… Those things both seem achievable.
… Any volunteers to open a pull request to address that?
Glenn: It would be an easy editorial change to use https in the examples throughout the spec.
Nigel: I may try to pick up this as a PR, but not until the end of next week.
… If anyone else can, that'd be great too.
… To me, the non-normative note about risks is the appropriate fix here because we don't talk about transport protocols at all.
Glenn: Yes, agreed.
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,
… but if there are any listed as for a later version that we can solve that's okay too of course.
Shear calculations and origin of coordinate system. w3c/ttml2#1199
github: https://
Cyril: To explain what happened, on this issue I opened a year ago (and then forgot about):
… We are now implementing support for TTML2 / IMSC 1.1 on Android came to me independently with the same questions.
… One question: Is the behaviour of shear influenced by the inline progression direction or the block progression direction?
… You can ask the question in different ways. Another is: what is a +ve or -ve angle in different writing modes?
… So 2 days ago I updated the issue with the same question in more details.
… My conclusion is that we should clarify what is the intention of the shear.
… It can be done visually with examples for different writing modes if that has an impact.
… Or we could be more precise mathematically and provide the centre of the orientation and the angle.
Nigel: Note Pierre's useful comment about CSS.
Glenn: What CSS does is irrelevant in this case - it's a skew transformation, so forget about that.
… I started looking at it and made some progress on drafting an answer to Cyril but I haven't finished it
… because I wanted to study in detail more the various combinatorics involved.
… To your question on block shear or paragraph level shear, i.e. tts:shear, at least the origin here was intended
… to be the origin of the block areas generated by the paragraph.
… Normally the paragraph will generate one or more outer block areas with line area children.
… In some implementations it might forgo the intermediate outer block area and just have line area block children.
… In any case the overall intent, reflected in the sample image that is included in the definition of that property,
… was that the origin of the generated block area be the origin of the shear transformation, not the centre.
Cyril: Where would the origin be?
… The top left, the top right corner?
Glenn: In horizontal writing modes and it's left to right as the paragraph level bidi assignment then it would be the top left.
… 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)
… 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.
… Then for tblr it would be top left corner, and tbrl it would be top right corner.
… Does that makes sense or not?
Cyril: I just care about it being clear in the spec.
Glenn: I understand that clarifying the spec is your main goal and I agree with that.
… But we also probably ought to agree what the correct answer would be as well.
… I'm open to other possible definitions than the one I just gave.
… That's the one I happen to have implemented. Others might feel like it's better to argue for a different definition.
Cyril: Another clarifying q. For tbrl, you said the origin would be the top right corner?
Glenn: Correct
Cyril: And the spec says if the ipd corresponds to the y axis then the 2d shear matrix is [...]
… What would be the x axis in this case, the ipd or as usual pointing to the right?
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.
Cyril: That makes sense because the +ve angle goes from the y axis to the x axis so it looks consistent to me.
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
… 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.
Nigel: Glenn you dismissed CSS very quickly earlier, but it's surely an important data point.
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
… but as we define the semantics.
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.
Glenn: You have a good point. I don't have the text of the spec in front of me right now.
Pierre: It's under semantic basis for shear derivation it points to skew-x and skew-y.
Glenn: That's something Nigel did, I never looked at that.
Pierre: That's what the spec says and what people implemented.
Glenn: If we inadvertently wrote that then we need to clarify what the derivation means, it could mean "can be mapped to".
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
… recall inventing any mappings.
Pierre: I think the spec is actually quite clear, whether it is right or not.
… It says semantic derivation and points to skew-x and skew-y
Cyril: I agree with Glenn here, the semantic derivation gives a link, but if you ignore it altogether you can't implement anything!
Pierre: Exactly
Nigel: I think the question here is what should the spec say, and does it say it?
Cyril: The key question is whether the shear direction depends on writing mode. At the moment the spec doesn't say that at all.
… Since it was not clear, it is unlikely that the implementations are interoperable. We may want to make it match CSS or not.
Glenn: I agree. I think I would try to oppose employing the CSS definition which would be the centre of the block area.
… 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
… is based on centre. But I view that as part of the implementation process of mapping our semantics to CSS in this regard.
… 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
… then that would be problematic in my opinion.
Pierre: I plan to object strongly to changing the origin to anything other than centre.
Glenn: Until we define it, it is currently undefined.
Pierre: I don't agree with that assessment and I think it is clear what it says in the spec today.
Glenn: You think it is the centre of the block?
Pierre: Yes absolutely. For the record, unless using centre for skew cannot be used in the context of timed text in general my
… position is that it should be used in general.
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
… in that example.
… If you take the right side of the image and apply the transformation around the centre without doing any translation, then the right hand
… kanji would be outside of the region.
Pierre: It's not possible to tell where the origin was in that illustration.
Cyril: I agree there's some ambiguity, but it's not clear.
Pierre: That's why I go back to the semantic derivation.
… 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.
Cyril: To get the example image you'd have to apply some translation (or padding)
Pierre: You'd have to do that regardless to avoid overflowing (loosely) the region.
Nigel: There are two questions: first is the origin of transformation, but the other is the direction of transformation.
… Do we have any info from CSS on direction?
Pierre: No, on that one, it is much more ambiguous.
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.
… 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
… 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,
… and translate that to a centre based skew transformation by appropriate matrix multiplication, but it will make the explanation of it
… 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
… not tried to do in general.
Pierre: Ideally here the solution is to get a discussion with CSS and find a common acceptable solution.
Glenn: Unless we have nailed down our intended semantics and have a way of documenting that first it will muddy the waters to
… get involved with CSS. They're not defining shear semantics as far as we know. Are they?
Nigel: I haven't checked JLReq and all the gap documents published by the internationalisation activity, but I would speculate that
… this would be one of the gaps that would need solving across the web platform, so they likely do want to solve it.
Cyril: I think we should identify what we want for how shear should work and then how to map it onto CSS.
… 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.
… For fonts you have to use font-style: oblique; I'm not sure it behaves the same.
Glenn: Does it take an angle?
Cyril: Yes oblique takes an angle parameter
Glenn: Ok I wasn't aware of that
Cyril: That's implemented in Chrome and Firefox and is in CSS, not sure if it is level 3 or 4.
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
… far as I'm concerned, in terms of defining our intentions.
Pierre: My interest is in interoperability and compatibility with the web platform.
Nigel: If we think about this from an authorial and user perspective, rather than a spec-partisan perspective, then we should surely come
… to the same conclusion.
Glenn: I agree, and did offer to consider other options.
Cyril: In the comments on the issue, the image at the bottom shows a possibility for defining shear not in consistent mathematical terms,
… depending on the writing mode, another approach is to say "here is what we want to achieve", which could be like italics, where
… positive shear behaves like italics in horizontal modes, and we can do what we want for vertical, then we can derive the math.
… Can we agree, forgetting for the time being about tbrl, that the three images are what we want?
… tbrl has positive shear pointing to bottom left.
… lr has positive shear pointing to top right
… rl has positive shear pointing to top left.
… If we can agree on that then we can decide if we need translation or scaling or padding or whatever.
Nigel: My assumption is that shear line layout occurs post-shear not pre-shear. Is that controversial?
Glenn: I think that's an implementation issue. We should review.
… 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
… blocks and inline areas with glyph areas assume a certain model but different implementations can take different approaches.
… For example one implementation might compute and create state information for laying out the glyphs in a line area based on advances
… alone possibly in association with baseline shifts.
… But when they actually paint those glyphs they might paint them from one or the other direction by recalculating those advances.
… 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
… or you might output them in ltr order opposite to reading order. As long as the eventual position of the glyphs match up.
… This has an impact on how things like PDF files store information for accessibility purposes, when those glyphs are recombined for
… operations like find. It is implementation dependent.
Cyril: Implementations can certainly do different things. The question is the interoperability. How do we achieve it?
… We should specify something but the question Nigel raised is important because if you apply layout first and then shear you might have
… 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
… on the layout, how is it placed with respect to other text or objects, and then translate that into specification math.
… For example in terms of layout one big difference between using the centre vs a corner for transformation, unless you apply padding or
… scaling, if you use the centre of the block you may have glyphs moving outside the original box. And that affects layout.
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
… of the line areas.
Nigel: I was about to say that
Cyril: Only on one edge, right?
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
… aligned measure within the outer block area, without overflowing. I don't take into account any other consideration at that point.
… Then I lay out without shear, mark the line area as having shear applied, and then apply the skew transformation when rendering the line.
… In my case I apply the skew not based on the centre.
SUMMARY: We need to work out what we want it to do before any detailed specification.
Glenn: It gets more complicated if different segments on a line have different shear direction. To prevent them from colliding you need to
… temporarily increase the space between them in order to avoid collision. Since we can specify font-shear on a character by character basis
… that means that different characters on a line may have different shears and spacing.
Meeting close
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.
… [adjourns meeting]
<atsushi> ahhhh, sorry I forgot that!