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.

ttml-shear

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. w3c/ttml2#1199
<nigel> github: https://github.com/w3c/ttml2/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. w3c/ttml2#1199
<nigel> github: https://github.com/w3c/ttml2/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.

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. w3c/ttml2#1199
<nigel> github: https://github.com/w3c/ttml2/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

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. w3c/ttml2#1199
<nigel_> github: https://github.com/w3c/ttml2/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/w3c/ttml2/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

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. w3c/ttml2#1199
<nigel> github: https://github.com/w3c/ttml2/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?

w3c / ttml2

Shear calculations and origin of coordinate system. #1199

Summary: