Meeting minutes
This meeting
Nigel: the main thing on the agenda is about writing mode and direction
… not sure we have anything on TTML2 IR and TPAC Virtual Agenda
… but we probably should meet with the Privacy group
… in AOB I would like to mention a couple of things about in-place edit to TTML1 3rd edition
… Mike Dolan pointed out some issues
… and a proposal I made to link to the History of specs rather than previous versions
… anybody else?
… no
Interaction between tts:writingMode and tts:direction on paragraph element. w3c/ttml2#1211
<nigel> github: https://github.com/w3c/ttml2/issues/1211
Nigel: good discussion and lots of detailed technical inputs
… thanks Pierre for raising this issue
… I asked yesterday do we have consensus?
… Pierre said it wasn't clear
… the difference between specifying direction/unicodeBidi on a p vs on a span
… Glenn put some equivalences in
… do we think we got to some kind of understanding
Andreas: while working through it, I noticed that it is complex, too many specs
… my proposal would be to go systematically through the issue
… and see if we have a common understanding
… for example going with direction on region and p
… and see if the specification text is clear to represent our understanding
Nigel: you created 3 cases
… and generated reviews for them
… in the end from doing that, do you think we did get to something that made sense to you?
… I did not detect any disagreement
… but I want to check
Andreas: I want to be really sure about it
… for region, what I got from the discussion
… is that inline progression direction influences start/left...
… using writing mode
… there are 2 kinds of inline progression direction
… one to set the edges that influences alignment
… and then the inline progression direction that is used to apply the unicode bidi algo
… and these 2 are separate
… tts:direction never influences the inline progression direction of writing mode
Cyril: I agree with you Andreas that there are two concepts.
… Not sure they're called Inline progression direction in both cases.
Andreas: From the spec it's not clear.
… Glenn commented that there are separate directions, for writing mode and direction.
Cyril: Also what makes the discussion difficult is that we refer a lot fo XSL-FO,
… and I'm not sure that our spec contains enough information to understand writingMode,
… direction and textAlign without going deep into XSL-FO.
Andreas: Yes, I tried to look through the different references and it's really difficult because
… direction came from CSS 2 to XSL-FO and both use the Unicode bidi algorithm,
… and then we have the new setting how CSS is handling writing mode and direction.
… We should first check our common understanding and then check back to the references.
… I agree with you Cyril that there is not enough text in TTML2 to understand the concepts
… and how they apply.
Andreas: if tts:direction is set on the region
… my understanding is that the only effect is that it is inherited to the p
Cyril: me too
Andreas: it was surprising that tts:unicodeBidi is not inheritable
… so only tts:direction makes sense on region
… so it inherits to the p and there set the paragraph embedding level
… on the p if only unicodeBidiis specified, then it would be combined
Pierre: I agree on the inheritance business
… Glenn's latest explanation on tts:direction is the cleanest I've seen
… it's the combination of tts:direction and unicodeBidi that inserts control characters
… and this explains everything
… tts:direction would have no effect on writing mode
… I'd like to see if this explanation is accurate
… I see no reason why tts:direction and unicodeBidi should apply to p
… because it insert control characters
… and that is clearly an inline matter that belongs to span
Cyril: maybe because of anonymous spans
Nigel: [reads the spec]
… 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.
Pierre: I wanted to understand what it meant
… Glenn's latest answer seems to indicate that applying on p or applying on the single child span has the same effect
Andreas: what's missing from Glenn's example is what happens if you set direction without setting unicodeBidi
… if you set tts:direction on a p, it sets the paragraph embedding level, regardless of the value of unicodeBidi
… that's a different concept from inserting control characters
… at least that's what I understand
Pierre: then I still don't understand
… what happens when you set tts:direction and unicodeBidi on p
… I read the words but ...
<Zakim> nigel, you wanted to check if there is enough text in TTML2 to define (rather than explain) the concepts
Nigel: 1) I wanted to ask if there is enough text in TTML2 to define the concepts
… 2) one of the things that get affected by writing mode is textAlign (start and end)
… and looking at the text of textAlign it does not define what start and end mean
… there is a semantic derivation
… which talks about start and end
… we seem to be in a knot of complicated spec
… it does not seem to make any sense to have textAlign based on the span, maybe on the p and the region
Pierre: I had concluded that tts:direction and unicodeBidi did nothing to inline progression direction but now I'm confused
… 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> CSS dependency that defines inline-start and inline-end
Pierre: because p is a block it also sets writing mode
<nigel> TTML2 reference that maps inline-start and inline-end to start and end
Pierre: 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
… but on p, setting tts:direction on p, also sets the inline progression direction
Andreas: it's not possible to compare CSS in its current form to TTML, because it derives from XSL:FO
… and XSL:FO derives from CSS 2 which was changed later
… in general with the formatting character, it is explained in the unicode bidi algo and in XSL:FO
… in the end all markup is converted into characters
… but before there are steps in setting fo bidi override elements to refine the formatting
… in general what TTML2 is defining is not broken
… but not specified clearly
… especially how unicode bidi applies to p
… it's consistent if it works as Glenn explained
Pierre: you said 'especially how unicode bidi applies on p', Glenn's response is simple
… it behaves the same as it behaves on span
Cyril: Reading the spec (again!), the part that talks about the combination with unicodeBidi
… is prefixed by "when applied to a span", there's nothing about a p element there.
… In TTML2 §10.2.12 after the table.
<atai> +1
<Zakim> nigel, you wanted to mention the CSS abstract - physical mapping
Nigel: sometimes you need to know the start and end actual edges depending on writing mode and direction
… padding is one of the cases where you need that
… textAlign too
… CSS mapping does that
… and TTML lists the mapping from start and end to CSS terms
… and this explains why you might want to set direction on a p
Pierre: long time ago, that was my understanding
… tts:direction on a p, changes the ipd like CSS
… but those 2 sentences in 10.2.12 were inserted to explicitly differ from CSS
Nigel: not sure there is a semantic difference between inline progression direction and the decoding of start and end
… they might be different things conceptually
Andreas: setting the edges and for the bidi algo, they are 2 different concepts
Andreas: What's missing from the spec for how tts:direction applies to p and span, for p it
… just says sets the para embedding level.
… for span it says how it translates in combination with unicodeBidi.
… But it doesn't say the same for p, so there's definitely some missing text here I think.
… I only come to the conclusion that this must be the case because unicodeBidi applies
… to p, from the formal description of the attribute, so it must have the meaning as
… Glenn explained in his latest comment, but it needs to be reflected in the spec.
… What you said Nigel, is the big problem, we mix CSS and XSL-FO and it can be hard
… to separate them. We need to take just XSL-FO as the reference. It may be different
… from CSS in its current form.
… XSL-FO takes from CSS2 but that may be different from current CSS.
… I think it makes sense what Glenn says, because in TTML the region is the only
… element that can map to an XSL-FO element that establishes a reference area.
… a fo:block container. This is the only element mapped from TTML that can establish the
… edges, so a block as I understand it, does not have this. A p is mapped to a fo:block.
… This may be different from CSS but in the logical mapping from TTML to XSL-FO,
… it makes absolutely sense.
Nigel: if you set padding or text align on a p and need to compute what start and end edges are
… Andreas is saying that the edges can only be defined by the region and never defined by the p itself
Andreas: yes
Nigel: I think that is different from what our spec says in the derivation for padding
Pierre: if that is the case, then what does establishing the paragraph level embedding means
Cyril: 3 questions we have:
… 1. Compute start and end edges - does tts:direction on p affect it, yes/no?
… 2. What is unicodeBidi doing on p given it is applicable but the text for tts:direction
… mentions unicodeBidi combination only for the span?
… 3. The one Pierre mentioned. What does "establishing the paragraph embedding" level mean?
… 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?
Cyril: This is a good spot to stop!
Nigel: I was thinking the same thing!
SUMMARY: Conversation resulted in 4 key questions - see IRC log above.
New member
Nigel: Hew joined us in the midst of a complex technical question
… it'd be very good to introduce who we are
[introductions]
TTML 1 in-place edits
Nigel: Mike pointed a couple of issues
… in the introductory material, the very top, there is a link to latest recommendation
… and that points to the previous recommendation not the next
… and his name is not the same in all the place
<atsushi> (that's definetry my job...)
Nigel: Mike you are going to be Michael Dolan in all the places you're listed
… in the process of doing this
<atsushi> latest draft for update: https://ttml-w3c.himor.in/TTML1-3rd-edit-20200820.html
Mike: if you're going to TTML 1 it is not obvious to find TTML1 2nd ed
Nigel: I raised an issue in the TTWG Github space
… in place of previous version links
… we use a history link
… this is a new link that is very useful
… and does not change from version to version
<nigel> Adopt /history in place of Previous Version for all future publications
Nigel: if you think there is any issue with that, let us know
Mike: I came about this because IMSC1.0.1 cites the 2nd edition
… but the link in 1.0.1 is a generic link that goes to the 3rd edition
Nigel: we are over time
… let's adjourn [adjourns meeting]