Shear calculations and origin of coordinate system.

TTML2 specifies how to perform shear calculations, in which it gives the transformation matrix to apply. However, it does not specify the origin of the coordinate system. This was discussed in the TTWG here. If we cannot agree on spec text for the positioning of the origin, I'd suggest at least adding a note indicating:
a) differences if any in the origin selection between shear, lineShear and fontShear;
b) properties that may affect it (e.g. writingMode, textAlign/multiRowAlign, textCombine, ...)
c) that it may have consequences on layout and that there may be differences between implementations

Following up on this topic, while implementing it, a colleague independently came to the same conclusion that the spec was ambiguous. There are several points of ambiguity:

Origin of the coordinate system for the shear transformation

Let's focus on tts:shear and with a tblr writing mode. This is the example given at https://www.w3.org/TR/ttml2/#style-attribute-shear. Is the origin of the shear transformation the top-right corner of the block areas generated by the paragraph? Or is it the center of those block areas? Note that the end result would only differ by a translation, and that has an impact on how the sheared text is placed compared to other elements (other paragraphs, other regions, ...). Also if you look at the example figure in tts:shear, it is not easy to tell because the skewed rectangle has been squeezed to fit in the original region dimension (or so it seems and indicated in the note).

Angle orientation

For vertical text, the spec says:

If the inline progression direction corresponds to the Y axis, then the 2D shear transformation is described by the following matrix:
| 1 0 0 |
| a 1 0 |
| 0 0 1 |

It does not indicate how the X axis is oriented.

One interpretation could be that the X axis corresponds to the block progression direction (i.e. pointing towards the left in tbrl), in which case, a positive angle (i.e. going from X to Y) would be counter-clockwise. So assume a positive shear percentage, i.e. a positive shear angle, i.e. a > 0 in the above matrix, then y' = y + a*x, means that y' > y when x is positive. This seems to correspond to the image in the example in https://www.w3.org/TR/ttml2/#style-attribute-shear. Note that to provide the same rendering in CSS you have to use a negative angle (i.e. skewY(-15deg)).

Another interpretation could be that X axis is always oriented to the right of the screen, but in this case, to produce the correct rendering, you'd have to use a negative angle value.

Summary:

We should clarify:

where the center of the shear transformation is and if it depends or not on the writing mode, which will clarify the placement of sheared text wrt the rest of the content
if the orientation of the axes of the shear transformation depend or not on the writing mode, which will in effect tell the orientation of positive angles (clockwise of counter-clockwise on the end user screen).

If we decide to make these 2 parameters writing-mode dependent, the image below tries to illustrate what using a positive value for shear would do, trying to match what italic does for horizontal text, and what users expect in Japanese text. Not sure what to do with tblr.

Or is it the center of those block areas?

CSS specifies that the origin of the skew transformation is center of the block area (see transform-origin).

The Timed Text Working Group just discussed Shear calculations and origin of coordinate system. w3c/ttml2#1199, and agreed to the following:

SUMMARY: We need to work out what we want it to do before any detailed specification.

The full IRC log of that discussion

<nigel> Topic: Shear calculations and origin of coordinate system. #1199
<nigel> github: https://github.com//issues/1199
<nigel> Cyril: To explain what happened, on this issue I opened a year ago (and then forgot about):
<nigel> .. We are now implementing support for TTML2 / IMSC 1.1 on Android came to me independently with the same questions.
<nigel> .. One question: Is the behaviour of shear influenced by the inline progression direction or the block progression direction?
<nigel> .. You can ask the question in different ways. Another is: what is a +ve or -ve angle in different writing modes?
<nigel> .. So 2 days ago I updated the issue with the same question in more details.
<nigel> .. My conclusion is that we should clarify what is the intention of the shear.
<nigel> .. It can be done visually with examples for different writing modes if that has an impact.
<nigel> .. Or we could be more precise mathematically and provide the centre of the orientation and the angle.
<nigel> Nigel: Note Pierre's useful comment about CSS.
<nigel> Glenn: What CSS does is irrelevant in this case - it's a skew transformation, so forget about that.
<nigel> .. I started looking at it and made some progress on drafting an answer to Cyril but I haven't finished it
<nigel> .. because I wanted to study in detail more the various combinatorics involved.
<nigel> .. To your question on block shear or paragraph level shear, i.e. tts:shear, at least the origin here was intended
<nigel> .. to be the origin of the block areas generated by the paragraph.
<nigel> .. Normally the paragraph will generate one or more outer block areas with line area children.
<nigel> .. In some implementations it might forgo the intermediate outer block area and just have line area block children.
<nigel> .. In any case the overall intent, reflected in the sample image that is included in the definition of that property,
<nigel> .. was that the origin of the generated block area be the origin of the shear transformation, not the centre.
<nigel> Cyril: Where would the origin be?
<nigel> .. The top left, the top right corner?
<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.
<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)
<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.
<nigel> .. Then for tblr it would be top left corner, and tbrl it would be top right corner.
<nigel> .. Does that makes sense or not?
<nigel> Cyril: I just care about it being clear in the spec.
<nigel> Glenn: I understand that clarifying the spec is your main goal and I agree with that.
<nigel> .. But we also probably ought to agree what the correct answer would be as well.
<nigel> .. I'm open to other possible definitions than the one I just gave.
<nigel> .. That's the one I happen to have implemented. Others might feel like it's better to argue for a different definition.
<nigel> Cyril: Another clarifying q. For tbrl, you said the origin would be the top right corner?
<nigel> Glenn: Correct
<nigel> Cyril: And the spec says if the ipd corresponds to the y axis then the 2d shear matrix is [...]
<nigel> .. What would be the x axis in this case, the ipd or as usual pointing to the right?
<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.
<nigel> Cyril: That makes sense because the +ve angle goes from the y axis to the x axis so it looks consistent to me.
<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
<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.
<nigel> Nigel: Glenn you dismissed CSS very quickly earlier, but it's surely an important data point.
<pal> q+
<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
<nigel> .. but as we define the semantics.
<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.
<nigel> Glenn: You have a good point. I don't have the text of the spec in front of me right now.
<nigel> Pierre: It's under semantic basis for shear derivation it points to skew-x and skew-y.
<nigel> Glenn: That's something Nigel did, I never looked at that.
<nigel> q+
<nigel> ack p
<pal> q-
<nigel> Pierre: That's what the spec says and what people implemented.
<pal> q+
<nigel> Glenn: If we inadvertently wrote that then we need to clarify what the derivation means, it could mean "can be mapped to".
<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
<nigel> .. recall inventing any mappings.
<nigel> q?
<pal> q+
<nigel> ack ni
<nigel> ack p
<nigel> Pierre: I think the spec is actually quite clear, whether it is right or not.
<nigel> .. It says semantic derivation and points to skew-x and skew-y
<nigel> Cyril: I agree with Glenn here, the semantic derivation gives a link, but if you ignore it altogether you can't implement anything!
<nigel> Pierre: Exactly
<nigel> Nigel: I think the question here is what should the spec say, and does it say it?
<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.
<nigel> .. Since it was not clear, it is unlikely that the implementations are interoperable. We may want to make it match CSS or not.
<nigel> Glenn: I agree. I think I would try to oppose employing the CSS definition which would be the centre of the block area.
<pal> q+
<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
<nigel> .. is based on centre. But I view that as part of the implementation process of mapping our semantics to CSS in this regard.
<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
<nigel> .. then that would be problematic in my opinion.
<nigel> q+
<nigel> ack p
<nigel> Pierre: I plan to object strongly to changing the origin to anything other than centre.
<nigel> Glenn: Until we define it, it is currently undefined.
<nigel> Pierre: I don't agree with that assessment and I think it is clear what it says in the spec today.
<nigel> Glenn: You think it is the centre of the block?
<nigel> Pierre: Yes absolutely. For the record, unless using centre for skew cannot be used in the context of timed text in general my
<nigel> .. position is that it should be used in general.
<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
<nigel> .. in that example.
<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
<nigel> .. kanji would be outside of the region.
<nigel> Pierre: It's not possible to tell where the origin was in that illustration.
<nigel> Cyril: I agree there's some ambiguity, but it's not clear.
<nigel> Pierre: That's why I go back to the semantic derivation.
<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.
<nigel> Cyril: To get the example image you'd have to apply some translation (or padding)
<nigel> Pierre: You'd have to do that regardless to avoid overflowing (loosely) the region.
<nigel> Nigel: There are two questions: first is the origin of transformation, but the other is the direction of transformation.
<nigel> .. Do we have any info from CSS on direction?
<nigel> Pierre: No, on that one, it is much more ambiguous.
<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.
<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
<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,
<nigel> .. and translate that to a centre based skew transformation by appropriate matrix multiplication, but it will make the explanation of it
<pal> q+
<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
<nigel> .. not tried to do in general.
<nigel> ack n
<nigel> ack p
<nigel> Pierre: Ideally here the solution is to get a discussion with CSS and find a common acceptable solution.
<nigel> Glenn: Unless we have nailed down our intended semantics and have a way of documenting that first it will muddy the waters to
<nigel> .. get involved with CSS. They're not defining shear semantics as far as we know. Are they?
<nigel> Nigel: I haven't checked JLReq and all the gap documents published by the internationalisation activity, but I would speculate that
<nigel> .. this would be one of the gaps that would need solving across the web platform, so they likely do want to solve it.
<nigel> Cyril: I think we should identify what we want for how shear should work and then how to map it onto CSS.
<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.
<nigel> .. For fonts you have to use font-style: oblique; I'm not sure it behaves the same.
<nigel> Glenn: Does it take an angle?
<nigel> Cyril: Yes oblique takes an angle parameter
<nigel> Glenn: Ok I wasn't aware of that
<nigel> Cyril: That's implemented in Chrome and Firefox and is in CSS, not sure if it is level 3 or 4.
<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
<nigel> .. far as I'm concerned, in terms of defining our intentions.
<nigel> Pierre: My interest is in interoperability and compatibility with the web platform.
<nigel> Nigel: If we think about this from an authorial and user perspective, rather than a spec-partisan perspective, then we should surely come
<nigel> .. to the same conclusion.
<nigel> Glenn: I agree, and did offer to consider other options.
<nigel> Cyril: In the comments on the issue, the image at the bottom shows a possibility for defining shear not in consistent mathematical terms,
<nigel> .. depending on the writing mode, another approach is to say "here is what we want to achieve", which could be like italics, where
<nigel> .. positive shear behaves like italics in horizontal modes, and we can do what we want for vertical, then we can derive the math.
<nigel> .. Can we agree, forgetting for the time being about tbrl, that the three images are what we want?
<nigel> .. tbrl has positive shear pointing to bottom left.
<nigel> .. lr has positive shear pointing to top right
<nigel> .. rl has positive shear pointing to top left.
<nigel> .. If we can agree on that then we can decide if we need translation or scaling or padding or whatever.
<nigel> Nigel: My assumption is that shear line layout occurs post-shear not pre-shear. Is that controversial?
<nigel> Glenn: I think that's an implementation issue. We should review.
<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
<nigel> .. blocks and inline areas with glyph areas assume a certain model but different implementations can take different approaches.
<nigel> .. For example one implementation might compute and create state information for laying out the glyphs in a line area based on advances
<nigel> .. alone possibly in association with baseline shifts.
<nigel> .. But when they actually paint those glyphs they might paint them from one or the other direction by recalculating those advances.
<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
<nigel> .. or you might output them in ltr order opposite to reading order. As long as the eventual position of the glyphs match up.
<nigel> .. This has an impact on how things like PDF files store information for accessibility purposes, when those glyphs are recombined for
<nigel> .. operations like find. It is implementation dependent.
<nigel> q?
<nigel> Cyril: Implementations can certainly do different things. The question is the interoperability. How do we achieve it?
<nigel> .. We should specify something but the question Nigel raised is important because if you apply layout first and then shear you might have
<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
<nigel> .. on the layout, how is it placed with respect to other text or objects, and then translate that into specification math.
<nigel> .. For example in terms of layout one big difference between using the centre vs a corner for transformation, unless you apply padding or
<nigel> .. scaling, if you use the centre of the block you may have glyphs moving outside the original box. And that affects layout.
<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
<nigel> .. of the line areas.
<nigel> Nigel: I was about to say that
<nigel> Cyril: Only on one edge, right?
<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
<nigel> .. aligned measure within the outer block area, without overflowing. I don't take into account any other consideration at that point.
<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.
<nigel> .. In my case I apply the skew not based on the centre.
<nigel> SUMMARY: We need to work out what we want it to do before any detailed specification.
<nigel> Glenn: It gets more complicated if different segments on a line have different shear direction. To prevent them from colliding you need to
<nigel> .. temporarily increase the space between them in order to avoid collision. Since we can specify font-shear on a character by character basis
<nigel> .. that means that different characters on a line may have different shears and spacing.

Or is it the center of those block areas?

CSS specifies that the origin of the skew transformation is center of the block area (see transform-origin).

Although TTML2 does specify a non-normative derivation path for tts:shear via CSS3 skewX() and skewY transforms [1], it does not specify or assume an origin for the coordinate system for such transforms, and, indeed, does not define an explicit semantic mapping from TTML2 to such (CSS3) usage.

[1] CSS Transforms, §9.1

The skew origin appears to be unimportant for line shear if the line areas are laid out (stacked) after any skew transformation has been applied since at that point factors such as text alignment and display alignment move the line areas anyway.

[Updated to clarify that this comment was in relation to line shear rather than block shear]

I'm concerned that we will likely never get any equivalent functionality to block shear in CSS, and even that the computational impact of block shear when tts:wrapOption="wrap" is greater than we considered initially. Certainly we haven't specified anything to explain how to handle it.

The problem is that the act of shearing reduces the equivalent pre-shear (i.e. pre-skew) inline dimension of the block area, and this may in turn cause some text to wrap to later lines; this then increases the block dimension of the area, but since the skew transformation effectively transfers the pre-skew block dimension somewhat into the post-skew inline dimension, the equivalent pre-skew inline dimension is then reduced further. This loop may reach stability at some point, but in general it has no constraining factors.

My suspicion, based on past discussions in the CSS WG around other topics that impact layout algorithms, is that an algorithm like this, that continues to loop until stability is achieved, but which is not predictably bounded in advance of layout, would never be accepted into CSS.

Further, this reason makes me query whether we should ever have specified it in TTML, not because of the absence in CSS, but because of the computational challenge. Is anyone able to remind me why we need block shear in addition to line shear?

One mitigation to the problem I outline here is to accept that the application of shear to blocks may cause the resultant parallelogram to exceed the bounds set by the enclosing region, by an amount that depends on the number of lines generated by the text in the block. I don't much like this approach in principle, since document authors cannot reliably know how much content might overflow the region: it is in general possible that some content may overflow the root container region, which is almost certainly undesirable.

Perhaps we should consider whether to remove tts:shear from TTML2 altogether, in favour of the more tractable tts:lineShear where the inline dimension constraint can be predicted at layout time based on the computed line height of each line area, possibly with the addition of any space reserved for ruby and text decoration.

I'd welcome views on this, from implementers and authors alike.

Continuing on this issue, we identified a need for clarifications in the Note:

the available distance that can be allocated to the block area, i.e., its maximum inline progression dimension length prior to shear transformation, is reduced by B*sin(θ), where B is the block progression dimension of the outer block area and θ is the shear angle, in order to fit the block area into the content rectangle of the immediate ancestor block area of the paragraph.

Something's unclear or there is a mistake in the formula. If we consider B being the dimension of the outer block area in the block progression dimension (i.e. the width of the paragraph, horizontally), then the formula should be: B*tan(θ) (tangent not sine).

The Timed Text Working Group just discussed Shear calculations and origin of coordinate system. w3c/ttml2#1199, and agreed to the following:

SUMMARY: Outstanding questions remain, regarding direction, and scaling. Real world computational issues have not yet arisen.

The full IRC log of that discussion

<nigel> Topic: Shear calculations and origin of coordinate system. #1199
<nigel> github: https://github.com//issues/1199
<nigel> Nigel: This is about block shear. Cyril raised a comment recently about the formula for reducing the inline progression dimension
<nigel> .. prior to shear transformation.
<nigel> .. Has anyone been able to review that comment?
<nigel> Pierre: No
<nigel> Nigel: That would be a substantive issue if it is wrong.
<nigel> .. I weighed in a couple of weeks ago with something that's possibly more concerning
<nigel> .. if people are implementing now.
<nigel> .. There's a computational impact that I don't think we realised.
<nigel> .. Unless there's a strong requirement I think we should consider dropping the feature.
<nigel> Pierre: What saves us here is that it is always possible for the author to give sufficient space to guarantee that
<nigel> .. line wrapping will not happen because it is really undesirable in the case of Japanese, especially if there are rubys involved.
<nigel> .. In practice it has not been a big issue.
<nigel> .. A more complicated answer is that CSS cannot support line shear today, which is a huge limitation.
<nigel> .. More importantly there's an ongoing debate. I've seen arguments on both sides.
<nigel> .. If you shear ruby annotations and ruby base text how should they be arranged?
<nigel> .. It can change the alignment if you shear separately from shearing together.
<nigel> .. I've heard strong opinions both ways that you must shear them separately or together.
<nigel> Atsushi: On the point, i18n WG Japanese task force reached out to someone working in typography but there was
<nigel> .. no consensus or good suggestion.
<nigel> Pierre: In fact, if you don't care about the relationship of alignment between ruby annotations and ruby base then you can
<nigel> .. just use fontShear, but that does not work for tate chu yoko.
<nigel> .. It is complicated. The potential for overflow or line wrappign in block shear has not been a problem so far.
<nigel> .. The potential is really terrible.
<nigel> .. Font shear would work great but in the case of ta te chu yoko you need block shear or line shear.
<nigel> s/pign/ping
<nigel> .. And another aspect, which is somewhat arbitrary but needs thinking about: do we want block shear or line shear to
<nigel> .. change if you're writing rtl or ltr for Hebrew vs English for instance. One could argue you should never use them
<nigel> .. but we still need to specify what happens.
<nigel> .. So far in imscJS just as a data point nobody has complained about block shear.
<nigel> Nigel: In imscJS does the resulting parallelogram from the shear go outside the boundaries of the original block area?
<nigel> Pierre: Yes, the CSS skew just allows it to go outside the boundaries.
<nigel> Nigel: And it's only in the inline progression direction that you get an overflow?
<nigel> Pierre: Correct.
<nigel> .. In Japanese it isn't really an issue in practice, because the authoring guarantees that lines won't wrap, and there's
<nigel> .. plenty of padding and no background, so in practice it seems to work.
<nigel> .. Line shear would be awesome and solves all problems but is not possible to implement in CSS today.
<nigel> .. And some people might object to it. As pointed out I'm not sure there's a consensus.
<nigel> Nigel: And my assumption is line shear would include the rubys on the line?
<nigel> Pierre: Yes absolutely, and the tate chu yoko when that's used.
<nigel> Nigel: That feels like the answer - doesn't everyone just want that?
<nigel> Pierre: If supported in CSS, maybe. We would need to go back to the original issue.
<nigel> .. The reason it was not picked for IMSC is the lack of support in CSS.
<nigel> Nigel: Going back to the Japanese language task force, my understanding is that shear is mostly used in electronic displays, and very little
<nigel> .. on paper?
<nigel> 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.
<nigel> .. The consensus in the Japanese task force is that it is an interesting question but who cares?
<nigel> Nigel: This came to us because of its use in captions - is that an aspect you would notice in daily life?
<nigel> 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.
<nigel> Nigel: Okay, thanks.
<nigel> .. Nevertheless we clearly have a requirement for it, certainly from Netflix.
<nigel> Atsushi: Captions in movies import styling meanings from western languages so they import the same semantic meaning as italics,
<nigel> .. but I believe using shearing or italic case is quite a specific use case, say for non-on-screen communications perhaps.
<nigel> Nigel: But a real one.
<nigel> Atsushi: Yes, that's correct.
<nigel> .. 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.
<nigel> Pierre: It is in widespread use in cinemas.
<nigel> Atsushi: In other words, there is no widely used common standard for how to shear or how to make italics.
<nigel> Pierre: There's a cinema standard.
<nigel> 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.
<nigel> Pierre: This was already provided by the way, to W3C.
<nigel> .. The cinema standard.
<nigel> .. In an issue.
<nigel> Nigel: We have sources for this so it might be worth going back and reminding ourselves what they say.
<nigel> .. 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
<nigel> .. direction, and it's then up to implementations to try to do anything more complicated, and authors can apply padding as needed to avoid
<nigel> .. it if they like.
<nigel> .. It may not be entirely interoperable, but it is at least implementable.
<nigel> SUMMARY: Outstanding questions remain, regarding direction, and scaling. Real world computational issues have not yet arisen.

Proposal for consideration: since our discussion revealed that the use of block shear has a potential computational issue if wrapping is happening, and there was an assertion that real world usage in Japanese captions always has authored line breaks, would it be helpful to define use of block shear when tts:wrapOption="wrap" to be an error? In other words, force line wrapping to be an authorial concern when using block shear.

@skynavga

The Timed Text Working Group just discussed TTML2 - Shear calculations and origin of coordinate system. w3c/ttml2#1199, and agreed to the following:

SUMMARY: @skynavga to consider computational issue further

The full IRC log of that discussion

<nigel> Topic: TTML2 - Shear calculations and origin of coordinate system. #1199
<nigel> github: https://github.com//issues/1199
<nigel> Nigel: Following my proposal about line wrapping and block shear, Glenn you wanted to add something?
<nigel> Glenn: In TTPE we implemented this in a branch. We computed the line measure for the block prior to performing
<nigel> .. paragraph line breaking operations. We computed that measure based on the block shear that would apply to the block, so it has the
<nigel> .. result of resulting the measure by some %age related to the sines or cosines of the angle.
<nigel> .. It did not require any kind of recursive update to the measure for formatting purposes.
<nigel> .. Once you've computed the line measure then it's done and you don't need to recompute.
<nigel> .. I will go back to your issue and see if you're thinking of something I had not considered.
<nigel> .. We didn't have any problem of the sort that you mentioned.
<nigel> Nigel: I'm confused by that so will await your further input.
<nigel> SUMMARY: @skynavga to consider computational issue further

@cconcolato

The Timed Text Working Group just discussed Shear calculations and origin of coordinate system. w3c/ttml2#1199, and agreed to the following:

SUMMARY: @cconcolato to propose text

The full IRC log of that discussion

<nigel_> Topic: Shear calculations and origin of coordinate system. #1199
<nigel_> github: https://github.com//issues/1199
<nigel_> Cyril: The initial issue is about clarifying what happens.
<nigel_> .. I think we came up with a possible clarification for some writing mode.
<nigel_> .. We need to propose some text.
<nigel_> Nigel: Yes, that's great, do that!
<nigel_> Cyril: Okay I'll propose text maybe for next time.
<nigel_> .. The discussion veered a bit to how to map to CSS, which won't be solved easily.
<nigel_> .. But better documenting what we have is important for interoperability.
<nigel_> Nigel: From https://github.com//issues/1199#issuecomment-802057127 I summarised that we need to know
<nigel_> .. what we want it to do. Do you think that's clear now?
<nigel_> Cyril: I think we said it does depend on the writing mode
<nigel_> Pierre: I'm not sure about that actually
<nigel_> .. Clarifying the current text is a good idea.
<nigel_> .. I'm hesitating only because CSS was about to do something. Do we know if they are planning
<nigel_> .. to address it soon? It would be a shame if we come to a different conclusion from what they are planning to do.
<nigel_> Cyril: Maybe we could say it's not defined in Horizontal writing mode, which we don't need for now.
<nigel_> -> https://github.com/w3c/csswg-drafts/issues/4818 [css-font-4] oblique angle for vertical text with text-combine-upright #4818
<nigel_> Nigel: I noticed today that the issue above got a useful comment 13 days ago.
<nigel_> Pierre: Yes, but what that says is "to the side"
<nigel_> Nigel: Yes, it's vertical for vertical text, i.e. in the inline direction, which some could consider "to the side"
<nigel_> group: [amusement]
<nigel_> Cyril: I can propose for the TTML spec an update that says the behaviour is undefined for anything
<nigel_> .. other than top-to-bottom, right-to-left, and that behaviour would match what CSS implementations do.
<nigel_> .. [thinks] Maybe the solution will be different for fontShear, lineShear and shear. I'll think about it.
<nigel_> Nigel: Thank you.
<nigel_> Pierre: Cyril, a bigger question is: today IMSC supports only blockShear. Is that really the right thing?
<nigel_> Cyril: It's a difficult question. I can tell you that ideally what we would like at Netflix is the behaviour of fontShear, with vertical
<nigel_> .. and tate-chu-yoko and ruby being handled correctly, where correctly here is still subject to interpretation.
<nigel_> .. I think we understand that lineShear is complicated in terms of line layout and reflow, and blockShear is the simplest we came up with
<nigel_> .. in terms of implementation.
<nigel_> Pierre: That's how it's done but it's not clear if that's right. It has the potential of overflowing.
<nigel_> .. It sounds like we don't have a answer there.
<nigel_> Nigel: I'm surprised by your view Cyril, I thought lineShear would be the preferred option, as it is simpler for layout and retains the alignments.
<nigel_> Cyril: But line lengths can change with lineShear.
<nigel_> Nigel: I think that's blockShear.
<nigel_> Pierre: For lineShear you can predict the line length in advance and layout once.
<nigel_> .. For blockShear you need to know the height of the block, but then there might be overflow causing a change to the block height.
<nigel_> Cyril: Ok I thought that it was simpler, I need to think about it.
<nigel_> .. I know what we want to achieve with shear in subtitles, it's complex because of what is implemented.
<nigel_> Pierre: I'm fairly sure we want lineShear, but we couldn't adopt it because of lack of implementation in CSS.
<nigel_> Cyril: The difference between lineShear and fontShear is essentially that they're the same but if you combine glyphs before shear for tate-chu-yoko they come out the same.
<nigel_> Nigel: What about ruby alignment?
<nigel_> Pierre: The alignment changes - I have heard it argued both ways.
<nigel_> Cyril: The difference is subtle, I wonder if we need to worry about it.
<nigel_> Pierre: If tomorrow all browsers supported fontShear with the tate-chu-yoko hack then I suspect we'd use it,
<nigel_> .. rather than CSS shear. I don't disagree with you.
<nigel_> .. Treating tate-chu-yoko as a single glyph is kind of weird though.
<nigel_> Pierre: I like your plan for vertical text to provide a clarification. That would be helpful, even if we
<nigel_> .. leave the rest undefined for now.
<nigel_> SUMMARY: @cconcolato to propose text

@skynavga

The Timed Text Working Group just discussed Shear calculations and origin of coordinate system. w3c/ttml2#1199, and agreed to the following:

SUMMARY: Waiting on Glenn @skynavga for a pull request to review

The full IRC log of that discussion

<nigel> Topic: Shear calculations and origin of coordinate system. #1199
<nigel> github: https://github.com//issues/1199
<nigel> Nigel: Glenn informed me earlier today that he is planning to open a pull request to address this, and is doing implementation work.
<nigel> .. I asked him to share his thoughts on the issue before opening the pull request, and he said he would.
<nigel> .. He summarised it as "don't optimise too soon", which I think means "you don't have to implement the ideal end result".
<nigel> .. I'm interested to see what flexibility he wants to clarify in implementations.
<nigel> Cyril: I also have an update.
<nigel> .. I talked to Glenn! He told me he wanted to write a PR.
<nigel> .. I had the action, though I'm late doing it.
<nigel> .. The agreement we had was that I would clarify the origin and axis in the case of tblr and we said we could leave
<nigel> .. it undefined for other writing modes. That's my recollection.
<nigel> .. Glenn told me he verified his TTPE implementation and is satisfied with it.
<nigel> .. My understanding is he wanted to clarify the spec based on that implementation.
<nigel> .. My original comment was about the lack of clear definition of the origin of the transform or the orientation of the axes,
<nigel> .. and if any scaling or transformation needs to be done.
<nigel> .. He told me he wants to clarify the same things.
<nigel> .. It might go beyond what I thought we would do, but that was because of a lack of agreement
<nigel> .. on what to do for the other writing modes.
<nigel> .. If we have a proposal we can decide if we want to adopt it (for the other writing modes)
<nigel> Nigel: Thanks, anyone else want to raise anything on this issue now?
<nigel> Atsushi: Nothing from me
<nigel> SUMMARY: Waiting on Glenn @skynavga for a pull request to review

The Timed Text Working Group just discussed Shear calculations and origin of coordinate system. w3c/ttml2#1199, and agreed to the following:

SUMMARY: @skynavga Glenn to continue working on specification pull request.

The full IRC log of that discussion

<nigel> Glenn: Status update on what I've been doing.
<nigel> … We recently finalised our implementation of line shear and block shear (tts:shear)
<nigel> … in the TTPE package. It's checked into a branch right now, possibly merged into the main branch.
<nigel> … We were able to verify the correct origin and orientation of the axes for both line shear and shear
<nigel> … in all of the writing modes in combination with different default paragraph level bidi levels.
<nigel> … That looks good.
<nigel> … One of the things we wanted to do was to resolve an issue Nigel had brought up
<nigel> … regarding processing of tts:shear semantics because in order to compute the adjustment
<nigel> … to the inline progression dimension (ipd) for doing line breaking, it is necessary to know
<nigel> … the value of the block progression dimension (bpd) that will be used for that adjustment.
<nigel> … The value of bpd may depend on having performed line breaking, so there is a potential
<nigel> … recursive process to resolve what the value of the bpd might be.
<nigel> … However after analysing the TTML specification semantics we realised that
<nigel> … bpd on a block area such as a paragraph is always defined in the sense that it has an initial value
<nigel> … which is auto, and at the present time, auto is defined such that it maps to 100%,
<nigel> … which means that the container area bpd in which the paragraph will be fitted constrains the
<nigel> … maximum value of the bpd, and in fact fixes it, because in all cases we can map
<nigel> … that back up to some region which is definite in its height and width and therefore bounded.
<nigel> … The long and short of it is that bpd = auto = 100% = bpd of the container area constrained by region size.
<nigel> … It can be no larger than the bpd of the region in which that p is placed.
<nigel> … The default semantics for doing shear calculation of the ipd can be determined ahead
<nigel> … of time when bpd = auto.
<nigel> … If bpd is set to some other value, e.g. an explicit length, or minContent, maxContent or fitContent,
<nigel> … which are defined in TTML2 but not used in IMSC, then other processes can be used to
<nigel> … determine the value of BPD and therefore plugged into the shear calculation to get the adjustment to ipd.
<nigel> … We were able to verify that and check that into our codebase,
<nigel> … and have entered it into the implementation report as having been implemented.
<nigel> … We added an expectation file in ttml2-tests for the TTPE output, so we
<nigel> … view that as having been resolved.
<nigel> … The next step is to update the spec as necessary.
<nigel> … Cyril has mentioned a couple:
<nigel> … Change sin theta to tan theta.
<nigel> … Add information about the origin and orientation of the axes for the purpose of performing the skew transformation.
<nigel> … I've started work on creating that update.
<nigel> … I plan to generate some SVG visuals that can go into the spec that
<nigel> … show the origin and axis for the different writing mode combinations wrt the paragraph directionality.
<nigel> … I expect that in the next few weeks.
<nigel> … We're trying to get all of the TTML2 tests implemented and checked into TTPE so that we have
<nigel> … resolved any issues in the tests and that will allow us to at least have one implementation
<nigel> … of every test that is listed in the implementation report.
<nigel> … Right now there are 3 tests left for us to complete, which should take 2-4 weeks approximately.
<nigel>
<nigel> Nigel: Thank you Glenn. Any questions?

@skynavga

@skynavga as part of issue triaging I have rediscovered this gem. You had the last action and seemed to have a plan, but I think other things happened that got in the way. Were you ever able to complete the tests so the specification changes could be proposed?

I had GPT 6 do an audit of correctness and completeness Re: Shear. I have not done any further implementation work since TTML2 2nd Ed. CR was published.

Below is a GitHub Flavored Markdown (GFM) version, formatted for direct use in a GitHub issue comment. It uses GitHub-compatible Markdown tables, code blocks, links, and LaTeX mathematical expressions.

Audit of TTML2 Shear Properties and Calculations

Specification: Timed Text Markup Language 2 (TTML2), Second Edition — W3C Candidate Recommendation, 9 March 2021

Sections audited:

Executive assessment

The specification establishes a coherent basic distinction between three levels of shear transformation: individual glyph areas, line areas, and paragraph block areas. It also defines a common percentage-to-angle mapping and two transformation matrices.

However, the language is not mathematically consistent or sufficiently complete to guarantee interoperable rendering in all cases.

The most significant issues concern:

Incorrect trigonometric calculations for layout adjustments.
Undefined transformation behavior at ±100%.
Layout requirements expressed only in non-normative notes.
Incomplete definitions of transformation origins and positioning.
Insufficient specification of interactions among the three shear properties.
Ambiguous writing-mode and sign conventions.
Incomplete glyph shear and layout semantics.

1. Incorrect trigonometric function in layout calculations

Severity: High — mathematical correctness

Affected sections: §10.2.28 (tts:lineShear) and §10.2.39 (tts:shear).

Both sections contain a note stating that the available inline progression dimension should be reduced by:

$$ B\sin(\theta) $$

where:

$B$ is the block progression dimension of the affected area.
$\theta$ is the shear angle.

This is inconsistent with the transformation matrices defined in §10.4.5.3.

Mathematical analysis

For horizontal inline progression, the specification defines:

$$ S_x = \begin{bmatrix} 1 & \tan\theta & 0 \\ 0 & 1 & 0 \\ 0 & 0 & 1 \end{bmatrix} $$

Applying this transformation gives:

$$ x' = x + y\tan\theta $$

$$ y' = y $$

Consider an initially rectangular area with inline dimension $W$ and block dimension $B$.

After shear transformation, the bounding rectangle has an inline dimension:

$$ \boxed{W' = W + B|\tan\theta|} $$

Consequently, to ensure that the transformed area fits within an available inline dimension $A$, the original area must satisfy:

$$ \boxed{W \le A - B|\tan\theta|} $$

The correct reduction is therefore:

$$ \boxed{\Delta W = B|\tan\theta|} $$

rather than $B\sin\theta$.

The same result applies for vertical inline progression after exchanging the coordinate axes.

Example

Suppose:

Available inline dimension: 100 px
Block progression dimension: 20 px
Shear value: 50%
Shear angle: 45°

The current specification gives:

$$ 20\sin45^\circ \approx 14.142\text{ px} $$

But the specified shear matrix gives:

$$ 20|\tan45^\circ| = 20\text{ px} $$

The specification would therefore permit an unsheared inline dimension of approximately 85.858 px, although the resulting sheared bounding rectangle would require 105.858 px.

That contradicts the stated objective of fitting the sheared area within its containing rectangle.

Additional defect: negative shear values

Both notes use $B\sin\theta$ without an absolute value.

For negative shear angles:

$$ \sin\theta < 0 $$

Subtracting this negative value would increase the available inline dimension, even though a negative shear increases the bounding rectangle's inline extent just as a positive shear of the same magnitude does.

This is particularly relevant because §10.2.20 explicitly illustrates negative shear values, and the common calculation section permits them.

Recommended correction

Replace B*sin(θ) in both sections with:

$$ B|\tan\theta| $$

provided that $B$ denotes the block progression dimension before transformation, as the existing language implies.

Also specify what happens when the resulting available dimension is zero or negative. A reasonable rule would be to clamp the available dimension to zero, although the working group should determine the intended layout behavior.

Assessment: This is a substantive mathematical defect, not merely an editorial ambiguity.

2. Undefined shear transformation at ±100%

Severity: High — mathematical correctness and interoperability

Affected section: §10.4.5.3, Shear Calculations.

The section states that 100% corresponds to 90° and -100% corresponds to −90°.

It also defines the matrix coefficient as:

$$ a = \tan\theta $$

However:

$$ \tan(90^\circ) \quad\text{and}\quad \tan(-90^\circ) $$

are mathematically undefined.

Thus, the specification explicitly permits values for which its specified transformation matrix cannot be evaluated.

Inadequacy of the existing workaround

The section attempts to address this using a note allowing the used angle to be adjusted by a small epsilon.

This is insufficient for three reasons.

First, the adjustment is optional.

The wording permits a processor not to apply the adjustment, leaving the transformation undefined.

Second, the value of epsilon is unspecified.

Different implementations can choose substantially different finite shear coefficients.

For example:

$$ \tan89^\circ \approx 57.29 $$

whereas:

$$ \tan89.9^\circ \approx 572.96 $$

The corresponding transformations differ by approximately a factor of ten.

Third, the wording is ambiguous for negative angles.

Reducing a signed angle of −90° would ordinarily make it more negative. The intended operation is presumably to reduce its absolute magnitude.

Recommended correction

The specification should adopt one of two approaches:

Preserve ±100% as valid values: Define a deterministic finite approximation, including the maximum shear angle or coefficient and the required sign handling.
Restrict the effective shear angle to less than 90° in magnitude: Define how processors handle values at or beyond the singularity, including backward compatibility with existing content.

The first approach avoids changing the permitted value syntax. The second more accurately reflects the mathematical domain of the transformation.

In either case, the required behavior belongs in normative prose rather than an optional note.

If epsilon-based handling is retained, the intent should be expressed as:

$$
\theta_{\mathrm{used}}

\operatorname{sgn}(\theta)(90^\circ-\varepsilon)
$$

for endpoint values, with a defined positive $\varepsilon$.

Assessment: The current endpoint semantics are incomplete and cannot guarantee interoperable results.

3. Layout requirements appear only in non-normative notes

Severity: High — normative completeness

Affected sections: §10.2.28 and §10.2.39.

The two sections explain how the available inline progression dimension must be adjusted to accommodate the shear transformation.

However, these explanations appear within paragraphs explicitly marked as notes.

Section 2.3, Documentation Conventions, establishes that all paragraphs marked as notes are non-normative.

Consequently, the two passages cannot independently impose a conformance requirement on a presentation processor.

The normative text preceding the examples requires applying the shear transformation, but does not explicitly require a corresponding adjustment to the available layout dimensions.

This leaves important questions unanswered:

Must a presentation processor reserve additional space for shear, or may it simply transform already-laid-out areas?
Must line breaking take account of the transformed bounding rectangle?
Must the processor ensure that the transformed area remains inside its containing content rectangle?
What happens when the requested transformation cannot fit?

The distinction matters. One implementation could reduce the available line length before line breaking; another could lay out the entire line normally and subsequently skew it.

Both might consider themselves compliant, yet produce visibly different results.

Recommended correction

Move the geometric constraints into normative prose in §10.2.28 and §10.2.39, or define a common normative layout procedure that both properties reference.

The revised text should distinguish:

Determination of the area dimensions before transformation.
Adjustment of available layout space, where required.
Application of the shear transformation.
Placement and clipping of the transformed area.

The examples and notes should illustrate these requirements rather than serve as their only definition.

Assessment: The specification describes an intended layout behavior without unambiguously making that behavior mandatory.

4. Transformation origin and positioning are underspecified

Severity: Medium–High — rendering interoperability

Affected sections: All four.

Section 10.4.5.3 defines the transformation matrices but does not establish the point relative to which they are applied.

For example, when the horizontal shear matrix is used, the transformation can be expressed relative to a reference point $(x_0,y_0)$:

$$ x' = x + (y-y_0)\tan\theta $$

$$ y' = y $$

Different values of $y_0$ produce different translations of the resulting geometry.

A 20 px-high area sheared by 45° produces different positioning depending on whether the transformation is anchored at the area's top edge, bottom edge, or center.

The specification does define a document coordinate system in Appendix H, but that does not by itself identify the local reference point for each sheared glyph, line, or block area.

The issue is relevant to the stated objective of fitting sheared areas within their containers. Reserving sufficient space does not establish where the transformed area should be placed.

Recommended correction

Specify the reference point for each kind of affected area, including whether it is determined from the allocation rectangle, content rectangle, or another reference rectangle.

Define how that reference point relates to the applicable writing mode and how the transformed area is subsequently aligned within its containing area.

The CSS Transforms specification provides a useful model by separately defining the transformation matrix, reference box, and transformation origin.

TTML2's non-normative CSS derivation references do not themselves establish equivalent TTML requirements.

Assessment: The matrix coefficients are defined, but the complete positioning operation is not.

5. Interaction among the three shear properties is insufficiently specified

Severity: Medium — completeness

Affected sections: §10.2.20, §10.2.28, §10.2.39, and §10.4.5.3.

The three properties act at different levels of the area hierarchy.

Property	Transformation target
`tts:fontShear`	Individual glyph areas
`tts:lineShear`	Each line area generated by a paragraph
`tts:shear`	The outermost paragraph block area

These individual definitions are reasonably clear.

What is less clear is the required behavior when multiple properties have nonzero computed values.

Consider:

<p tts:shear="10%" tts:lineShear="20%">
  <span tts:fontShear="15%">Example</span>
</p>

The specification does not explicitly describe the complete sequence of transformations for the resulting glyphs.

In particular, it should establish:

Whether the glyph transformation occurs in glyph-local coordinates before the line transformation.
Whether the line transformation occurs before the outer block transformation.
How the coordinate systems and transformation origins are related.

A natural interpretation is to apply the transformations from the innermost area outward.

Using homogeneous transformation matrices, the resulting operation could be expressed as:

$$
T_{\mathrm{result}}

T_{\mathrm{block}}
T_{\mathrm{line}}
T_{\mathrm{glyph}}
$$

where each $T$ includes any required translation to and from its reference point.

However, the specification should make this interpretation explicit rather than require implementers to infer it.

Recommended correction

Add normative language specifying how the transformations compose, including their reference coordinate systems.

Also clarify whether the available inline dimensions are adjusted separately at each stage or derived from the combined transformed geometry.

The latter distinction matters when transformations have opposing signs or act in different coordinate systems.

Assessment: The three properties are individually defined, but their combined application deserves an explicit algorithm.

6. Writing-mode and sign conventions need clarification

Severity: Medium — semantic clarity

Affected section: §10.4.5.3.

The specification distinguishes two cases based on whether the inline progression direction corresponds to the X or Y axis.

This is appropriate for horizontal versus vertical writing modes.

However, the terminology could more precisely distinguish the axis of inline progression from its signed direction.

For example, the horizontal writing modes lrtb and rltb share the X axis, but their inline progression directions are opposite.

Similarly, the vertical writing modes tbrl and tblr share the Y axis for inline progression, but have opposite block progression directions.

The current matrices use the same coefficient $a=\tan\theta$ regardless of these differences.

That establishes a particular physical transformation, but the prose does not explicitly state whether the sign of the shear is intended to be invariant under changes in writing direction.

Recommended correction

Define positive and negative shear explicitly in document coordinates.

For example, if the existing matrices express the intended behavior, state that:

A positive shear angle produces a positive X displacement as Y increases for X-axis shear.
A positive shear angle produces a positive Y displacement as X increases for Y-axis shear.

Then state whether changing writing direction affects the sign of the transformation.

This would eliminate uncertainty without necessarily changing the mathematics.

Assessment: The matrices provide substantial information, so this is principally a clarification issue rather than a demonstrated mathematical error.

7. `tts:fontShear` needs clearer layout and glyph semantics

Severity: Medium — completeness

Affected section: §10.2.20.

The section requires a shear transformation to be applied to each affected glyph area.

However, it does not distinguish sufficiently between transforming the glyph's rendered outline and transforming the geometry of the glyph area.

This distinction has consequences for layout.

For example, the specification should clarify whether tts:fontShear:

Changes glyph advance dimensions.
Contributes to line-breaking calculations.
Affects the positioning of adjacent glyphs.
Transforms decorations or backgrounds associated with the glyph area.

Section 11.3.2.2 identifies per-glyph font shear as a feature that may affect line height. However, this appears in a non-normative note rather than a normative calculation procedure.

There is also a potential interaction with tts:fontStyle.

Section 10.2.22 states that tts:fontStyle="oblique" denotes a shear transformation whose angle is unspecified.

Consequently, when tts:fontStyle="oblique" and a nonzero tts:fontShear are applied to the same text, the specification should explain whether the two effects are cumulative or whether one substitutes for the other.

Recommended correction

Define whether tts:fontShear changes layout metrics or only the rendered shape of glyph areas.

Specify its relationship with:

Font selection.
Synthetic obliquing.
Text orientation.
Inline-area layout.

In particular, an implementation should not have to guess whether applying a shear also changes the advance used to position the next glyph.

Assessment: The intended visual operation is understandable, but important layout consequences are not fully specified.

8. Additional editorial and completeness issues

8.1. Clarify the scope of `tts:shear`

Section 10.2.39 initially identifies the affected area as the outermost block area generated by the affected element.

Its subsequent normative sentence refers more generally to each block area to which the attribute applies.

Although the intended target can be inferred, the second sentence should retain the qualification outermost.

Suggested wording:

For each outermost block area generated by a p element to which this style property applies, apply the shear transformation specified in §10.4.5.3.

This is a minor editorial clarification.

8.2. Make the percentage-to-angle calculation explicit

The first sentence of §10.4.5.3 describes a linear relationship between the percentage and the angle.

The relationship is correct for values strictly between −100% and 100%, but would be clearer as an equation.

If $p$ denotes the numerical percentage value, define:

$$ \theta = \frac{p}{100}\times90^\circ $$

For example, 16.67% corresponds to approximately 15.003°.

Explicitly distinguishing the numerical percentage from its fractional representation would reduce the possibility of implementation errors.

8.3. Clarify the calculation sequence for `tts:lineShear`

The space-reduction explanation in §10.2.28 depends on the block progression dimension $B$ of an individual line area.

However, that dimension may depend on the content assigned to the line, including ruby annotations and other advanced formatting features.

This creates a potential layout dependency:

The available line length may depend on $B$.
$B$ itself may depend on the line's content.

The specification should clarify when $B$ is determined and how the processor handles cases in which line breaking changes the required block progression dimension.

This is particularly relevant to automatic line wrapping in content containing ruby.

8.4. Improve the examples

The existing examples demonstrate several useful cases, including positive and negative font shear, vertical writing, ruby, and tate-chu-yoko.

They could be extended to cover:

Positive and negative tts:lineShear and tts:shear.
Simultaneous use of all three shear properties.
Horizontal right-to-left writing.
Values near and at ±100%.
Values outside the ±100% range.
Layout near the boundaries of containing areas.

The examples should identify the expected shear angles and, where practical, the resulting geometric dimensions.

These additions would be especially useful for implementation testing.

9. Suggested revised language for Shear Calculations

The following is a proposed replacement for the core mathematical language of §10.4.5.3.

It resolves the percentage conversion and matrix definitions and establishes the bounding-dimension calculation.

It deliberately leaves the endpoint policy as a separate decision because a finite affine shear corresponding exactly to ±90° cannot be defined.

Proposed text

10.4.5.3 Shear Calculations

A shear value specifies a two-dimensional shear transformation applied along the axis corresponding to the inline progression dimension of the affected area.

Let $p$ be the numerical value of the specified percentage, excluding the percent sign.

The effective percentage value $p_c$ is:

$$ p_c = \max(-100,\min(100,p)) $$

The corresponding shear angle $\theta$, expressed in degrees, is:

$$ \theta = \frac{p_c}{100}\times90^\circ $$

For shear angles satisfying:

$$ -90^\circ < \theta < 90^\circ $$

the shear coefficient $a$ is:

$$ a = \tan\theta $$

If $\theta=0^\circ$, the shear transformation is the identity transformation.

If the inline progression dimension corresponds to the X axis, the shear transformation is:

$$ S_x = \begin{bmatrix} 1 & a & 0 \\ 0 & 1 & 0 \\ 0 & 0 & 1 \end{bmatrix} $$

If the inline progression dimension corresponds to the Y axis, the shear transformation is:

$$ S_y = \begin{bmatrix} 1 & 0 & 0 \\ a & 1 & 0 \\ 0 & 0 & 1 \end{bmatrix} $$

The transformation is applied in the coordinate system of the affected area, relative to a reference point determined by the applicable area transformation semantics.

For an initially rectangular area having an inline progression dimension $W$ and block progression dimension $B$, application of either transformation produces a bounding rectangle whose inline progression dimension is:

$$ W' = W+B|a| $$

and whose block progression dimension remains $B$.

When presentation processing requires the transformed bounding rectangle to fit within an available inline progression dimension $A$, the pre-transformation inline progression dimension must not exceed:

$$ A-B|a| $$

The treatment of cases where this quantity is negative must follow the specified overflow or fallback semantics.

Additional normative text is required to establish:

The transformation reference point.
Positioning rules.
Composition of multiple shear transformations.
Behavior at ±90°.

Editorial implications

The preceding language would provide a consistent mathematical foundation for all three properties.

However, it should not be adopted as a complete replacement without resolving the remaining semantic questions.

In particular, the working group must determine:

Whether layout-space reservation is mandatory.
Whether exact endpoint values remain permitted.
How area-local coordinate systems are established.

10. Overall audit conclusions

Finding	Classification	Priority
`sin(θ)` inconsistent with specified `tan(θ)` shear matrices	Mathematical defect	High
Missing absolute value for negative shear layout adjustments	Mathematical defect	High
Undefined transformation at ±100%	Mathematical defect	High
Optional, unspecified epsilon adjustment	Interoperability defect	High
Layout constraints defined only in notes	Normative completeness	High
Transformation reference point unspecified	Semantic completeness	Medium–High
Composition of multiple shear properties insufficiently specified	Semantic completeness	Medium
Glyph shear effects on layout metrics unclear	Semantic completeness	Medium
Positive/negative shear conventions could be clearer	Editorial/semantic clarity	Medium
`tts:fontStyle="oblique"` interaction unclear	Semantic completeness	Medium
Line breaking and shear-dependent dimensions insufficiently integrated	Layout completeness	Medium
Inconsistent reference to outermost block areas	Editorial	Low
Percentage mapping expressed only in prose	Editorial	Low
Limited boundary-condition examples	Testability	Low

Aspects that appear correct

The audit also identified several aspects that do not require substantive correction.

The three properties have appropriately distinct targets within the formatting area hierarchy.
Their common 0% initial value is consistent with an identity transformation.
The use of a signed <percentage> value is consistent with the grammar in §10.3.31, which permits signed integer and real percentages.
The properties' inheritance declarations are consistent with TTML2's general styling model.
In particular, tts:fontShear can be inherited from an ancestor even though its semantic application is restricted to span elements. The general styling provisions explicitly permit that behavior.
Declaring all three properties discretely animatable is internally consistent. Continuous interpolation is not required by these property definitions.

These aspects should be retained unless there is a separate requirement to change the underlying feature behavior.

11. Recommended actions

The shear definitions require substantive revision before their rendering behavior can be considered fully specified.

I recommend addressing the issues in three stages.

Priority 1: Correct the mathematics

Replace both occurrences of B*sin(θ) with B*abs(tan(θ)).
Establish a mathematically valid and deterministic policy for ±100%.
Define behavior when the required transformed area cannot fit within its container.
Resolve the treatment of negative shear angles in layout calculations.

Priority 2: Complete the normative semantics

Define the transformation reference point.
Specify the interaction among glyph, line, and block shear.
Define the relationship between shearing, line breaking, and available layout space.
Move mandatory layout rules out of non-normative notes.
Specify the order of transformations and their coordinate systems.

Priority 3: Improve clarity and testability

Clarify sign conventions for horizontal and vertical writing modes.
Clarify the effect of tts:fontShear on glyph metrics and adjacent glyph positioning.
Clarify interactions with tts:fontStyle="oblique".
Align terminology concerning outermost block areas.
Add examples exercising negative shear, combined shear, and endpoint behavior.
Express the percentage-to-angle mapping as an explicit equation.

Conclusion

The highest-priority corrections concern §10.4.5.3 together with the layout notes in §10.2.28 and §10.2.39.

These sections should be addressed together because changing the shear calculations without revising their layout consequences would leave the specification internally inconsistent.

The issues fall into two categories:

Demonstrable defects: The trigonometric inconsistency, missing absolute value for negative shear, and undefined transformations at ±100%.
Specification completeness issues: Transformation origins, layout semantics, composition order, writing-mode conventions, and glyph-metric interactions.

The first category requires mathematical correction. The second requires clarification of the intended normative behavior to ensure interoperable implementations.

Reference: TTML2, W3C Candidate Recommendation, 9 March 2021.

ln addition, I asked GPT to review this issue in light of its audit included above:

Does your response adequately raise the issue/comments in #1199 (comment)?

Assessment: Substantially, but not completely

I reviewed [TTML2 issue #1199](#1199), including its discussion history and the [October 17, 2026 comment](#1199 (comment)).

The October 17 comment reproduces my earlier GFM audit. It identifies the principal specification defects, but it does not adequately incorporate several important conclusions from the issue's 2021 discussions.

In particular, it correctly identifies three central concerns:

Incorrect shear geometry: The B*sin(θ) expression is inconsistent with the tangent-based shear matrices.
Undefined transformation origin: The specification does not adequately establish the point about which shear is applied.
Writing-mode-dependent behavior: The specification needs clearer definitions of coordinate-system orientation and shear direction.

These correspond closely to the original issues raised by Cyril Concolato in February 2020 and March 2021. The trigonometric defect was explicitly identified in March 2021 and acknowledged as a necessary correction during the June 24, 2021 working group discussion. :chatgpt-content-reference{index="0"}

The shortcomings are primarily about historical context, specificity, and the distinction between unresolved specification defects and implementation questions that were investigated in 2021.

What the comment does not adequately address

1. The 2021 discussion identified specific transformation-origin alternatives

My audit recommends defining the shear transformation origin, but does not acknowledge the competing interpretations already discussed.

During the March 18, 2021 discussion, Glenn Adams described an intended interpretation in which the transformation origin depended on writing mode and paragraph-level bidirectional embedding level. The examples included the top-left corner for horizontal left-to-right text, top-right for horizontal right-to-left text, top-left for tblr, and top-right for tbrl.

Pierre Lemieux advocated a center-based origin consistent with CSS transforms. This was a substantive disagreement, not merely an omission that could be corrected without deciding the intended semantics.

The discussion also distinguished tts:fontShear, for which Glenn suggested an origin related to glyph placement on the baseline rather than the center of the glyph.

The audit should explicitly identify these alternatives and request a resolution. It should also acknowledge that mapping TTML shear semantics to CSS transforms may require additional translations. :chatgpt-content-reference{index="1"}

2. The 2021 implementation work addressed the apparent recursive layout problem

This is the most important omission.

In March 2021, Nigel Megitt identified a possible circular dependency involving tts:shear and automatic line wrapping:

Available inline progression dimension depends on block progression dimension.
Block progression dimension may depend on line breaking.
Line breaking depends on the available inline progression dimension.

My audit raises this problem but does not acknowledge the subsequent implementation analysis.

At the June 24, 2021 meeting, Glenn reported that the TTPE implementation had addressed the dependency by using TTML2's block progression dimension semantics.

Specifically, he explained that tts:bpd="auto" resolves to a dimension constrained by the containing area. This permitted calculation of the shear-adjusted inline progression dimension before line breaking, avoiding the anticipated recursive computation in that default case.

He also reported that TTPE had implemented and tested line and block shear, including transformation origins and axis orientations for different writing modes and paragraph bidi levels.

This does not establish that every possible layout configuration is resolved, but it materially changes the assessment.

My audit should distinguish an underspecified normative procedure from an implementation problem for which a solution was already demonstrated. :chatgpt-content-reference{index="2"}

3. The audit does not identify the specification changes already proposed in 2021

The June 24 discussion identified two concrete specification updates:

Correct sin(θ) to tan(θ). My audit covers this and extends it by identifying the need for absolute values when calculating the required bounding dimension.

Clarify the origin and orientation of the transformation axes. My audit identifies this requirement, but does not present the writing-mode-dependent origin and orientation rules that the TTPE implementation reportedly validated.

At that meeting, Glenn also described plans to develop SVG diagrams showing the origins and axes for different combinations of writing mode and paragraph directionality.

Those diagrams would be particularly valuable because they would turn the abstract matrix definitions into verifiable presentation semantics. :chatgpt-content-reference{index="3"}

4. The audit does not directly address the October 2026 question about test completion

On October 14, 2026, Nigel specifically asked whether the tests had been completed so that the specification changes could be proposed.

The October 17 comment states that no further implementation work had been undertaken, but does not provide a precise status of the tests identified in June 2021 or the planned specification changes.

For the purpose of resolving issue #1199, these are relevant distinctions.

The next step should be to determine which tests and expectation files exist, which remain outstanding, and whether the demonstrated TTPE behavior can be used as the basis for normative text. :chatgpt-content-reference{index="4"}

A qualification to my earlier recommendations

My original audit recommends making the geometric layout constraints normative and resolving the transformation semantics comprehensively.

That remains a defensible objective, but it is more prescriptive than the approach considered during the 2021 working group discussions.

Those discussions included the possibility of defining the essential transformation semantics while allowing some implementation flexibility, particularly where exact layout behavior was computationally difficult or lacked interoperable implementation experience.

Accordingly, I would distinguish between the minimum normative clarifications needed for interoperability and additional layout refinements that may be desirable but do not necessarily belong in this issue.

I would also consider separating the newly identified ±100% singularity problem into its own issue. It is a legitimate mathematical concern, but is not central to the historical discussion of issue #1199.

Recommended follow-up

I would retain the existing October 17 audit as a broad assessment and add a shorter follow-up comment that connects its findings to the previous working group work.

The follow-up could read:

The preceding audit identifies issues that overlap with the 2021 discussion. In particular, the correction from sin(θ) to tan(θ) and the need to define the shear transformation origin and axis orientation were already identified in the June 24, 2021 TTWG discussion.

That discussion also reported that TTPE had implemented and verified tts:lineShear and tts:shear across writing modes and paragraph bidi levels. Furthermore, it identified an approach to resolving the potential dependency between line breaking and the block progression dimension, using the semantics of tts:bpd.

I suggest that any specification changes build on that implementation experience and distinguish between:

(a) the normative mathematical corrections;

(b) the origin, coordinate-system orientation, and positioning semantics established by the implementation;

(c) layout behaviors for which implementation flexibility is appropriate; and

(d) any additional interoperability issues identified by the audit that were not addressed in 2021.

It would also be useful to determine the status of the TTPE tests and expectation files reported in June 2021, and whether the previously planned SVG illustrations of transformation origins and coordinate axes can now be produced.

Conclusion

The October 17 comment is an adequate audit of the four specification sections, but it is not a complete response to the historical technical discussion in issue #1199.

It correctly identifies important mathematical and semantic deficiencies. Its principal weakness is that it treats several matters as newly identified or unresolved without acknowledging the substantial implementation work and design discussions that occurred in 2021.

I would preserve the audit, incorporate the demonstrated TTPE behavior, and use that material to formulate specific proposed normative changes.

The most productive next step is not another general audit, but a concrete proposal for transformation origins, axis orientations, and layout calculations, supported by implementation tests and examples.

Shear calculations and origin of coordinate system. #1199

Description

Activity

cconcolato commented on Mar 16, 2021

Summary:

palemieux commented on Mar 17, 2021

css-meeting-bot commented on Mar 18, 2021

skynavga commented on Mar 19, 2021

nigelmegitt commented on Mar 19, 2021

nigelmegitt commented on Mar 19, 2021

cconcolato commented on Mar 31, 2021

css-meeting-bot commented on Apr 1, 2021

nigelmegitt commented on Apr 27, 2021

css-meeting-bot commented on Apr 29, 2021

css-meeting-bot commented on May 13, 2021

css-meeting-bot commented on Jun 10, 2021

nigelmegitt commented on Jun 24, 2021

nigelmegitt commented on Oct 14, 2026

skynavga commented on Oct 17, 2026

Audit of TTML2 Shear Properties and Calculations

Executive assessment

1. Incorrect trigonometric function in layout calculations

Mathematical analysis

Example

Additional defect: negative shear values

Recommended correction

2. Undefined shear transformation at ±100%

Inadequacy of the existing workaround

Recommended correction

$$ \theta_{\mathrm{used}}

3. Layout requirements appear only in non-normative notes

Recommended correction

4. Transformation origin and positioning are underspecified

Recommended correction

5. Interaction among the three shear properties is insufficiently specified

$$ T_{\mathrm{result}}

Recommended correction

6. Writing-mode and sign conventions need clarification

Recommended correction

7. tts:fontShear needs clearer layout and glyph semantics

Recommended correction

8. Additional editorial and completeness issues

8.1. Clarify the scope of tts:shear

8.2. Make the percentage-to-angle calculation explicit

8.3. Clarify the calculation sequence for tts:lineShear

8.4. Improve the examples

9. Suggested revised language for Shear Calculations

Proposed text

Editorial implications

10. Overall audit conclusions

Aspects that appear correct

11. Recommended actions

Priority 1: Correct the mathematics

Priority 2: Complete the normative semantics

Priority 3: Improve clarity and testability

Conclusion

skynavga commented on Oct 17, 2026

Assessment: Substantially, but not completely

What the comment does not adequately address

1. The 2021 discussion identified specific transformation-origin alternatives

2. The 2021 implementation work addressed the apparent recursive layout problem

3. The audit does not identify the specification changes already proposed in 2021

4. The audit does not directly address the October 2026 question about test completion

A qualification to my earlier recommendations

Recommended follow-up

Conclusion

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

$$
\theta_{\mathrm{used}}

$$
T_{\mathrm{result}}

7. `tts:fontShear` needs clearer layout and glyph semantics

8.1. Clarify the scope of `tts:shear`

8.3. Clarify the calculation sequence for `tts:lineShear`