{Minutes} TTWG Meeting 2020-08-20

Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2020/08/20-tt-minutes.html


In text format:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

20 August 2020

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2020/08/06-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/136

      [4] https://www.w3.org/2020/08/20-tt-irc


Attendees

   Present
          Andreas, Atsushi, Cyril, Gary, Hew, Mike, Nigel, Pierre

   Regrets
          -

   Chair
          Gary, Nigel

   Scribe
          cyril, nigel

Contents

    1. [5]This meeting
    2. [6]Interaction between tts:writingMode and tts:direction on
       paragraph element. w3c/ttml2#1211
    3. [7]New member
    4. [8]TTML 1 in-place edits

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: [9]https://github.com/w3c/ttml2/issues/1211


      [9] 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> [10]CSS dependency that defines inline-start and
   inline-end

     [10] https://www.w3.org/TR/2018/CR-css-writing-modes-3-20180524/#logical-to-physical


   Pierre: because p is a block it also sets writing mode

   <nigel> [11]TTML2 reference that maps inline-start and
   inline-end to start and end

     [11] https://www.w3.org/TR/2018/REC-ttml2-20181108/#derivation-padding


   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: [12]https://
   ttml-w3c.himor.in/TTML1-3rd-edit-20200820.html

     [12] 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> [13]Adopt /history in place of Previous Version for all
   future publications

     [13] https://github.com/w3c/ttwg/issues/145


   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]


    Minutes manually created (not a transcript), formatted by
    [14]scribe.perl version 122 (Tue Aug 11 13:09:49 2020 UTC).

     [14] https://w3c.github.io/scribe2/scribedoc.html