Open palemieux opened 4 years ago
In the case where the block progression direction is horizontal, tts:direction="ltr" specifies a top-to-bottom inline progression direction whereas tts:direction="rtl" specifies a bottom-to-top inline progression direction.
Idk that TTML uses it, but for writing-mode: sideways
it is the opposite: ltr is bottom-to-top.
when specified on
<p>
I'm unfamiliar with the TTML markup and inheritance model, but if you have higher-level elements, shouldn't tts:direction inherit from those also?
Fwiw, a much earlier property model in CSS had writing-mode
as a shorthand for both block-direction and direction properties. (They were split out because vertical vs horizontal writing is a presentational preference, whereas bidi direction is describing the content.) If you need to preserve tts:writing-modes
’s ability to set the bidi direction when tts:direction
is not set, then you could consider a similar model, where tts:writing-mode
sets both direction
and writing-mode
and tts:direction
sets only direction
. But if there's no compat risk, I might suggest taking the same model as CSS and using only tts:direction
for RTL.
@palemieux I see no inconsistency here. The text of XSL 1.1 §5.8 makes it clear that inline progression direction at the block level is determined by writing mode, and within inline formatting objects by a combination of the Unicode Bidi Algorithm and the tts:unicodeBidi
and tts:direction
properties. The semantics of tts:direction
clearly specify that they are applied only in two cases (1) when applied to p
to determine the default paragraph level and (2) when used in combination with tts:unicodeBidi
. Note also that an author is free to employ Unicode Bidirectional Control characters as an alternative to or in addition to style markup, e.g., instead of using tts:unicodeBidi
and tts:direction
properties.
If an author specifies, e.g., that a region has tts:writingMode="rl"
but then specifies a tts:direction="ltr"
on a p
in that region, then there is no semantic (or processing) inconsistency: you have a Left-to-Right paragraph in a outer Right-to-Left region. This is perfectly well defined as far as UAX#9 and XSL formatting semantics are concerned.
The issue regarding vertical inline progression modes is also well defined as far as I'm aware, though it would be a bit awkward since we don't define the vertical equivalent of horizontal "rl" modes, i.e., "btrl" and "btlr", the reason being that the market hasn't asked for one. Technically, one could do it with "tbrl" or "tblr" writing modes and then use tts:direction="rtl"
on paragraphs, but I know of no implementation that explicitly supports (or has tested) this combination. TTPE hasn't.
I would object to the proposed (alleged) clarification, which in my mind confuses the matter, since it does not "override" writing mode; rather, tts:direction
on p
does exactly (and only) what it already says it does in the spec:
When applied to a p element, the computed value of this property explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.
If an author specifies, e.g., that a region has tts:writingMode="rl" but then specifies a tts:direction="ltr" on a p in that region, then there is no semantic (or processing) inconsistency: you have a Left-to-Right paragraph in a outer Right-to-Left region.
Will the IPD be left-to-right in the block created by the paragraph?
@skynavga Here is the rendering I get with TTPE 7.1-SNAPSHOT
Do you confirm that it is the result you'd expect? I may have misconfigured TTPE. If not, it seems counter-intuitive when the text says "This text is displayed right to left."
I see that Direction003 is reported in the Implementation Report for TTML1, unfortunately it is not in the ttml1-tests repo. The IR says that 2 implementations passed it: "W3C / HTML5/JS" and "MS / Silverlight TimedTextPad". Are these implementations still around? I'd be curious to see their rendering. It's a pity we don't have the matching images (do we?).
@cconcolato Direction003 got moved to https://github.com/w3c/imsc-tests/blob/master/imsc1/ttml/direction/Direction003.ttml - a lot of useful TTML1 tests got moved into that repo. The render at https://github.com/w3c/imsc-tests/blob/master/imsc1/png/Direction003/0.000000.png does indeed differ:
For reference, @palemieux found this: https://www.w3.org/2008/12/dfxp-testsuite/web-framework/START.html When you try Direction003 with the only player that was passing according to https://www.w3.org/2009/05/dfxp-results.html, i.e. the HTML5 player, it gives the following:
@palemieux re: https://github.com/w3c/ttml2/issues/1211#issuecomment-668373528, the block-progression-direction and inline-progression-direction traits of the block level reference area generated by the region
are determined by the ttp:writingMode
property on that region; the block-progression-direction and inline-progression-direction traits of each block area generated by a p
element associated with that region inherit (are assigned) the same block-progression-direction and inline-progression-direction traits as its associated region's traits; the tts:direction
property on p
has no impact on these semantics; however, for the purpose of determining the inline-progression-direction of character descendants of a paragraph, the Unicode Bidi Algorithm does apply, and tts:direction
on p
sets the Default Paragraph Bidi Level for the purpose of running UAX#9 on the paragraph's character content. Once UAX#9 has been run, you end up with directionally resolved text runs which allow you to assign resolved inline-progression-direction traits to generated inline area objects that compose each line area generated by the paragraph.
To attempt to answer more succinctly, the IPD of the paragraph's generated blocks will be RTL, and, therefore, start
will mean left
. OTOH, the IPD of inline area descendants of these blocks may be RTL or LTR depending upon the result of UAX#9 processing, which includes the value of tts:direction
on p
as an input parameter.
the IPD of the paragraph's generated blocks will be RTL, and, therefore, start will mean left. OTOH, the IPD of inline area descendants of these blocks may be RTL or LTR
Two questions come to mind:
what are the use cases where the IPD of a <p>
would be rl but the IPD of its inline area descendants would be lr?
Can a <p>
have non-inline area descendants?
the IPD of the paragraph's generated blocks will be RTL, and, therefore, start will mean left. OTOH, the IPD of inline area descendants of these blocks may be RTL or LTR
Two questions come to mind:
- what are the use cases where the IPD of a
<p>
would be rl but the IPD of its inline area descendants would be lr?
What is the relevance of use case to this issue?
- Can a
<p>
have non-inline area descendants?
The XSL-FO model has p
generating line areas which are block areas, which, in turn, have inline area descendants, some of which may be inline block areas, which look like block areas in an inline context.
@cconcolato re: https://github.com/w3c/ttml2/issues/1211#issuecomment-668660828, I haven't run this against TTPE myself to verify (will do so later today), but if my results confirm this, then it would be a bug or incomplete feature implementation in TTPE, since the content of Direction003.xml appears to be reasonable from a quick viewing. However, that content does indeed raise another (unmentioned) ambiguity about the semantics of tts:direction
on p
; namely, when applied to p
, it may have one of two interpretations depending on whether there is an accompanying tts:unicodeBidi
style: if tts:unicodeBidi
is specified, then it should have sense (2) as indicated in the first paragraph of §10.2.12, but if not specified, should have sense (1).
@nigelmegitt re: https://github.com/w3c/ttml2/issues/1211#issuecomment-668693197, the alignment is bad, i.e., the outer paragraph block should be right aligned since the default for writing mode is lr; changing the default paragraph bidi level for the purpose of UAX#9 processing doesn't change the assigned writing mode: inline progression direction on the paragraph block area is still left to right
The XSL-FO model has p generating line areas which are block areas, which, in turn, have inline area descendants, some of which may be inline block areas, which look like block areas in an inline context.
Ok. Each line area extend from one to other edge of the the parent block along the inline axis and tts:direction
controls the IPD within each line area, right?
If so, in what circumstances will the rendering of the following two snippets differ?
<region xml:id="a" tts:writingMode="lr"/>
...
<p region="a">
Some text
</p>
and
<region xml:id="a" tts:writingMode="rl"/>
...
<p region="a" tts:direction="ltr">
Some text
</p>
The Timed Text Working Group just discussed (AOB) Interaction between tts:writingMode and tts:direction on <p> w3c/ttml#1211
, and agreed to the following:
SUMMARY: Continue discussions on the issue thread for the time being.
@palemieux re: https://github.com/w3c/ttml2/issues/1211#issuecomment-669982824, it is not accurate to say that
tts:direction
controls the IPD within each line area
however, it would be accurate to say that
tts:direction
may influence the inline progression direction† within inline areas descendants of line areas
more specifically, controls is too strong a word, since it is only one of a number of possible factors that influence the determination of inline progression direction, others being:
p
level) and inner scopes (within the inline generating element);p
level) and inner scopes (within the inline generating element);†The term IPD refers to inline progression dimension, not inline progression direction.
‡A UAX#9 paragraph does not necessarily correspond with a TTML p
element; i.e., a p
element can map to a sequence of UAX#9 paragraphs (separated by 0x2029 PARAGRAPH SEPARATOR characters).
Regarding the second part of re: https://github.com/w3c/ttml2/issues/1211#issuecomment-669982824, firstly, these two examples have nothing to do with your first question which I answered above, since these examples do not produce any differences in the inline progression direction of the inline area descendants of the outer block area generated by p
for the following reason:
In both of these examples, the UAX#9 paragraph level will be left to right, the text content doesn't change, and it is, with the exception of one WS character, all L class characters. The paragraph level is left to right in both cases due to:
in the first example, tts:direction
on p
inherits from region
which computed value of ltr
is determined from the inline progression direction of tts:writingMode
on region
;
in the second example, tts:direction
on p
is explicitly specified as ltr
;
therefore, the inline progression direction of every inline area generated by p
in both examples will be the same value: left to right.
However, notwithstanding the above, there will be a significant visual difference, namely, the text alignment of the two paragraphs, neither of which specify an explicit value for tts:textAlign
, and, therefore, the computed value of the text-align trait on the block areas generated by the p
elements will be start
, but, the used value will be left
in the first example, but right
in the second example. The reason for this is that the text alignment of a paragraph is determined by the inline progression direction that applies to the outer block level areas generated by the paragraph (irregardless of the inline progression direction of descendant inline block areas), and the first example has a writing mode of lr
while the second example has a writing mode of rl
.
As a final note, the initial description of this issue has a misleading statement when it suggests that the following text in [XSL-FO 1.1] §7.2.9 applies in the current context. In fact it does not apply here, since this cited text is discussing cases where one can specify both writing-mode
and direction
on the same element, and that only occurs in TTML in the case of the region
element, and we already have language for dealing with this possibility (of having both specified and in conflict), namely, see https://w3c.github.io/ttml2/index.html#style-attribute-direction-special-semantics.
To insure consistency with the "writing-mode" property, the "direction" property is initialized to the value that sets the same inline-progression-direction as is set by the "writing-mode" property whenever that "writing-mode" property sets that direction. If the "direction" property is explicitly specified on the same formatting object the value of the "direction" property will override the inline-progression-direction set by the "writing-mode".
Rendering by TTPE (7.1 Snapshot) of the above examples:
<?xml version="1.0" encoding="UTF-8"?>
<tt:tt xmlns:tt="http://www.w3.org/ns/ttml" xmlns:ttp="http://www.w3.org/ns/ttml#parameter" xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling" xmlns:ttm="http://www.w3.org/ns/ttml#metadata" ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/text" xml:lang="en">
<head>
<styling>
<initial tts:color="white"/>
</styling>
<layout>
<region xml:id="a" tts:writingMode="lrtb" tts:extent="80% 80%" tts:origin="10% 10%"/>
</layout>
</head>
<body>
<div>
<p begin="0s" end="10s" region="a">
Some text
</p>
</div>
</body>
</tt:tt>
<?xml version="1.0" encoding="UTF-8"?>
<tt:tt xmlns:tt="http://www.w3.org/ns/ttml" xmlns:ttp="http://www.w3.org/ns/ttml#parameter" xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling" xmlns:ttm="http://www.w3.org/ns/ttml#metadata" ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/text" xml:lang="en">
<head>
<styling>
<initial tts:color="white"/>
</styling>
<layout>
<region xml:id="a" tts:writingMode="rltb" tts:extent="80% 80%" tts:origin="10% 10%"/>
</layout>
</head>
<body>
<div>
<p begin="0s" end="10s" region="a" tts:direction="ltr">
Some text
</p>
</div>
</body>
</tt:tt>
(I had to modify the values of writingMode
to add tb
because TTPE would not recognize it)
So, in this case, TTPE implements the intended behavior.
I agree with most what @skynavga responded to @palemieux in https://github.com/w3c/ttml2/issues/1211#issuecomment-670982408. But the mixture of TTML specifics, CSS and XSL-FO makes it complex. So, I have still some questions. If I try to bring the pieces together I get no consistent picture.
My interpretation:
A region maps in XSL-FO to a fo:block-container object. It is the only TTML element that can map to it. An fo:block-container establishes a reference area. It is the only fo-object that is used in the derived TTML XSL-FO layout model that can establish a reference area. writingMode in XSL-FO applies only to objects that create reference areas and establishes the directionality of the edges of these reference areas, in our case for the start and end edges. Therefore in TTML writingMode can only be applied to a region. So far I agree. But I wonder if direction specified on a region also changes the directionality of the edges of a reference area. I think that XSL-FO is a bit ambiguous here. On the one hand as @skynavga mentions, XSL 1.1 §7.2.9 states:
If the "direction" property is explicitly specified on the same formatting object the value of the "direction" property will override the inline-progression-direction set by the "writing-mode".
But later it also says in the same listing:
The "direction" property only changes the inline-progression-direction and is used primarily for formatting objects that generate inline-areas that are not also reference areas. Use of the "direction" property for other formatting objects is deprecated in this specification.
"direction" as property can also not be applied to a fo:block-container (of course this does not exclude specification on it).
I think the first point of the XSL-FO specific additions in XSL 1.1 §7.2.9 may give a hint:
The specific use of "direction" and "unicode-bidi" on inline objects is to set the inline-progression-direction to be used by the Unicode BIDI algorithm. This direction may override the inline-progression-direction determined by the current writing-mode and the implicit direction determined by the Unicode BIDI algorithm.
My interpretation is that "direction" does not intervene with the directionality of the edges set by writingMode (e.g. with the question if start is left or right) and only plays a role in the application of the Unicode BIDI algorithm. My tests with an XSL-FO reference formatter confirm this assumption.
Regarding the test cases: I propose to use more complex samples that combine characters with strong, weak and neutral bidi_types e.g. the text 1) Some text.
That also shows how the character stacking is influenced by writingMode, direction and unicode-bidi.
My interpretation is that "direction" does not intervene with the directionality of the edges set by writingMode (e.g. with the question if start is left or right) and only plays a role in the application of the Unicode BIDI algorithm
That was my initial interpretation as well. I have however since run into two issues (as described at https://github.com/w3c/ttml2/issues/1211#issue-671225583):
My interpretation is that "direction" does not intervene with the directionality of the edges set by writingMode (e.g. with the question if start is left or right) and only plays a role in the application of the Unicode BIDI algorithm
That was my initial interpretation as well. I have however since run into two issues (as described at #1211 (comment)):
- this contradicts the stated intent of Direction003.html
- there is no mapping to CSS as far as I know
How does it conflict with Direction003.xml (not html)? The text of Direction003.xml should indeed be right to left because of the tts:unicodeBidi='override'
combined with tts:direction='rtl'
. There should be no difference between the behavior of Direction003.xml and
<p>‮This text is displayed right to left.‬</p>
and
<p><span tts:unicodeBidi="override" tts:direction="rtl">This text is displayed right to left.</span></p>
Please ignore the behavior of TTPE for Direction003.xml as there is a bug at work.
Please ignore the behavior of TTPE for Direction003.xml as there is a bug at work.
Thanks for clarifying.
Note that this comment was updated based on below comments by @nigelmegitt and @skynavga. Thanks for that!
I created samples in TTML, XSL-FO, HTML/CSS. Driving questions:
@tts:direction
is specified on <tt:region>
or <tt:p>
?Fictional use case: a sports program in Arabic. In a three-row subtitle a coach of an English team is cited as follows:
The English coach has two goals:
"1) We win the championship!
2) We play fair!"
The first sentence of the subtitle is written in Arabic.
The subtitle should be aligned at the right edge of the video. Relative values should be used to set in TTML the text alignment.
I covered three cases:
@tts:direction
is not specified@tts:direction
is specified on a <region>
element@tts:direction
is specified on the <p>
elementEach row of the subtitle is wrapped in a <p>
element. All <p>
elements are in the same region. For the <region>
element the @writingMode
attribute is set to rltb
. This results in a right-to-left inline progression direction and a top-to-bottom block progression direction.
@tts:direction
is not specifiedNo measure is taken to adapt to the bi-directionality of the subtitle. @tts:direction
is not specified explicitly.
* The TTML to XSL-FO mapping is based on the samples in TTML2, 11.3.1.4 Synchronic Flow Processing. The XSL-FO rendering was checked with two XSL-FO formatters.
@tts:direction
is specified on a <region>
elementThe assumption is that the value of @tts:direction
changes the inline progression direction in a way as if it would have been specified as part of the @tts:writingMode
. If (as in the below case) the value of @tts:writingMode
is rltb
and @tts:direction
is set to ltr
then (following this assumption) the layout would be the same as if the value of @tts:writingMode
would have been lrtb
.
In the sample @tts:direction
on the <region>
element is inherited to all <p>
in that region. Therefore it sets the paragraph embedding level or base direction for that <p>
elements.
@tts:direction
is specified on the <p>
element@tts:direction
is used to adapt to the bi-directionality of the subtitle and marks the English citation as a left-to-right sequence.
This may be a typical example where a text sequence, with a horizontal writing direction opposite to the main horizontal writing direction, is just added, and no further adjustments are made. The TTML to XSL-FO mapping is straightforward. The writing-mode
attribute of the <fo:block-container>
element is set to rl-tb
. The <fo:block-container>
represent the TTML <region>
element.
In CSS (as @fantasai mentioned in https://github.com/w3c/ttml2/issues/1211#issuecomment-667596464) the (inline-progression-)direction was factored out of the writing-mode
property. To change the horizontal writing direction the direction
property must be used. Because the default of the direction
property is ltr
for a left-to-right direction, it has to be set explicitly to rtl
to achieve the same effect as in the TTML sample.
For the fictional use case, it seems not a rational option but it is considered here to discuss the use of @tts:direction
on <region>
. A syntactic mapping to XSL-FO is not straightforward as @direction
can not be specified on a <fo:block-container>
element. @direction
can only be specified on the <fo:bidi-override>
element. <fo:bidi-override>
can not be a child element of <fo:block-container>
. Therefore the only way to achieve the same result as in TTML is to change the value of to wrap the text content of all @writing-mode
on <fo:block-container>
from rl-tb
to lr-tb
.<fo:block>
elements in the <fo:block-container>
with a <fo:bidi-override>
element (see also case 3).
The mapping to CSS is straightforward as the The solution pattern is the same as in case 3 with the exception that it has to be applied to all HTML direction
property sets the inline progression direction. The value can be changed from rtl
to ltr
or direction
can be omitted completely (because the default value of the direction
property is ltr
).<p>
elements that correspond to TTML <p>
elements in that region.
To adapt to the bi-directionality of the subtitle in TTML @direction
needs to be set explicitly for the English citation. By the specification of @direction
on the <p>
elements with the English text with a value of ltr
, the initial embedding level of the paragraph is set to a value for left-to-right and numbers, quotes and parenthesis appear as intended. The interpretation of TTML is that the tts:unicodeBidi
default value does not need to change.
A TTML <p>
element maps in XSL-FO to a <fo:block>
element. An <fo:block>
element can not have a @direction
attribute*. An <fo:block>
can have <fo:bidi-override>
as a child element that wraps the inline content. But it is not sufficient to set @direction
on <fo:bidi-override>
to <ltr>
. To set a new embedding level @unicode-bidi
on <fo:bidi-override>
needs to be set explicitly to embed
. Otherwise, the default value normal
of @unicode-bidi
would apply and the value of @direction
would not have any effect.
The mapping to CSS requires to add a new <span>
element that wraps the text content of the <p>
element. A direction
property with a value of ltr
and a unicode-bidi
property with the value of embed
needs to apply to this <span>
element.
A strategy where direction
and unicode-bidi
apply to corresponding HTML <p>
elements would not work because this would also change the reference inline progression direction for the alignment of the text (which is not desired). The application of this strategy is documented in a CodePen and a Gist
* This is based on an interpretation of the XSL-FO spec and the testing with two XSL-FO formatters.
Overall the TTML specification seems to be consistent in it itself but the divergence from XSL-FO and CSS in some aspects may make the application of tts:writingMode
, tts:direction
and tts:direction
difficult for implementers.
Therefore two changes could be discussed for a future version of TTML:
Deprecate the use of the @direction
attribute on a <region>
element.
Deprecate the use of the @direction
on a <p>
element.
@direction
can be set in XSL-FO only on the inline element fo:bidi-override
. From this perspective, it is very similar to a <span>
element in HTML on which the direction
and unicode-bidi
CSS properties apply. <p>
HTML elements may leed to false expectations regarding the rendering result. @tts:unicodeBidi
attribute needs to have the value embed
to change the paragraph embedding level (instead of keeping the default value normal
). Although this seems not an error it makes the application of this pattern difficult to understand.@tairt Thanks for the detailed thoughts and sharing those carefully thought through examples. I have one question:
- Deprecate the use of the
@direction
attribute on a<region>
element.
Did you notice that tts:direction
does not apply to <region>
, but only to <p>
and <span>
, therefore even if it is specified on a region, that is only used as the basis for inheritance down to the p
and span
level?
My understanding is that inheriting tts:direction
from a region
to derive its computed value is no different to specifying the same value on the p
itself, so case 2 effectively becomes the same as case 3.
Did you notice that tts:direction does not apply to
, but only to and , therefore even if it is specified on a region, that is only used as the basis for inheritance down to the p and span level?
Good point.
My understanding is that inheriting tts:direction from a region to derive its computed value is no different to specifying the same value on the p itself, so case 2 effectively becomes the same as case 3.
In case 3 you can specify @tts:direction
on each <p>
individually. In case 2 it applies to all <p>
elements in that region.
Based on https://github.com/w3c/ttml2/issues/1211#issuecomment-674982796 by @nigelmegitt the rendering result for the case 2 TTML sample should be as documented in https://gist.github.com/tairt/78256a2e297f37e62f80dfb901b35e89.
@skynavga: Is this also your understanding?
@tairt actually, neither image is correct; the 2nd image would be correct, were the Arabic letters properly joined, but they are not.
@skynavga Thanks for having a look at it! I need to check where the error in the IMSC rendering occurred. Can you have a look at the new rendering: https://gist.github.com/tairt/78256a2e297f37e62f80dfb901b35e89#gistcomment-3422011 This formatting is the result of an XSL-FO input document where the block with the Arabic text is wrapped by an <fo:bidi-override>
element where @direction
is set to ltr
and @unicode-bidi
to embed
.
@tairt this last image https://gist.github.com/tairt/78256a2e297f37e62f80dfb901b35e89#gistcomment-3422011 appears correct as far as I can tell, though I can't be 100% for certain since I don't know the exact characters encoded in the source TTML file (if all of the content of the first paragraph were encoded using numeric character references, then I could check with certainty).
@tairt I am assuming that the character that appears to be a COLON in the first paragraph is U+0030; I would want to check its logical position in the paragraph, e.g., whether it came first or last; I am guessing it may be at the logical end of the paragraph, which would place it on the right if the paragraph level is set to left-to-right due to inheriting tts:direction="ltr"
@tairt I've finally taken a look at your original post at https://github.com/w3c/ttml2/issues/1211#issuecomment-674975249; my first observation is that it isn't necessary to use tts:direction
at all: one could do everything with directional formatting characters and one explicit writing mode property on the region; my second observation is that tts:direction
is only used as a parameter for tts:unicodeBidi
(and only when its computed value is not normal
) except in the case of when it is applied to p
for the purpose of assigning a paragraph level for UAX#9 processing; in all other cases, tts:direction
has no semantics;
Regarding Case 1, I don't know what you mean by "No measure is taken to adapt to the bi-directionality of the subtitle." The explicit presence of directional formatting characters as well as the implicit semantics of UAX#9 still apply. I can't tell if there are any directional formatting characters present in the example. In any case, even if they are not, the defaulting semantics of TTML2 §10.2.12.1 apply, both at p
and span
levels via inheritance.
Regarding Case 2, this is based on a bogus assumption that is not supported by the specification text. There is and was no intended reading (either in TTML or via XSL-FO semantics) that specifying tts:direction
on region
would cause a specification of tts:writingMode
on region
to have its inline progression direction be reinterpreted to match tts:direction
.
Regarding Case 3, tts:direction
never causes a change in the value of tts:unicodeBidi
; rather, tts:direction
serves as a parameter for interpreting the semantics of tts:unicodeBidi
when the value of the latter is not normal
in the context of its application to a p
or a span
element during UAX#9 processing. In addition, tts:direction
serves as a parameter in computing the paragraph level of a UAX#9 paragraph text unit during UAX#9 processing.
It is not correct that an fo:block
element cannot have a direction
property. It certain can specify a direction
property, which is inherited by descendant fo:bidi-override
elements. Regarding use of unicode-bidi='embed'
, it could also be unicode-bidi='override'
, and, in the TTML2 case, tts:unicodeBidi='isolate'
.
For CSS mapping, directional formatting characters are also an option.
Regarding Thoughts, I disagree with the proposal to deprecate tts:direction
on region
, as it is based on a misunderstanding of current TTML semantics. Furthermore, I disagree that it has a direct mapping to XSL-FO, though it may be argued that the current mapping specification could be improved (I have previously stated that this mapping is intentionally vague in this area for practical reasons). I also disagree with the proposal to deprecate on p
as being premature. As I have pointed out here and elsewhere, the tts:unicodeBidi
and tts:direction
properties were originally introduced in CSS, adopted into XSL-FO, and then TTML as an alternative to encoding the same semantics directly in plaintext by way of Unicode's directional formatting characters, a mechanism that still exists alongside the stylesheet approach to this authoring. If the TTWG were to seriously entertain deprecation, then the first option must be to jettison both tts:unicodeBidi
and tts:direction
and simply revert to the plaintext Unicode approach clearly documented by UAX#9.
I'm adding this to the agenda for tomorrow's call. The things I'd like to check on are:
tts:writingMode
, tts:direction
etc as they apply to a <p>
element?Do we have consensus on the intended semantics of tts:writingMode, tts:direction etc as they apply to a
element?
I am still unsure of the difference between the following two snippets:
<region xml:id="a" tts:writingMode="lr"/>
...
<p region="a" tts:direction="rtl" tts:unicodeBidi="<not normal>">
...
</p>
and
<region xml:id="a" tts:writingMode="lr"/>
...
<p region="a">
<span tts:direction="rtl" tts:unicodeBidi="<not normal>">...</span>
</p>
@palemieux wrote
I am still unsure of the difference between the following two snippets: ....
Good point, @palemieux . Based on your example the below table compares the different options:
@tts:direction |
@tts:unicodeBidi |
Comparison between setting both attributes on <p> or <span> |
---|---|---|
rtl | embed | Same result |
rtl | bidiOverride | ? |
rtl | isolate | ? |
For the value of embed
there should be no difference
For the value of bidiOverride
and isolate
this is less clear to me. If we take the following text from TTML for @tts:direction
:
When applied to a p element, the computed value of this property explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.
When applied to a span element (or anonymous span), the computed value of this property, in combination with the computed value of the tts:unicodeBidi style property, determines the directionality of a bidirectional embedding or override as specified by [UAX9], §4.3, Higher Level Protocol HL3.
For a <p>
element it only specifies that it sets the embedding level/base direction (of the paragraph). It does not say that it imposes in combination with tts:unicodeBidi a directional override or isloate as specified by UAX9, §4.3, Higher Level Protocol HL3. But it does say that for <span>
.
On the other hand @tts:unicodeBidi
applies to <p>
and it can not be inherited (in contrast to @tts:direction
). So the main question is how @tts:unicodeBidi
applies to <p>
.
@skynavga Thanks for taking the time to go through the comment and for your detailed answer. I will reply to your comments soon. I updated already the part on case 2 in https://github.com/w3c/ttml2/issues/1211#issuecomment-674975249.
Do we agree that the expected rendering of Direction003 is the alignment shown by TTPE with the character ordering shown by IMSC.js or the HTML5 player?
@palemieux re: https://github.com/w3c/ttml2/issues/1211#issuecomment-676466382, a few examples will suffice:
<p tts:unicodeBidi='embed' tts:direction='rtl'>ABC</p> ==>
‫ABC‬
<p><span tts:unicodeBidi='embed' tts:direction='rtl'>ABC</span></p> ==>
‫ABC‬
<p tts:unicodeBidi='embed' tts:direction='rtl'><span tts:unicodeBidi='embed' tts:direction='rtl'>ABC</span></p> ==>
‫‫ABC‬#x202C;
N.B. [CSS2.1] §9.10 "The final order of characters in each block container is the same as if the bidi control codes had been added as described above, markup had been stripped, and the resulting character sequence had been passed to an implementation of the Unicode bidirectional algorithm for plain text that produced the same line-breaks as the styled text."
@skynavga Thanks for the helpful comments in https://github.com/w3c/ttml2/issues/1211#issuecomment-675862088 . See below my reply to some of them.
my first observation is that it isn't necessary to use
tts:direction
at all: one could do everything with directional formatting characters and one explicit writing mode property on the region;
As I understand chapter 2.7 of UAX 9 "Where available, markup should be used instead of the explicit formatting characters".
Regarding Case 1, I don't know what you mean by "No measure is taken to adapt to the bi-directionality of the subtitle."
In the sample, I assume that the author does not change the directionality of the text (which is right-to-left). Therefore Latin text may lead to unintended results (as shown in the rendering).
The explicit presence of directional formatting characters as well as the implicit semantics of UAX#9 still apply. I can't tell if there are any directional formatting characters present in the example.
For the check you may take the GIST as "Raw".
Regarding Case 2, this is based on a bogus assumption that is not supported by the specification text. There is and was no intended reading (either in TTML or via XSL-FO semantics) that specifying
tts:direction
onregion
would cause a specification oftts:writingMode
onregion
to have its inline progression direction be reinterpreted to matchtts:direction
.
I changed the description and samples for case 2 in the above comment. The question is if the specification text could be clearer. Most of the readers of the specification may not know that there is an inline progression direction for writingMode
that sets the edges and a separate one that is used to apply UAX9.
Regarding use of
unicode-bidi='embed'
, it could also beunicode-bidi='override'
, and, in the TTML2 case,tts:unicodeBidi='isolate'
.
Additional text for the application of tts:unicodeBidi
on <p>
when the value is override
or isolate
may be useful.
Regarding Thoughts, I disagree with the proposal to deprecate
tts:direction
onregion
, as it is based on a misunderstanding of current TTML semantics.
To be clear: it was a proposal to discuss the potential changes not to make them.
Overall it may help if we set priorities on different goals of our discussion. Goals could be:
@cconcolato wrote
Do we agree that the expected rendering of Direction003 is the alignment shown by TTPE with the character ordering shown by IMSC.js or the HTML5 player?
I tend to agree but we possibly should first have a common understanding of how writingMode, direction and unicodeBidi influence each other. After we agreed on the steps that apply and their order it may be easier to agree on the rendering.
@skynavga Thanks for the explanation which is possibly the simplest I have seen so far. Can you confirm that specifying direction
and unicodeBidi
on p
can always be replaced by wrapping the contents of the p
with a span with direction
and unicodeBidi
specified on it?
The Timed Text Working Group just discussed Interaction between tts:writingMode and tts:direction on paragraph element.
, and agreed to the following:
SUMMARY: Conversation resulted in 4 key questions - see IRC log above.
What does "establishing the paragraph embedding" level mean?
I meant to say paragraph level.
Per your answer for (2), it sounds like applying tts:direction
on p
(and thus establishing the paragraph level) is equivalent to generating a child anonymous span with the same values for tts:direction
and tts:unicodeBidi
.
Comments on the responses to the questions of https://github.com/w3c/ttml2/issues/1211#issuecomment-677749316:
- Compute start and end edges - does tts:direction on p affect it, yes/no?
@skynavga wrote:
No. Nothing in the specification supports such a reading, and no such intention existed. There seem to be agreement on this question.
- What is unicodeBidi doing on p given it is applicable but the text for tts:direction mentions unicodeBidi combination only for the span?
@skynavga wrote:
The main function of
tts:unicodeBidi
andtts:direction
(as a pair) onp
comes into play when text node children ofp
ends up being reparented onto an anonymous span that then has thep
as its parent.
Given the following case:
<p tts:unicodeBidi="bidiOverride" tts:direction="rtl">
<span tts:color="yellow">1) Oh!</span>
</p>
I assume that in this case the text node in the span will not be re-parented to the <p>
element. @skynavga: If this assumption is correct: Do you say that in this case tts:unicodeBidi
will not reverse the text 1) Oh!
?
@skynavga wrote:
This could be the subject of a new note, definitely informative in nature.
I think we coming to an agreement that additional text may be helpful.
What does "establishing the paragraph embedding" level mean?**
@skynavga wrote:
That phrase doesn't appear in the specification, and I don't believe I used that phrase above either.
"paragraph embedding level" is a term from UAX9, https://unicode.org/reports/tr9/#BD4. But possibly @skynavga pointed to "establishing"?
A good way to get an idea about the role of the paragraph embedding level in UAX9 is to follow the steps X1 to X9 (https://unicode.org/reports/tr9/#X1). It becomes clear already at the beginning.
@palemieux wrote as a response to @skynavga:
Per your answer for (2), it sounds like applying tts:direction on p (and thus establishing the paragraph level) is equivalent to generating a child anonymous span with the same values for tts:direction and tts:unicodeBidi.
This may not completely the case. The final representation may be the same. But as I read it the depth of the embedding levels could be different.
No. Nothing in the specification supports such a reading, and no such intention existed.
The semantic derivation of tts:padding and of tts:textAlign seem to. This should probably be clarified. This is also related to @skynavga's statement:
the text alignment of a paragraph is determined by the inline progression direction that applies to the outer block level areas generated by the paragraph (irregardless of the inline progression direction of descendant inline block areas)
It is not obvious from the spec today.
@tairt Re: https://github.com/w3c/ttml2/issues/1211#issuecomment-681005169
Question 2
- What is unicodeBidi doing on p given it is applicable but the text for tts:direction mentions unicodeBidi combination only for the span?
@skynavga wrote:
The main function of
tts:unicodeBidi
andtts:direction
(as a pair) onp
comes into play when text node children ofp
ends up being reparented onto an anonymous span that then has thep
as its parent.Given the following case:
<p tts:unicodeBidi="bidiOverride" tts:direction="rtl"> <span tts:color="yellow">1) Oh!</span> </p>
I assume that in this case the text node in the span will not be re-parented to the
<p>
element. @skynavga: If this assumption is correct: Do you say that in this casetts:unicodeBidi
will not reverse the text1) Oh!
?
No, your assumption is wrong. First, you need to follow through the semantics of [construct anonymous spans]. Second, you need to follow through the semantics of UAX#9 with respect to the meaning of applying an enclosing RLO/PDF pair.
@skynavga wrote:
This could be the subject of a new note, definitely informative in nature.
I think we coming to an agreement that additional text may be helpful.
Although I did say it might be helpful, I did not suggest it was necessary.
I also did not remind of the second function of tts:direction
on p
, which I will deal with more below.
Question 3
What does "establishing the paragraph embedding" level mean?**
@skynavga wrote:
That phrase doesn't appear in the specification, and I don't believe I used that phrase above either.
"paragraph embedding level" is a term from UAX9, https://unicode.org/reports/tr9/#BD4. But possibly @skynavga pointed to "establishing"?
A good way to get an idea about the role of the paragraph embedding level in UAX9 is to follow the steps X1 to X9 (https://unicode.org/reports/tr9/#X1). It becomes clear already at the beginning.
@palemieux wrote as a response to @skynavga:
Per your answer for (2), it sounds like applying tts:direction on p (and thus establishing the paragraph level) is equivalent to generating a child anonymous span with the same values for tts:direction and tts:unicodeBidi.
This may not completely the case. The final representation may be the same. But as I read it the depth of the embedding levels could be different.
Andreas is correct here [this is not ... the case]. The current specification text on tts:direction
When applied to a p element, the computed value of this property explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.
is not
equivalent to generating a child anonymous span with the same values for
tts:direction
andtts:unicodeBidi
While it is somewhat close to wrapping with a tts:unicodeBidi='isolate'
, it would have to be performed after subdividing the content of p
into UAX#9 Paragraphs. Keep in mind that a UAX#9 Paragraphs doesn't correspond 1-to-1 with a p
element. In particular, a p
element may map to a sequence of UAX#9 Paragraphs, e.g., if it contains multiple U+2029 PARAGRAPH SEPARATOR characters.
So, given a p
element as input, one possible processing model is:
p
tts:unicodeBidi
and tts:direction
pairs with directional formatting characterstts:direction
on p
As you might guess, this is basically the algorithm used by TTPE.
Thanks, @skynavga
Just for discussion, I add a graph with dependencies of specifications.
The Timed Text Working Group just discussed Interaction between tts:writingMode and tts:direction on paragraph element. w3c/ttml2#1211
, and agreed to the following:
SUMMARY: Keep working towards answers to the questions!
As discussed earlier today: can we think of any use cases where it is necessary to set the paragraph level to a direction other than the inline writing direction?
This feature is supported by TTML2 but not CSS as far as I know.
If we can come up with use cases, then we should submit them to CSS.
If we cannot come up with use cases, then we should consider either:
tts:direction
on p
affects the inline progression direction (see https://codepen.io/palemieux/pen/NWNjyWJ)tts:direction
applicable on span
only, either in TTML2 or through constraints in IMSC@tairt re: https://github.com/w3c/ttml2/issues/1211#issuecomment-681964894, this is a misleading figure as it does not distinguish between normative and informative references; the references to CSS Writing Modes are informative, and entirely irrelevant to the present discussion IMO
@palemieux re: https://github.com/w3c/ttml2/issues/1211#issuecomment-682074562, this is a revisionist view of history given the semantics of tts:direction
on p
came from CSS2 directly, long before CSSWG wrote CSS Writing Modes and attempted to glom it on top of CSS2
this is a revisionist view of history
I am not making a statement on the history of CSS, only how I think CSS is implemented today. If an essential feature was lost in the crafting of CSS Writing Modes, then we should report it. This is why I recommend we identify essential use cases that are not supported by CSS in its current form.
TTML2 specifies:
When applied to a p element, the computed value of
tts:direction
explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.It is unclear how this interacts with
tts:writingMode
. Specifically:are there any cases where
tts:direction
andtts:writingMode
should conflict on<p>
? In other words, does specifyingtts:direction="ltr"
ever make sense iftts:writingDirection="rl
? CSS does not allow this inconsistency.what does
tts:direction
mean when the IPD is vertical? UAX #9, clause 6.2 implies thattts:direction
should affect character rotation, but, again, this is ignored by CSS.the Direction003.html test case implies that specifying
tts:direction="rtl"
on<p>
changes the IPD.XSL specifies that
If the "direction" property is explicitly specified on the same formatting object the value of the "direction" property will override the inline-progression-direction set by the "writing-mode".
I suggest considering the following clarification:
when specified on
<p>
,tts:direction
sets the inline progression direction, overriding that set bytts:writingDirection
. In the case where the block progression direction is horizontal,tts:direction="ltr"
specifies a top-to-bottom inline progression direction whereastts:direction="rtl"
specifies a bottom-to-top inline progression direction.