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