Meeting minutes
this meeting
nigel: we have regrets from Glenn
… the first topic is what his regrets apply to
… but we can use the opportunity to get the discussion going
pal: yes
<atsushi> (will come shortly. still in previous)
nigel: since sending the agenda on tuesday I modified the order to put the registry next
… we just published
… I still haven't got the MPEG liaison
<glenn> I'm here, IRC only.
cyril: I'll send you the liaison again
nigel: not sure if we need more on Process 2020
… the conclusion last time was that gary would send something around
gkatsev: the patent 2020 there is a time limit if we want to do the quick adoption of that
nigel: and the last topic is changing the default branch name
… from master to main
nigel: any other business for the agenda
nigel: seems not
remove applicability of direction on p
github: https://
nigel: we have comments from Glenn
… Pierre tried to address Andreas' comments
… Andreas approved them
… Glenn says there is some semantic inconsistency
… we need to workout what that means
pal: the computed value of tts:direction on a region can come from 2 different places
… implicitly from tts:writingmode or explicitely if you specify it or initial value
… I don't see why Glenn is unhappy
nigel: it's not obvious is it?
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
<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
cyril: Since last time I did some research in our catalogue.
… I found 2 things.
… 1. I found more example of tts:direction being used on p, and not only from internal Netflix tools
… but at least 2 external vendors who produce such content.
… 2. The content I found has tts:direction on p, no writingMode on region, but textAlign on p, most usually "center".
… I need to search for other cases where textAlign is not used.
… 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
… Netflix external vendors.
<glenn_> I am also unhappy with (read cannot and will not accept) deprecating.
atai: coming back to the rendering question
… what are the expectation of vendors when putting this value on p
… what interpretation is done by the renderers
… what should be the rendering
<glenn> thinks nobody is reading IRC except me
atai: I struggle to see how the situation could be worse if we remove applicability on p
<glenn> cannot accept deprecation approach
atai: because it seems implementation dependent
nigel: there is a missing data
… for the content that Cyril has found, that sets direction
… 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?
nigel: 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
nigel: specifically, around what is implemented now vs any hypothetical implementation
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
… In my experience, produced documents that today would be deemed not conformant
cyril: Netflix has received plenty of documents prior to 2017 that were fine
<glenn> @pal have you used all implementations? i haven't
pal: but what does direction mean then in these documents
cyril: maybe that its equivalent to writing mode
nigel: there is a stated meaning of direction p
… I don't think anybody doubts that it sets the paragraph embedding level
… 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
… that wouldn't be right
pal: that's not accurate
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
… especially to override the left to right direction because they did not specify writing mode
… if we follow the text in TTML2 as of now, i.e. setting the embedding level, this has an effect on arabic and hebrew
… because the neutral and weak characters would use it
… the issue we are facing is how it is defined in TTML is that it separates the directionality from the inline progression direction
… CSS3 does both at the same time while TTML2 does not
… the problem is that most authors would expect that it behaves like CSS
… either way there will be problems
… and not the expected rendering from the authors
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
… in that particular tts:direction will have no impact
… if it's pure arabic with no latin
… so that's the case where somebody might set tts:direction thinking it would do something but it does nothing
<glenn_> not true
pal: 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
<glenn_> it is used with tts:unicodeBidi as a parameter
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
nigel: in Netflix cases, is tts:direction applying with unicodeBidi?
cyril: no
<glenn_> it has nothing to do with textAlign
cyril: there is no unicodeBidi in my example
<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
nigel: I wanted to note that Andreas made a good pointå about the direction and CSS compatibility
… and that's precisely issue #1213 and that is not implemented in this PR
<glenn_> it had tts:unicodeBidi="embed"
nigel: sorry, this is confusing
… in this PR, I don't think it does that
pal: the PR is compatible with CSS
… because the PR proposes that the paragraph embedding level be set by the inline progression direction computed on the region
… which in CSS would be set by direction
nigel: I will close the queue on this to move on in the agenda
atai: I agree with Pierre that the PR solves the conflict with CSS because it avoids the situation where TTML acts differently from CSS
… 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
atai: there have been some examples in the long long thread
… where I mixed some latin text with weak characters and numbers, and this will be rendered differently
… I'm not sure if we discussed the option that some parts of the rendering could be implementation dependent
… I think that reflects the reality at the moment
… 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
atai: saying that it's not clear in the spec and implementation dependent
pal: I will withdraw my PR
<glenn_> I support withdrawal of the PR, thank you pal
SUMMARY: Pull Request is closed without merging due to lack of consensus
TTML Profile Registry
nigel: we published a new version, thank you very much Atsushi
… it's a WG note, we can publish whenever we like
… Cyril has made a request by email
… to add in a new IMSC1.1 based profile
… Mike expressed support for this already, which is helpful
… there is no general reason why we would not accept it
… the proposal I suppose is to use identifier nst1
… not used at the moment
PROPOSAL: add the Netflix profile to the TTML Profile Registry as requested using identifer nst1
nigel: any objections?
mike: no objection, I consider approved and closed, but I have a question
… the process says to put it in the agenda and discuss
… would we ever decline if the 5 items requested are provided?
nigel: maybe there would be ways to misuse the process
… the fact that it's a formality is not a concern for me
mike: I thought it was administrative
Resolution: add the Netflix profile to the TTML Profile Registry as requested using identifier nst1
nigel: Cyril can you raise an issue?
cyril: yes
Patent Policy 2020
gkatsev: I doubt that we really care that much
… but it sounds like if we wanted to apply the PP2020 we have through nov 27th to say so and the charter would be updated just for that
… so we could use the new PP immediately
… otherwise we will have to wait for the next re-charter, december next year
nigel: I haven't kept track of the differences
gkatsev: the continuous CR living standard would require that
nigel: and we have no plan to use that mechanism
gkatsev: not right now
… but I figure it's worth mentioning it now
cyril: what's the harm in adding it now even if we don't use it?
gkatsev: probably nothing
nigel: anybody would have concerns about adopting it?
<atsushi> could be helpful: https://
nigel: I would advocate for using it
… and for a reduced review period if there is this deadline of Nov. 27th period
… Atsushi, can I ask you to extend the deadline to accomodate our decision review period
… which would bring us to Dec. 3rd
… I don't want to reduce the review period, because people may have to go back to lawyers
atsushi: this seems to be a strict deadline
… we can ask rechartering at any time
nigel: I did not understand the deadline, causing AC review if we are too slow
… I will ask plh directly if you want
atsushi: the purpose is to make it easy to review multiple charters at the same time
PROPOSAL: adopt Patent Policy 2020
nigel: are there any objections now
cyril: I don't know
… I think it's ok but I will consult
Resolution: adopt Patent Policy 2020
nigel: If you think you need a review, please do it now, don't wait for the 2 weeks
… it might be too late
Default branch name
Nigel: We don't have time to cover this now so I'll bump it up the agenda for next week.
Pierre: Would like a proposal from the Chairs and W3M. It's going to be work whatever we do.
Nigel: I think it is going to impact Editors primarily.
… In any case, let's come back to it.
Meeting close
Nigel: Thanks everyone, we're out of time for today. [adjourns meeting]
<atsushi> nigel: for branch name item, let me send some line of summary and proposal for changing procedure shortly (I hope shortly...)