Open cconcolato opened 4 years ago
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:
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).
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.
We should clarify:
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.
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.
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.
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 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 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 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.
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