Remove applicability of tts:direction on

palemieux commented 3 years ago

Closes #1211 Closes #1213 Closes #1212

The paragraph embedding level is determined by the ipd, instead of being determined by tts:direction as applied to p. This is compatible with CSS since, in CSS, direction sets the paragraph embedding level and the combination of direction and writing-mode maps to tts:writingMode.

The effect of tts:unicodeBidi on p is clarified to match CSS.

palemieux commented 3 years ago

At the moment, it looks to me, unless I've misunderstood, that the PR does not match the requested changes from the issues it is intended to close. I look forward to discussing.

Yes, the PR attempts to find a middle ground to address the concerns with changing the semantics of tts:direction on p to influence the IPD.

css-meeting-bot commented 3 years ago

The Timed Text Working Group just discussed Remove applicability of tts:direction on w3c/ttml2#1214, and agreed to the following:

SUMMARY: Continue reviewing

The full IRC log of that discussion

<nigel> Topic: Remove applicability of tts:direction on w3c/ttml2#1214
<nigel> github: https://github.com/w3c/ttml2/pull/1214
<nigel> Pierre: My summary: long discussion on #1211. Boils down to what does tts:direction
<nigel> .. actually do when applied to p. 4 options available:
<nigel> .. 1. Keep things exactly as is by having tts:direction on p have no effect on the inline progression direction.
<nigel> .. This is probably what TTML and XSL-FO have in mind but is incompatible with CSS3.
<nigel> .. 2. Make things consistent with current CSS by having tts:direction on p override the inline
<nigel> .. progression direction set by the writing mode.
<nigel> .. This is inconsistent with existing TTML and XSL-FO.
<nigel> .. 3. Make tts:direction not applicable to p and instead set the paragraph embedding levels differently.
<nigel> .. 4. Keep things as is but note that the result of applying tts:direction on p is implementation-dependent.
<nigel> .. The PR I propose is a compromise, option 3 here.
<nigel> .. It makes tts:direction not applicable on p, removes the opportunity for inconsistency.
<nigel> .. Instead the paragraph embedded level is set from the computed value of the
<nigel> .. writingMode on region, so it is always set to the inline progression direction as determined on region.
<nigel> .. It's consistent with the spirit of TTML, and compatible with modern CSS, and if we ever
<nigel> .. change our mind we can make tts:direction applicable again and maybe then it will be
<nigel> .. more obvious what to do.
<nigel> .. As an aside, we have to decide what to do with unicodeBidi on p, which should be easier
<nigel> .. to deal with.
<atai> q+
<nigel> ack at
<nigel> Andreas: I have minor comments on the pull request but in general I fully agree with the
<nigel> .. intent, for the reasons Pierre mentioned.
<nigel> q+
<nigel> ack nige
<nigel> Nigel: What's the impact in terms of potentially breaking existing documents?
<nigel> Pierre: It's really hard to tell. I've not seen many if any right to left IMSC documents in the wild.
<atai> q+
<nigel> .. The few I have seen I think just set the writingMode and that's it, without any direction.
<nigel> .. I don't know, in terms of hard numbers.
<nigel> .. If we're going to settle on something now is a good time.
<nigel> Nigel: Not quite what I meant - rather, if there were a document with direction on p, and
<nigel> .. we made this change, what would be the impact?
<nigel> Pierre: If the author set direction to explicitly set the paragraph embedding level explicitly,
<nigel> .. presumably that would be consistent with the writingMode, because it would be unusual
<nigel> .. to set the two unequal, so there would be no change.
<nigel> .. If an author had used tts:direction on p to override the inline progression direction set
<nigel> .. by writingMode that would break those documents. Why would someone do that? Maybe
<nigel> .. because they think they're in CSS? This approach would break those documents, possibly.
<nigel> ack a
<nigel> Andreas: If you specify tts:direction on p or reference a style through some inheritance then
<nigel> .. it is actually specified for p. It is not an error - you can do it even if there is no effect.
<nigel> .. The question about the change breaking, my interpretation is that you would set direction
<nigel> .. on p and there is a deterministic behaviour expected for the rendering. From the long
<nigel> .. long thread we had on that, where all the experts were discussing and could not really
<nigel> .. get a grip on it and agree, it seems to be agreed that there's no deterministic behaviour
<nigel> .. so therefore it doesn't break anything. On the contrary, if you do that, it might not even
<nigel> .. break an existing application. I would argue that if an application would render it the
<nigel> .. way CSS3 does it, it would maybe be okay, but at least not an error.
<nigel> .. If you now fix and make normative a deterministic behaviour then it is very clear that
<nigel> .. some implementation is no longer conformant.
<nigel> Nigel: Thanks, that's a good point, definitely food for thought.
<nigel> .. I think what you're saying is that this change removes from reachability some features
<nigel> .. of CSS, in that you couldn't get a mapping from a TTML2 document by a processor
<cyril> q+
<nigel> .. conformant to this PR, which would end up setting the direction property on a p element.
<nigel> .. If you're mapping from TTML to HTML + CSS, say.
<nigel> .. Is that fair?
<nigel> Pierre: exactly. The only place where you would set the direction property would be the
<nigel> .. equivalent of the region TTML element, which is fine because that's where the inline
<nigel> .. progression direction is set.
<nigel> ack cy
<nigel> Cyril: When Pierre said he hadn't seen Arabic documents in the wild I was wondering what
<nigel> .. we do at Netflix. We have 100,000s Arabic documents. I picked one completely at random
<nigel> .. and it uses direction on p.
<nigel> .. I will paste the example.
<nigel> .. The document I have has no writingMode on the region at all.
<cyril> اجعل نوم أخيك...
<nigel> Andreas: The direction is on span not p
<nigel> Cyril: Sorry, I need to wake up!
<nigel> Andreas: Exactly how it should be used.
<nigel> Cyril: I will try to see if we ever use direction on a p
<nigel> Pierre: In general that's the question.
<nigel> Nigel: It seems like Netflix is the best placed to give us real world data.
<atai> q+
<nigel> Cyril: I'm looking. I think the difficulty is checking various vendors. I suspect that if all
<nigel> .. vendors use the same tool, given there's a restricted set of production tools, once we have
<nigel> .. looked at the output of all those tools, if none of them use direction on p then we're
<nigel> .. probably in good shape.
<cyril> مسلسلات NETFLIX الأصلية
<nigel> Pierre: If they use it on a p and it is consistent with writingMode then it's not terrible.
<nigel> Cyril: Another example above, again nothing on the p or region
<nigel> .. I will run some queries before expressing an opinion on the change.
<nigel> ack at
<nigel> Andreas: It's also important to see what would happen if you removed it if you do find it.
<nigel> .. It should be an interoperable behaviour, and at least it should be tested.
<nigel> Pierre: I will work on implementing Andreas's suggestions - they don't change really the
<nigel> .. fundamental proposal.
<atai> q+
<nigel> .. I do want to understand why the group concluded that unicodeBidi is not applicable on p
<nigel> .. when CSS does say some values are applicable to p. I'm happy either way. It would be
<nigel> .. good to get confirmation there.
<nigel> ack at
<nigel> Andreas: I've seen in your comments you asked for a reference. I couldn't find the discussion
<nigel> .. part but in one of Glenn's latest comment he said he considered removing the application
<nigel> .. of unicodeBidi from p in a later version and that's my recollection from the discussion as
<nigel> .. well, and there's issue #1212 that says to do this.
<nigel> Pierre: If you go to the latest CSS drafts, some values of unicode-bidi that do have an impact
<nigel> .. on p, including embed. We should point to some discussion or assessment in the PR I think.
<nigel> Andreas: There is a part of the minutes where Elika explained what they do if it is applied to p.
<nigel> Pierre: yes, it's in the CSS spec. I think that's less urgent.
<nigel> .. My goal is to close this by end of year.
<nigel> Nigel: Good discussion on this given the PR is only 11 hours old so already a massive step
<nigel> .. forward, let's keep reviewing.
<nigel> SUMMARY: Continue reviewing

cconcolato commented 3 years ago

Following our discussion I found one example in our catalog that uses dir on p:

<p begin="10844167t" end="29195834t" region="bottom" tts:direction="rtl" tts:unicodeBidi="embed" xml:id="ID_57d7c57f-ef91-42fd-8f32-0d1f237b5131">
  <span style="span">- תוכן מקורי של NETFLIX -</span>
</p>

the region is defined as

<region tts:backgroundColor="transparent" tts:displayAlign="after" tts:extent="80.000% 80.000%" tts:origin="10.000% 10.000%" tts:textAlign="center" xml:id="bottom"/>

writing-mode is not used at all in the document

palemieux commented 3 years ago

@cconcolato What is the expected rendering?

skynavga commented 3 years ago

Re: https://github.com/w3c/ttml2/pull/1214#issue-519627186, please note that the abbreviation ipd does not mean inline progression direction in TTML, it means inline progression dimension; therefore, to avoid confusion, it is best to spell out inline progression direction.

skynavga commented 3 years ago

@cconcolato Re: https://github.com/w3c/ttml2/pull/1214#issuecomment-726243664, I would expect the rendering to be such that the region is left-right, top-to-bottom, containing a horizontally center aligned paragraph that has its content effectively wrapped in a RLE/PDF Unicode Bidirectional Controls pair, which content consists of the text

- תוכן מקורי של NETFLIX -

The Bidi reordered text should appear as follows, and translates as "Original Content of NETFLIX".

- NETFLIX תוכן מקורי של -

css-meeting-bot commented 3 years ago

The Timed Text Working Group just discussed remove applicability of direction on p, and agreed to the following:

SUMMARY: Pull Request is closed without merging due to lack of consensus

The full IRC log of that discussion

<cyril> Topic: remove applicability of direction on p
<cyril> github: https://github.com/w3c/ttml2/pull/1214
<cyril> nigel: we have comments from Glenn
<cyril> ... Pierre tried to address Andreas' comments
<cyril> ... Andreas approved them
<cyril> ... Glenn says there is some semantic inconsistency
<cyril> ... we need to workout what that means
<cyril> pal: the computed value of tts:direction on a region can come from 2 different places
<cyril> ... implicitly from tts:writingmode or explicitely if you specify it or initial value
<cyril> ... I don't see why Glenn is unhappy
<cyril> nigel: it's not obvious is it?
<cyril> nigel: we need to ask glenn
<glenn_> mainly, i
<glenn_> mainly, i'm not happy with using a dull axe to cut out tts:direction semantics
<cyril> q+
<glenn_> we went to a lot of trouble to define out tts:writingMode maps to tts:direction which maps to paragraph embedding level in UAX#9; there is no need to remove those semantics
<nigel> scribe: nigel
<nigel> cyril: Since last time I did some research in our catalogue.
<nigel> .. I found 2 things.
<nigel> .. 1. I found more example of tts:direction being used on p, and not only from internal Netflix tools
<nigel> .. but at least 2 external vendors who produce such content.
<nigel> .. The content I found has tts:direction on p, no writingMode on region, but textAlign on p, most usually "center".
<nigel> .. I need to search for other cases where textAlign is not used.
<nigel> .. I am really worried that if we make this change to indicate that direction does not apply on p, there could be an impact on these
<nigel> .. Netflix external vendors.
<atai> q+
<nigel> s/The content/2. The content
<cyril> ack cyril
<cyril> scribe: cyril
<glenn_> I am also unhappy with (read cannot and will not accept) deprecating.
<cyril> atai: coming back to the rendering question
<cyril> ... what are the expectation of vendors when putting this value on p
<cyril> ... what interpretation is done by the renderers
<cyril> ... what should be the rendering
<glenn> thinks nobody is reading IRC except me
<cyril> ... I struggle to see how the situation could be worse if we remove applicability on p
<nigel> q+
<nigel> ack at
<glenn> cannot accept deprecation approach
<cyril> ... because it seems implementation dependent
<nigel> q?
<nigel> ack n
<cyril> nigel: there is a missing data
<cyril> ... for the content that Cyril has found, that sets direction
<cyril> ... presumably it is setting direction to rtl
<glenn> what is the missing data?
<glenn> you do realize that the bidi algorithm uses the character directionality?
<cyril> ... is there a common expecting rendering behavior that you would be expected and that would change if direction applicability is removed
<glenn> ah, someone is reading....
<glenn> sorry, i'm not on audio
<cyril> nigel: specifically, around what is implemented now vs any hypothetical implementation
<cyril> pal: a very general observation is that implementations prior to 2017 or 2018 of TTML, perhaps with the exception of ttv and ttpe, were terrible
<cyril> ... In my experience, produced documents that today would be deemed not conformant
<cyril> cyril: Netflix has received plenty of documents prior to 2017 that were fine
<glenn> @pal have you used all implementations? i haven't
<nigel> q+
<cyril> pal: but what does direction mean then in these documents
<cyril> cyril: maybe that its equivalent to writing mode
<nigel> q?
<cyril> nigel: there is a stated meaning of direction p
<cyril> ... I don't think anybody doubts that it sets the paragraph embedding level
<cyril> ... if the result of this change meant that it no longer did that, then a bunch of text already out there, if you rendered it with a now conformant implementation, would render in the incorrect order
<cyril> ... that wouldn't be right
<nigel> ack n
<atai> q+
<cyril> pal: that's not accurate
<nigel> q+ pal
<nigel> ack at
<cyril> atai: going back to what Cyril said, that it was clear what directionality on p, I can guess that they wanted to indicate that the content in the p had the direction indicate in the tts:direction attribute
<cyril> ... especially to override the left to right direction because they did not specify writing mode
<cyril> ... if we follow the text in TTML2 as of now, i.e. setting the embedding level, this has an effect on arabic and hebrew
<cyril> ... because the neutral and weak characters would use it
<cyril> ... the issue we are facing is how it is defined in TTML is that it separates the directionality from the inline progression direction
<cyril> ... CSS3 does both at the same time while TTML2 does not
<glenn_> q+
<cyril> ... the problem is that most authors would expect that it behaves like CSS
<cyril> ... either way there will be problems
<nigel> q+ to say that #1213 is the issue that implements Andreas's point
<nigel> ack pal
<cyril> ... and not the expected rendering from the authors
<cyril> pal: as an example where this is not clear is the case where you have arabic (rtl) but writing mode is set (ltr) and textAlign is set to center
<atai> q+
<cyril> ... in that particular tts:direction will have no impact
<cyril> ... if it's pure arabic with no latin
<cyril> ... so that's the case where somebody might set tts:direction thinking it would do something but it does nothing
<glenn_> not true
<nigel> ack glenn_
<cyril> ... because some think it may set the alignment but they use text align
<nigel> nigel: Glenn please go ahead via IRC
<glenn_> I would like to point out (yet agaiin)
<glenn_> that tts:direction is used in two context with respect to tt:p
<glenn_> and one context with respect to tt:span
<nigel> q?
<glenn_> it is used with tts:unicodeBidi as a parameter
<cyril> nigel: I think that's well understood in the conversation
<glenn_> i don't think so
<glenn_> with tt:p it has two uses
<glenn_> we need to know which context applies
<glenn_> if we are talking about the use where it appears by itself
<glenn_> then tts:direction only means set the default paragraph embedding level
<glenn_> and that does have an impact
<glenn_> it means something and has a visual interpretation w.r.t. neutral characters
<glenn_> so I don't know why pal is saying it has no impact
<cyril> nigel: in Netflix cases, is tts:direction applying with unicodeBidi?
<cyril> cyril: no
<glenn_> it has nothing to do with textAlign
<cyril> cyril: there is no unicodeBidi in my example
<nigel> q?
<nigel> ack nigel
<Zakim> nigel, you wanted to say that #1213 is the issue that implements Andreas's point
<glenn_> I don't have the example in front of me
<glenn_> I think the examplle I looked at DID have unicodeBidi
<cyril> nigel: I wanted to make a point that the main things was that Andreas made a good point about the direction and CSS compatibility
<cyril> ... and that's precisely issue #1213 and that is not implemented
<glenn_> it had tts:unicodeBidi="embed"
<cyril> ... sorry, this is confusing
<cyril> ... in this PR, I don't think it does that
<cyril> pal: the PR is compatible with CSS
<cyril> ... because the PR proposes that the paragraph embedding level be set by the inline progression direction computed on the region
<cyril> ... which in CSS would be set by direction
<nigel> q?
<cyril> nigel: I will close the queue on this to move on in the agenda
<nigel> ack atai
<cyril> atai: I agree with Pierre that the PR solves the conflict with CSS because it avoids the situation where TTML acts differently from CSS
<cyril> ... but I also need to agree with Glenn that setting tts:direction to RTL and have centered arabic text as content in that p, will render different from the case where you have not set tts:direction on the p
<glenn_> that is precisely the semantic inconsistency I point out in my comments
<glenn_> tts:writingMode does not apply to tt:p
<cyril> ... there have been some examples in the long long thread
<cyril> ... where I mixed some latin text with weak characters and numbers, and this will be rendered differently
<cyril> ... I'm not sure if we discussed the option that some parts of the rendering could be implementation dependent
<cyril> ... I think that reflects the reality at the moment
<cyril> ... at least regarding the setting the edges
<glenn_> tts:writingMode applys to tt:region which has special semantics that flow to tts:direction which inherit down to tt:p which apply to paragraph embedding level WHICH NEEDS TO STAY AS DEFINED
<cyril> ... saying that it's not clear in the spec and implementation dependent
<cyril> pal: I will withdraw my PR
<glenn_> I support withdrawal of the PR, thank you pal
<cyril> SUMMARY: Pull Request is closed without merging due to lack of consensus

w3c / ttml2

Remove applicability of tts:direction on <p> #1214