search

w3c / ttml2

Timed Text Markup Language 2 (TTML2)
https://w3c.github.io/ttml2/
Other
41 stars 16 forks source link

Interaction between tts:writingMode and tts:direction on paragraph element. #1211

Open palemieux opened 4 years ago

palemieux commented 4 years ago

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:

I suggest considering the following clarification:

when specified on <p>, tts:direction sets the inline progression direction, overriding that set by tts:writingDirection. 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.

fantasai commented 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.

skynavga commented 4 years ago

@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.

palemieux commented 4 years ago

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?

cconcolato commented 4 years ago

@skynavga Here is the rendering I get with TTPE 7.1-SNAPSHOT ttpi000001 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?).

nigelmegitt commented 4 years ago

@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:

Direction003

cconcolato commented 4 years ago

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:

Screen Shot 2020-08-04 at 10 43 09 AM
skynavga commented 4 years ago

@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.

palemieux commented 4 years ago

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:

skynavga commented 4 years ago

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.

skynavga commented 4 years ago

@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).

skynavga commented 4 years ago

@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

palemieux commented 4 years ago

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>
css-meeting-bot commented 4 years ago

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:

The full IRC log of that discussion <nigel> Topic: (AOB) Interaction between tts:writingMode and tts:direction on <p> w3c/ttml#1211
<nigel> github: https://github.com/w3c/ttml2/issues/1211
<nigel> Nigel: One thing I note about this is Direction003 used to be in TTML tests and has moved
<nigel> .. to IMSC tests and that has confused a couple of people independently recently.
<nigel> .. Does anyone else feel that an explainer for Where to Find TTML Tests would be a useful document?
<nigel> Pierre: Looking at Glenn's comments, he thinks TTPE's presentation is wrong.
<nigel> Nigel: He thinks the reference render is wrong though.
<nigel> Pierre: [explains how the lines in the p all use the whole width so the layout direction - scribe failure]
<nigel> Nigel: Is textAlign used in the test?
<nigel> Pierre: It would be weird for textAlign to be affected by writingMode.
<nigel> .. I think we need an answer from Glenn.
<nigel> Nigel: How do you know the line areas cover the whole width? That seems unusual.
<nigel> Pierre: Exactly.
<nigel> Pierre: Maybe we need to get everyone around the table for that with examples.
<nigel> Nigel: I'm sure if we schedule this for a meeting and invite Glenn then we can gather him and
<nigel> .. anyone else interested.
<nigel> Andreas: I planned also to look into this issue so please keep me posted if you schedule a
<nigel> .. separate meeting.
<nigel> Nigel: My default here would be to use one of these TTWG weekly calls if possible.
<nigel> Nigel: Let's allow the conversation to continue on the issue thread, and convene a meeting
<nigel> .. perhaps in 2 weeks time, if there are outstanding questions.
<nigel> Pierre: Alright.
<nigel> SUMMARY: Continue discussions on the issue thread for the time being.
skynavga commented 4 years ago

@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:

†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:

  1. 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;

  2. 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.

XSL 1.1 §7.2.9

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".

cconcolato commented 4 years ago

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>

1211-1

<?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>

1211-2

(I had to modify the values of writingMode to add tb because TTPE would not recognize it)

skynavga commented 4 years ago

So, in this case, TTPE implements the intended behavior.

andreastai commented 4 years ago

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.

palemieux commented 4 years ago

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):

skynavga commented 4 years ago

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>&#x202E;This text is displayed right to left.&#x202C;</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.

palemieux commented 4 years ago

Please ignore the behavior of TTPE for Direction003.xml as there is a bug at work.

Thanks for clarifying.

andreastai commented 4 years ago

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:

  1. Result if @tts:direction is specified on <tt:region> or <tt:p>?
  2. Mapping to XSL-FO and HTML/CSS?

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.

Cases

I covered three cases:

  1. @tts:direction is not specified
  2. @tts:direction is specified on a <region> element
  3. @tts:direction is specified on the <p> element

Each 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.

Case 1: @tts:direction is not specified

No 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.

Case 2: @tts:direction is specified on a <region> element

The 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.

Case 3: @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.

Discussion

Case 1

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.

Case 2

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 @writing-mode on <fo:block-container> from rl-tb to lr-tb. to wrap the text content of all <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 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). The solution pattern is the same as in case 3 with the exception that it has to be applied to all HTML <p> elements that correspond to TTML <p> elements in that region.

Case 3

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.

Thoughts

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:

nigelmegitt commented 4 years ago

@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.

andreastai commented 4 years ago

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.

andreastai commented 4 years ago

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?

skynavga commented 4 years ago

@tairt actually, neither image is correct; the 2nd image would be correct, were the Arabic letters properly joined, but they are not.

andreastai commented 4 years ago

@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.

skynavga commented 4 years ago

@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).

skynavga commented 4 years ago

@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"

skynavga commented 4 years ago

@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.

nigelmegitt commented 4 years ago

I'm adding this to the agenda for tomorrow's call. The things I'd like to check on are:

  1. Do we have consensus on the intended semantics of tts:writingMode, tts:direction etc as they apply to a <p> element?
  2. Is there any part of the TTML2 specification that needs to be clarified or improved to help readers understand this consensus? (another possibility is that some other explainer document could be helpful)
palemieux commented 4 years ago

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>
andreastai commented 4 years ago

@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>.

andreastai commented 4 years ago

@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.

cconcolato commented 4 years ago

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?

skynavga commented 4 years ago

@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>  ==>
&#x202B;ABC&#x202C;
<p><span tts:unicodeBidi='embed' tts:direction='rtl'>ABC</span></p>  ==>
&#x202B;ABC&#x202C;
<p tts:unicodeBidi='embed' tts:direction='rtl'><span tts:unicodeBidi='embed' tts:direction='rtl'>ABC</span></p>  ==>
&#x202B;&#x202B;ABC&#x202C;#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."

andreastai commented 4 years ago

@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 on region would cause a specification of tts:writingMode on region to have its inline progression direction be reinterpreted to match tts: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 be unicode-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 on region, 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:

andreastai commented 4 years ago

@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.

palemieux commented 4 years ago

@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?

css-meeting-bot commented 4 years ago

The Timed Text Working Group just discussed Interaction between tts:writingMode and tts:direction on paragraph element., and agreed to the following:

The full IRC log of that discussion <cyril> Topic: Interaction between tts:writingMode and tts:direction on paragraph element.
<nigel> github: https://github.com/w3c/ttml2/issues/1211
<nigel> s/Topic: Interaction between tts:writingMode and tts:direction on paragraph element.//
<cyril> nigel: good discussion and lots of detailed technical inputs
<cyril> ... thanks Pierre for raising this issue
<cyril> ... I asked yesterday do we have consensus?
<atai> q+
<cyril> ... Pierre said it wasn't clear
<cyril> ... the difference between specifying direction/unicodeBidi on a p vs on a span
<cyril> ... Glenn put some equivalences in
<cyril> ... do we think we got to some kind of understanding
<cyril> ack atai
<cyril> atai: while working through it, I noticed that it is complex, too many specs
<cyril> ... my proposal would be to go systematically through the issue
<cyril> ... and see if we have a common understanding
<cyril> ... for example going with direction on region and p
<cyril> ... and see if the specification text is clear to represent our understanding
<cyril> nigel: you created 3 cases
<cyril> ... and generated reviews for them
<cyril> ... in the end from doing that, do you think we did get to something that made sense to you?
<cyril> ... I did not detect any disagreement
<cyril> ... but I want to check
<cyril> atai: I want to be really sure about it
<cyril> ... for region, what I got from the discussion
<cyril> ... is that inline progression direction influences start/left...
<cyril> ... using writing mode
<cyril> ... there are 2 kinds of inline progression direction
<cyril> ... one to set the edges that influences alignment
<cyril> ... and then the inline progression direction that is used to apply the unicode bidi algo
<cyril> ... and these 2 are separate
<cyril> ... tts:direction never influences the inline progression direction of writing mode
<nigel> scribe: nigel
<nigel> Cyril: I agree with you Andreas that there are two concepts.
<nigel> .. Not sure they're called Inline progression direction in both cases.
<nigel> Andreas: From the spec it's not clear.
<pal> q+
<nigel> .. Glenn commented that there are separate directions, for writing mode and direction.
<nigel> Cyril: Also what makes the discussion difficult is that we refer a lot fo XSL-FO,
<nigel> .. and I'm not sure that our spec contains enough information to understand writingMode,
<nigel> .. direction and textAlign without going deep into XSL-FO.
<nigel> Andreas: Yes, I tried to look through the different references and it's really difficult because
<nigel> .. direction came from CSS 2 to XSL-FO and both use the Uniode bidi algorithm,
<nigel> .. and then we have the new setting how CSS is handling writing mode and direction.
<nigel> .. We should first check our common understanding and then check back to the references.
<nigel> .. I agree with you Cyril that there is not enough text in TTML2 to understand the concepts
<nigel> .. and how they apply.
<cyril> scribe: cyril
<cyril> atai: if tts:direction is set on the region
<cyril> ... my understanding is that the only effect is that it is inherited to the p
<nigel> q+ to check if there is enough text in TTML2 to define (rather than explain) the concepts
<cyril> cyril: me too
<cyril> atai: it was surprising that tts:unicodeBidi is not inheritable
<cyril> ... so only tts:direction makes sense on region
<cyril> ... so it inherits to the p and there set the paragraph embedding level
<cyril> ... on the p if only unicodeBid is specified, then it would be combined
<cyril> ack pal
<cyril> pal: I agree on the inheritance business
<cyril> ... glenn's latest explanation on tts:direction is the cleanest I've seen
<cyril> ... it's the combination of tts:direction and unicodeBidi that inserts the code
<cyril> ... and this explains everything
<atai> q+
<cyril> ... tts:direction would have no effect on writing mode
<cyril> ... I'd like to see if this explanation is accurate
<cyril> ... I see no reason why tts:direction and unicodeBidi should apply to p
<cyril> ... because it insert control characters
<cyril> ... and that is clearly an inline matter that belongs to span
<cyril> s/inserts the code/inserts control characters/
<cyril> cyril: maybe because of anonymous spans
<cyril> nigel: [reads the spec]
<cyril> ... the algo that we are referencing requires a paragraph embedding level
<nigel> > 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.
<cyril> pal: I wanted to understand what it meant
<cyril> ... glenn's latest answer seems to indicate that applying on p or applying on the single child span has the same effect
<cyril> atai: what's missing from Glenn's example is what happens if you set direction without setting unicodeBidi
<cyril> ... if you set tts:direction on a p, it sets the paragraph embedding level, regardless of the value of unicodeBidi
<cyril> ... that's a different concept from inserting control characters
<cyril> ... at least that's what I understand
<nigel> q?
<cyril> pal: then I still don't understand
<cyril> ... what happens when you set tts:direction and unicodeBidi on p
<cyril> ... I read the words but ...
<nigel> ack nige
<Zakim> nigel, you wanted to check if there is enough text in TTML2 to define (rather than explain) the concepts
<cyril> nigel: 1) I wanted to ask if there is enough text in TTML2 to define the concepts
<cyril> ... 2) one of the things that get affected by writing mode is textAlign (start and end)
<cyril> ... and looking at the text of textAlign it does not define what start and end mean
<cyril> ... there is a semantic derivation
<cyril> ... which talks about start and end
<cyril> ... we seem to be in a knot of complicated spec
<atai> q+
<cyril> ... it does not seem to make any sense to have textAlign based on the span, maybe on the p and the region
<cyril> q
<cyril> q+
<cyril> pal: I had concluded that tts:direction and unicodeBidi did nothing to inline progression direction but now I'm confused
<cyril> ... what prompted me to raise this issue, in CSS it is NOT possible to set the equivalent of tts:direction and unicodeBidi on p
<nigel> -> https://www.w3.org/TR/2018/CR-css-writing-modes-3-20180524/#logical-to-physical CSS dependency that defines inline-start and inline-end
<cyril> ... because p is a block it also sets writing mode
<nigel> -> https://www.w3.org/TR/2018/REC-ttml2-20181108/#derivation-padding TTML2 reference that maps inline-start and inline-end to start and end
<cyril> ... the way I read CSS, if you set unicodeBidi and direciton on a span (which is an inline element) it has the same effect as in TTML
<nigel> q+ to mention the CSS abstract - physical mapping
<cyril> ... but on p, setting tts:direction on p, also sets the ipd
<cyril> s/ipd/inline progression direction
<nigel> q?
<nigel> ack atai
<cyril> atai: it's not possible to compare CSS in its current form to TTML, because it derives from XSL:FO
<cyril> ... and XSL:FO derives from CSS 2 which was changed later
<cyril> ... in general with the formatting character, it is explained in the unicode bidi algo and in XSL:FO
<cyril> ... in the end all markup is converted into characters
<cyril> ... but before there are steps in setting fo bidi override elements to refine the formatting
<cyril> ... in general what TTML2 is defining is not broken
<cyril> ... but not specified clearly
<cyril> ... especially how unicode bidi applies to p
<cyril> ... it's consistent if it works as Glenn explained
<nigel> q+ pal
<nigel> ack pal
<cyril> pal: you said 'especially how unicode bidi applies on p', glenn's response is simple
<cyril> ... it behaves the same as it behaves on p
<nigel> scribe: nigel
<cyril> s/p/span
<atai> q+
<nigel> ack cyril
<nigel> Cyril: Reading the spec (again!), the part that talks about the combination with unicodeBidi
<nigel> .. is prefixed by "when applied to a span", there's nothing about a p element there.
<nigel> q?
<nigel> .. In TTML2 §10.2.12 after the table.
<atai> +1
<nigel> ack ni
<Zakim> nigel, you wanted to mention the CSS abstract - physical mapping
<cyril> nigel: sometimes you need to know the start and end actual edges depending on writing mode and direction
<cyril> ... padding is one of the cases where you need that
<cyril> ... textAlign too
<cyril> ... CSS mapping does that
<cyril> ... and TTML lists the mapping from start and end to CSS terms
<cyril> ... and this explains why you might want to set direction on a p
<cyril> pal: long time ago, that was my understanding
<cyril> ... tts:direction on a p, changes the ipd like CSS
<cyril> ... but those 2 sentences in 10.2.12 were inserted to explicitly differ from CSS
<cyril> nigel: not sure there is a semantic difference between inline progression direction and the decoding of start and end
<cyril> ... they might be different things conceptually
<nigel> ack at
<cyril> atai: setting the edges and for the bidi algo, they are 2 different concepts
<nigel> scribe: Nigel
<nigel> atai: What's missing from the spec for how tts:direction applies to p and span, for p it
<nigel> .. just says sets the para embedding level.
<nigel> .. for span it says how it translates in combination with unicodeBidi.
<nigel> .. But it doesn't say the same for p, so there's definitely some missing text here I think.
<nigel> .. I only come to the conclusion that this must be the case because unicodeBidi applies
<nigel> .. to p, from the formal description of the attribute, so it must have the meaning as
<nigel> .. Glenn explained in his latest comment, but it needs to be reflected in the spec.
<nigel> .. What you said Nigel, is the big problem, we mix CSS and XSL-FO and it can be hard
<nigel> .. to separate them. We need to take just XSL-FO as the reference. It may be different
<nigel> .. from CSS in its current form.
<nigel> .. XSL-FO takes from CSS2 but that may be different from current CSS.
<nigel> .. I think it makes sense what Glenn says, because in TTML the region is the only
<nigel> .. element that can map to an XSL-FO element that establishes a reference area.
<nigel> .. a fo:block container. This is the only element mapped from TTML that can establish the
<nigel> .. edges, so a block as I understand it, does not have this. A p is mapped to a fo:block.
<nigel> .. This may be different from CSS but in the logical mapping from TTML to XSL-FO,
<nigel> .. it makes absolutely sense.
<cyril> scribe: cyril
<cyril> nigel: if you set padding or text align on a p and need to compute what start and end edges are
<cyril> ... Andreas is saying that the edges can only be defined by the region and never defined by the p itself
<cyril> atai: yes
<cyril> nigel: I think that is different from what our spec says in the derivation for padding
<cyril> q+
<atai> q+
<cyril> pal: if that is the case, then what does establishing the paragraph level embedding means
<nigel> scribe: nigel
<nigel> Cyril: 3 questions we have:
<nigel> .. 1. Compute start and end edges - does tts:direction on p affect it, yes/no?
<nigel> .. 2. What is unicodeBidi doing on p given it is applicable but the text for tts:direction
<nigel> .. mentions unicodeBidi combination only for the span?
<nigel> .. 3. The one Pierre mentioned. What does "establishing the paragraph embedding" level mean?
<nigel> .. Is it the same as the formatting characters or something different?
<nigel> Pierre: 4th question:
<nigel> .. Depends on the answer to the 3rd one. To the extent that in TTML it is possible to set
<nigel> .. the paragraph embedding level without also changing the start and end edges,
<nigel> .. should CSS also allow that?
<nigel> Cyril: This is a good spot to stop!
<nigel> Nigel: I was thinking the same thing!
<nigel> SUMMARY: Conversation resulted in 4 key questions - see IRC log above.
<cyril> scribe: cyril
skynavga commented 4 years ago
.. 1. Compute start and end edges - does tts:direction on p affect it, yes/no? No. Nothing in the specification supports such a reading, and no such intention existed. .. 2. What is unicodeBidi doing on p given it is applicable but the text for tts:direction .. mentions unicodeBidi combination only for the span? Historically, this came from XSL-FO ``fo:bidi-override`` which could have ``fo:block`` children. Further, CSS2 permitted it to appear on and apply to ``p``. The main function of ``tts:unicodeBidi`` and ``tts:direction`` (as a pair) on ``p`` comes into play when text node children of ``p`` ends up being reparented onto an anonymous span that then has the ``p`` as its parent. At that point, the ``tts:unicodeBidi`` and ``tts:direction`` that originally appeared on the ``p`` would be migrated to the anonymous span so as to wrap its content were directional formatting character to be substituted for the styles. [This is what I believe to be the source of the bug in TTPE, i.e., we failed to migrate the properties down to the anonymous span.] This __could__ be the subject of a new note, definitely informative in nature. .. 3. The one Pierre mentioned. What does "establishing the paragraph embedding" level mean? That phrase doesn't appear in the specification, and I don't believe I used that phrase above either. .. Is it the same as the formatting characters or something different? Pierre: 4th question: .. Depends on the answer to the 3rd one. To the extent that in TTML it is possible to set .. the paragraph embedding level without also changing the start and end edges, .. should CSS also allow that? UAX#9 uses the term "Paragraph Level", about which see §3.3.1. Is that what you mean?
palemieux commented 4 years ago

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.

andreastai commented 4 years ago

Comments on the responses to the questions of https://github.com/w3c/ttml2/issues/1211#issuecomment-677749316:

Question 1

  1. 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.

Question 2

  1. 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 and tts:direction (as a pair) on p comes into play when text node children of p ends up being reparented onto an anonymous span that then has the p 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.

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.

cconcolato commented 4 years ago

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.

skynavga commented 4 years ago

@tairt Re: https://github.com/w3c/ttml2/issues/1211#issuecomment-681005169

Question 2

  1. 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 and tts:direction (as a pair) on p comes into play when text node children of p ends up being reparented onto an anonymous span that then has the p 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!?

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 and tts: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:

  1. perform anonymous span construction on the content of p
  2. replace tts:unicodeBidi and tts:direction pairs with directional formatting characters
  3. from here to the end, ignore all markup, treating all text nodes as single sequence (string S) of linear character content
  4. subdivide S into UAX#9 paragraphs P1, P2, ...
  5. assign the UAX#9 paragraph level of each UAX#9 paragraph according to the computed value of tts:direction on p
  6. run the rest of UAX#9 processing steps to obtain resolved levels for every character in S
  7. annotate original content (as desired for subsequent processing) to record resolved bidirectional levels for every character in every text node (using whatever implementation specific optimizations are desired)

As you might guess, this is basically the algorithm used by TTPE.

andreastai commented 4 years ago

Thanks, @skynavga

Just for discussion, I add a graph with dependencies of specifications.

uax9-references

css-meeting-bot commented 4 years ago

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:

The full IRC log of that discussion <nigel> Topic: Interaction between tts:writingMode and tts:direction on paragraph element. w3c/ttml2#1211
<atai> q+
<nigel> Nigel: Good updates over the past week, are we getting closer?
<nigel> Cyril: No!
<nigel> ack ni
<nigel> github: https://github.com/w3c/ttml2/issues/1211
<nigel> Pierre: If I may I'd like to go back to the [scribe missed]
<nigel> Cyril: We asked 4 questions but don't have answers on any of them.
<nigel> .. I would like to know the opinion on semantic derivation on padding and textAlign.
<nigel> .. On the second q, he gives history about why unicodeBidi is on a p, but I don't think
<nigel> .. I have an answer because unicodeBidi is not applicable on a p but maybe there's some
<nigel> .. reparenting specific behaviour.
<nigel> .. I'm lost in the answer on the paragraph embedding level.
<nigel> .. That's what I meant by being no closer.
<nigel> q?
<nigel> ack at
<nigel> Andreas: It's the typical case where the closer you look the further it gets.
<nigel> .. My question is if we can solve individual parts of the Unicode Bidi algorithm without the
<nigel> .. big picture of how it is applied in general. The more I read about it the less clear it gets
<nigel> .. because there are so many entangled specifications.
<nigel> .. For the reader it is not clear which specification applies.
<nigel> Cyril: Are the specifications in conflict?
<nigel> Andreas: They won't fit together. For example XSL-FO was written before unicodeBidi:isolate
<nigel> .. was added to the algorithm but TTML2 uses it, so it is difficult to follow.
<nigel> .. TTML uses the layout mechanism and text handling from XSL-FO. I won't say it is in conflict
<nigel> .. but it is also not clear what Glenn tried to state in his latest post, a clear algorithm for
<nigel> .. how it all works together.
<nigel> Pierre: That's definitely where I am.
<nigel> .. In particular there is broad understanding of Unicode Bidi algo across inline elements.
<nigel> .. I still don't understand what setting unicodeBidi on p does. I don't understand that.
<nigel> .. CSS does not do that either.
<nigel> Nigel: Maybe tts:color would be a comparable example.
<nigel> .. Oh, no, it only applies to span.
<nigel> Pierre: Yes, we made changes to a number of style attributes to remove applicability to p
<nigel> .. when they only apply to span.
<nigel> .. [shares screen with codepen]
<nigel> .. Two p elements:
<nigel> .. 1st includes rtl "hello", with unicode-bidi set to override and direction: rtl
<nigel> .. In CSS direction:rtl changes the inline progression direction because it is right-aligned and
<nigel> .. the start edge is to the right.
<nigel> .. the border-inline-start: 10px solid red; shows the start edge
<nigel> .. Setting direction on p changed the writing mode and the direction of the unicode-bidi algorithm.
<nigel> .. If you do the same thing for a span within a p it does not change the start edge but it does
<nigel> .. change the writing order. The same string is still written right to left, but the line is left aligned.
<nigel> Andreas: This is what we discussed and seemed to agree, that it happens in CSS but is not
<nigel> .. aligned with TTML.
<nigel> Pierre: My fundamental question, for the first p, is that, in CSS since you cannot change
<atai> q+
<nigel> .. direction on p, without changing the progression direction, is there any circumstance when
<nigel> .. you would want to change the direction of p without changing the progression direction?
<nigel> .. If there is then we should ask for it from CSS.
<nigel> Andreas: Short answer to this: you can find a use case, like an arabic programme with an English
<nigel> .. citation, with writingMode on region but textAlign on p.
<nigel> .. It's just syntactic sugar and convenience why you can set direction on span. [scribe: ??]
<nigel> Pierre: I asked Glenn that, and he said no.
<nigel> Andreas: That's the second thing. The paragraph level is the base direction of the paragraph.
<nigel> .. In the unicode bidi algorithm this is a special construct, not the same as inserting
<nigel> .. special characters. Every p has this, but from the algorithm it is not the same.
<gkatsev> q+ to ask about border inline start for the span and contexts
<nigel> .. I need to go through the complete thing, but from now I can see that at least you may
<nigel> .. have a different count of embedding levels which would lead to exceeding the maximum
<nigel> .. number of levels depending on which option you choose. Relevant for testing but not
<nigel> .. for real world use.
<nigel> .. Algorithmically, it's not syntactic sugar but practically it is hard for me to see the difference.
<nigel> Pierre: So for instance if you try to transform TTML into HTML+CSS, when you encounter
<nigel> .. direction on p you would create a child span with direction on the child span, and that
<nigel> .. would be the rendering equivalent?
<nigel> Andreas: I hope so, yes.
<nigel> ack g
<Zakim> gkatsev, you wanted to ask about border inline start for the span and contexts
<nigel> Gary: If you colour the border inline start of the span, is it also on the right?
<nigel> Pierre: Within the span, yes.
<nigel> Gary: Then I guess this is because the p is still in the standard writing mode, it pushes the
<nigel> .. span to the left even if it it rtl.
<nigel> .. It's direction: rtl; that does something different, and it's the context that makes it look
<nigel> .. like something different is happening but for the actual element where you apply the
<nigel> .. direction the same thing is happening within it.
<nigel> Pierre: So there is no equivalent to tts:direction in CSS today because every time you set
<nigel> .. direction in CSS it does change the writing direction even if you set it on a span.
<nigel> Gary: I guess you could set writing-mode on top of it to set it manually?
<nigel> Pierre: No you can't anymore in CSS. It's only for vertical.
<atai> q+
<nigel> .. I don't mind going back to CSS and saying that their approach does not address some
<nigel> .. important use cases but otherwise the divergence between TTML and CSS is not helpful.
<nigel> ack a
<nigel> Andreas: Elika commented at the beginning that they changed it in CSS so we maybe need
<nigel> .. to go back to CSS level 1 to see if it was similar to what TTML is doing now. In general
<nigel> .. it shows how difficult it is to balance all these different specs, especially XSL-FO that is
<nigel> .. getting more and more decoupled from what is in CSS.
<nigel> .. I see no alternative but eventually to rebase TTML on CSS to have an aligned development.
<nigel> Pierre: Before that huge step, can you think of practical use cases where setting
<nigel> .. inline progression direction differently from the unicode bidi writing direction is useful?
<nigel> .. Or tell me my question is silly!
<nigel> Cyril: I'm not sure I understand the exact issue. Is it true that we can do things in TTML
<nigel> .. that we cannot map to CSS, or the opposite?
<nigel> Pierre: In this specific case, in CSS it is not possible to set the inline progression direction
<nigel> .. separately from the unicode bidi direction.
<nigel> Cyril: Is it possible to get the same effect with different elements?
<nigel> Pierre: I don't think so because setting direction also sets the writing direction. In TTML
<nigel> .. the two are set separately.
<nigel> Andreas: From my current view, from the power of expression both strategies should be
<nigel> .. equivalent so you can express both, but if not you need to find which strategy allows you
<nigel> .. to do more than the other. I don't see it at the moment.
<nigel> .. There are two different concepts of the unicode bidi algorithm and the alignment point.
<nigel> Nigel: I'm not sure if we have a clear understanding of the spec, but to the extent that we do,
<nigel> .. if we change the interpretation, that would be a bad thing for existing authored documents
<nigel> .. if they get rendered differently.
<nigel> Pierre: Looking at Direction003 test, the reference render changes both the alignment and
<nigel> .. the unicode bidi direction. That's how its been since April 2017.
<nigel> Cyril: And we agree that TTPE would show it left aligned?
<nigel> Pierre: Yes
<nigel> Cyril: And an HTML render would have it right aligned?
<nigel> Pierre: Yes, if you set direction: rtl; on p then it would right align when text alignment is start.
<nigel> Andreas: Yes, it seems that TTML is doing something different here.
<nigel> Pierre: Yes, and I'm worried about CSS being widely implemented and used...
<nigel> Cyril: ... could we limit the divergence in IMSC by saying writingMode and direction should
<nigel> .. match?
<nigel> Pierre: Yes of course, but then this test would need to be changed because this test has
<nigel> .. them not matching on p.
<nigel> Cyril: The content would then not be valid IMSC, so we would remove it.
<nigel> Pierre: I'm concerned that diverging from CSS makes it harder for people to do TTML in general.
<atai> q+
<nigel> Nigel: Another option is to state that when mapping to CSS when they don't match you have
<nigel> .. to reverse the mapping of the start and end keywords.
<nigel> ack at
<nigel> Andreas: A formal way is to do it like CSS or say don't use direction on p, possibly.
<nigel> .. The unicode bidi algorithm really applies to inline text.
<nigel> .. With writing mode set already to paragraph embedding level.
<nigel> Pierre: I think that would be a super clean solution by the way. Just remove "p" from applied to
<nigel> .. and the problem is gone completely.
<nigel> Nigel: You can still have writingMode on region though
<nigel> Pierre: Yes absolutely, it means that in TTML the only way to change the alignment is on a region.
<nigel> Nigel: And then you can't have text alignment start based on the script direction on a p by p basis.
<nigel> Pierre: That's Glenn's interpretation now though.
<nigel> Nigel: Yes that's right.
<nigel> Andreas: You can always set left and right.
<nigel> Nigel: True
<nigel> Pierre: Having a use case here would really help if we want to go back to CSS and tell them
<nigel> .. they have missed a use case. Otherwise we should explore getting closer to CSS rather
<nigel> .. than farther away.
<nigel> Nigel: Seems like a good place to draw today's conversation to a close.
<nigel> SUMMARY: Keep working towards answers to the questions!
palemieux commented 4 years ago

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:

skynavga commented 4 years ago

@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

skynavga commented 4 years ago

@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

palemieux commented 4 years ago

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.