{Minutes} TTWG Meeting 2020-03-18

Thanks all for attending today's TTWG meeting. I understand that there was some confusion about the time, for which apologies. I thought I'd updated all the information but forgot the .ics files.

Minutes can be found in HTML format at https://www.w3.org/2021/03/18-tt-minutes.html

In text format:

​   [1]W3C

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

                Timed Text Working Group Teleconference

18 March 2021

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

      [2] https://www.w3.org/2021/03/04-tt-minutes.html

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

      [4] https://www.w3.org/2021/03/18-tt-irc


          Cyril, Glenn, Nigel, Pierre

          Atsushi, Gary




    1. [5]This meeting
    2. [6]Publication of updated CR
    3. [7]Unresolved horizontal review issues
    4. [8]Shear calculations and origin of coordinate system.
    5. [9]Meeting close

Meeting minutes

  This meeting

   Nigel: Today's a TTML2 focused call.
   … For the agenda I have CR2 publication, and unresolved HR
   … Is there any other business?

   group: [no other business]

   Cyril: If we have time to talk about shear calculation?

   Nigel: We can add that to the agenda

  Publication of updated CR

   Nigel: Good news - we got there with CR2, at [10]https://
   … I noticed too late that we forgot to put a history link in at
   the top.
   … That can go in later, at PR or a CRD if we do one.

     [10] https://www.w3.org/TR/2021/CR-ttml2-20210309/

  Unresolved horizontal review issues

   Nigel: Ralph, in reviewing the CR transition request, noted
   that there are open HR issues.

   Glenn: I closed one of the HR issues after publication had
   occurred, which was just some clean up work I was doing
   … to create the release entries in GitHub, and clean up any of
   the milestones for TTML2 CR2.
   … I noticed that there was one review issue that was still
   logged against that milestone,
   … that seemed to be covered by material we added under the
   privacy section on fonts,
   … and I see that Nigel reached out to the original commenters
   to see if they want to add anything further.
   … Are there others?
   … There may be some that were not associated with that

   Nigel: Yes there are. I added them to the agenda.
   … #1211 was split into #1212 and #1213, about writingMode,
   direction and unicodeBidi on the p element.
   … We tried to resolve that before, and it didn't go well.
   … But it remains open.
   … The other one just to complete the list is #1201 which is
   above security and privacy risks of insecure transport / mixed
   … I have a feeling that is only editorial and is asking to
   replace any http:// URLs in examples with https:// ones.
   … I think we may have a hard time going to PR if we haven't at
   least tried to address these in some way.

   Glenn: On the first, #1211, it will depend on whether the
   proposed resolution entails a substantive change or not,
   … as to whether it applies in 2nd Ed. Particularly if there is
   a change that breaks backwards compatibility.
   … I still have some TBDs to progress some PRs on these after we
   finished our last round of in-depth discussion on these.
   … I guess the ball is in my court to get some PRs out on them.

   Nigel: That would be great if you could. Pierre tried before
   but we didn't have consensus to merge.

   Glenn: It could be that a substantive change needs to go to

   Nigel: Yes, if it's a breaking change, but I think where we go
   to is we didn't need that.

   Glenn: Okay, I will try to devote some time to opening PRs on
   this topic.

   Nigel: Thank you, I really appreciate that.
   … On #1201, the proposed resolutions are to note
   non-normatively the risks to confidentiality and integrity, and
   to change the scheme to https in the examples.
   … Those things both seem achievable.
   … Any volunteers to open a pull request to address that?

   Glenn: It would be an easy editorial change to use https in the
   examples throughout the spec.

   Nigel: I may try to pick up this as a PR, but not until the end
   of next week.
   … If anyone else can, that'd be great too.
   … To me, the non-normative note about risks is the appropriate
   fix here because we don't talk about transport protocols at

   Glenn: Yes, agreed.

   Nigel: The tool linked below is really helpful - when I
   reviewed, those issues are the only ones we have to deal with
   in TTML2 2nd Ed,
   … but if there are any listed as for a later version that we
   can solve that's okay too of course.

   [11]TTML horizontal review issues (all versions)

     [11] https://www.w3.org/PM/horizontal/review.html?shortname=ttml

  Shear calculations and origin of coordinate system. w3c/ttml2#1199

   github: [12]https://github.com/w3c/ttml2/issues/1199

     [12] https://github.com/w3c/ttml2/issues/1199

   Cyril: To explain what happened, on this issue I opened a year
   ago (and then forgot about):
   … We are now implementing support for TTML2 / IMSC 1.1 on
   Android came to me independently with the same questions.
   … One question: Is the behaviour of shear influenced by the
   inline progression direction or the block progression
   … You can ask the question in different ways. Another is: what
   is a +ve or -ve angle in different writing modes?
   … So 2 days ago I updated the issue with the same question in
   more details.
   … My conclusion is that we should clarify what is the intention
   of the shear.
   … It can be done visually with examples for different writing
   modes if that has an impact.
   … Or we could be more precise mathematically and provide the
   centre of the orientation and the angle.

   Nigel: Note Pierre's useful comment about CSS.

   Glenn: What CSS does is irrelevant in this case - it's a skew
   transformation, so forget about that.
   … I started looking at it and made some progress on drafting an
   answer to Cyril but I haven't finished it
   … because I wanted to study in detail more the various
   combinatorics involved.
   … To your question on block shear or paragraph level shear,
   i.e. tts:shear, at least the origin here was intended
   … to be the origin of the block areas generated by the
   … Normally the paragraph will generate one or more outer block
   areas with line area children.
   … In some implementations it might forgo the intermediate outer
   block area and just have line area block children.
   … In any case the overall intent, reflected in the sample image
   that is included in the definition of that property,
   … was that the origin of the generated block area be the origin
   of the shear transformation, not the centre.

   Cyril: Where would the origin be?
   … The top left, the top right corner?

   Glenn: In horizontal writing modes and it's left to right as
   the paragraph level bidi assignment then it would be the top
   … If it's horizontal writing mode with right to left as the
   paragraph level bidi (or an odd number by the bidi algo for the
   outer p embedding level)
   … then it would be the top right of the block area since you're
   filling from right to left. At least that was my intention.
   … Then for tblr it would be top left corner, and tbrl it would
   be top right corner.
   … Does that makes sense or not?

   Cyril: I just care about it being clear in the spec.

   Glenn: I understand that clarifying the spec is your main goal
   and I agree with that.
   … But we also probably ought to agree what the correct answer
   would be as well.
   … I'm open to other possible definitions than the one I just
   … That's the one I happen to have implemented. Others might
   feel like it's better to argue for a different definition.

   Cyril: Another clarifying q. For tbrl, you said the origin
   would be the top right corner?

   Glenn: Correct

   Cyril: And the spec says if the ipd corresponds to the y axis
   then the 2d shear matrix is [...]
   … What would be the x axis in this case, the ipd or as usual
   pointing to the right?

   Glenn: The answer I just gave would have it match the bpd, so
   if it is right to left then it would be the top right corner.

   Cyril: That makes sense because the +ve angle goes from the y
   axis to the x axis so it looks consistent to me.

   Glenn: That's how most implementations would tend to lay out
   block areas and I believe (haven't verified it) that if we were
   to go back
   … to look at the definitions of placement of block areas in
   XSL-FO that would correspond to its model of the origin of
   those block areas as well.

   Nigel: Glenn you dismissed CSS very quickly earlier, but it's
   surely an important data point.

   Glenn: Not really, in CSS there's a post-processing mapping
   from shear to skew, and the skew transformation could be used
   to implement it
   … but as we define the semantics.

   Pierre: I'm shocked by this; The spec says the semantic basis
   for tts:shear is CSS skew, so you can't say that wasn't

   Glenn: You have a good point. I don't have the text of the spec
   in front of me right now.

   Pierre: It's under semantic basis for shear derivation it
   points to skew-x and skew-y.

   Glenn: That's something Nigel did, I never looked at that.

   Pierre: That's what the spec says and what people implemented.

   Glenn: If we inadvertently wrote that then we need to clarify
   what the derivation means, it could mean "can be mapped to".

   Nigel: I don't believe credit or blame is due my way for the
   mapping from shear to skew. I rearranged the semantic
   derivation but I don't
   … recall inventing any mappings.

   Pierre: I think the spec is actually quite clear, whether it is
   right or not.
   … It says semantic derivation and points to skew-x and skew-y

   Cyril: I agree with Glenn here, the semantic derivation gives a
   link, but if you ignore it altogether you can't implement

   Pierre: Exactly

   Nigel: I think the question here is what should the spec say,
   and does it say it?

   Cyril: The key question is whether the shear direction depends
   on writing mode. At the moment the spec doesn't say that at
   … Since it was not clear, it is unlikely that the
   implementations are interoperable. We may want to make it match
   CSS or not.

   Glenn: I agree. I think I would try to oppose employing the CSS
   definition which would be the centre of the block area.
   … It is clear that one can map a semantic that is based on an
   origin that is not centre based to a semantic derivation of
   skew in CSS that
   … is based on centre. But I view that as part of the
   implementation process of mapping our semantics to CSS in this
   … In my mind, the question, and what I read between the lines
   is Pierre's suggestion to adopt the CSS semantic of a block
   centre skew transformation
   … then that would be problematic in my opinion.

   Pierre: I plan to object strongly to changing the origin to
   anything other than centre.

   Glenn: Until we define it, it is currently undefined.

   Pierre: I don't agree with that assessment and I think it is
   clear what it says in the spec today.

   Glenn: You think it is the centre of the block?

   Pierre: Yes absolutely. For the record, unless using centre for
   skew cannot be used in the context of timed text in general my
   … position is that it should be used in general.

   Cyril: If you look at the tts:shear example image, I don't know
   how the centre of the block could be the centre of the
   … in that example.
   … If you take the right side of the image and apply the
   transformation around the centre without doing any translation,
   then the right hand
   … kanji would be outside of the region.

   Pierre: It's not possible to tell where the origin was in that

   Cyril: I agree there's some ambiguity, but it's not clear.

   Pierre: That's why I go back to the semantic derivation.
   … My question is why is centre wrong? It seems to work. Unless
   there is an argument why it is not good then we should stick
   with it.

   Cyril: To get the example image you'd have to apply some
   translation (or padding)

   Pierre: You'd have to do that regardless to avoid overflowing
   (loosely) the region.

   Nigel: There are two questions: first is the origin of
   transformation, but the other is the direction of
   … Do we have any info from CSS on direction?

   Pierre: No, on that one, it is much more ambiguous.

   Glenn: Another issue: while it is feasible to define the shear
   in terms of centre for p or line shear, it cannot be used for
   font shear.
   … You're intent is going to break down at that point, to define
   a centre based shear model based on skew in CSS. The origin
   cannot be
   … the centre of the glyph. One could take the semantics we need
   to define, which is an origin based on its placement on the
   … and translate that to a centre based skew transformation by
   appropriate matrix multiplication, but it will make the
   explanation of it
   … more complicated if we define it in those terms and at that
   point we're instructing on how to implement based on CSS which
   we have
   … not tried to do in general.

   Pierre: Ideally here the solution is to get a discussion with
   CSS and find a common acceptable solution.

   Glenn: Unless we have nailed down our intended semantics and
   have a way of documenting that first it will muddy the waters
   … get involved with CSS. They're not defining shear semantics
   as far as we know. Are they?

   Nigel: I haven't checked JLReq and all the gap documents
   published by the internationalisation activity, but I would
   speculate that
   … this would be one of the gaps that would need solving across
   the web platform, so they likely do want to solve it.

   Cyril: I think we should identify what we want for how shear
   should work and then how to map it onto CSS.
   … One problem I see is we have one way to do block, font or
   line shear, but to map onto CSS you cannot use the same
   mechanism for each.
   … For fonts you have to use font-style: oblique; I'm not sure
   it behaves the same.

   Glenn: Does it take an angle?

   Cyril: Yes oblique takes an angle parameter

   Glenn: Ok I wasn't aware of that

   Cyril: That's implemented in Chrome and Firefox and is in CSS,
   not sure if it is level 3 or 4.

   Glenn: I think it's nice to have for people who are basing
   implementation on CSS, but it's not a necessary part of our
   semantics as
   … far as I'm concerned, in terms of defining our intentions.

   Pierre: My interest is in interoperability and compatibility
   with the web platform.

   Nigel: If we think about this from an authorial and user
   perspective, rather than a spec-partisan perspective, then we
   should surely come
   … to the same conclusion.

   Glenn: I agree, and did offer to consider other options.

   Cyril: In the comments on the issue, the image at the bottom
   shows a possibility for defining shear not in consistent
   mathematical terms,
   … depending on the writing mode, another approach is to say
   "here is what we want to achieve", which could be like italics,
   … positive shear behaves like italics in horizontal modes, and
   we can do what we want for vertical, then we can derive the
   … Can we agree, forgetting for the time being about tbrl, that
   the three images are what we want?
   … tbrl has positive shear pointing to bottom left.
   … lr has positive shear pointing to top right
   … rl has positive shear pointing to top left.
   … If we can agree on that then we can decide if we need
   translation or scaling or padding or whatever.

   Nigel: My assumption is that shear line layout occurs
   post-shear not pre-shear. Is that controversial?

   Glenn: I think that's an implementation issue. We should
   … The semantics of laying out the line areas in XSL-FO, close
   to CSS 2.1, is based on a non-shear model, so the packing or
   stacking of
   … blocks and inline areas with glyph areas assume a certain
   model but different implementations can take different
   … For example one implementation might compute and create state
   information for laying out the glyphs in a line area based on
   … alone possibly in association with baseline shifts.
   … But when they actually paint those glyphs they might paint
   them from one or the other direction by recalculating those
   … For example if you're painting a paragraph that's rtl you
   might output the glyphs in rtl display order which might match
   reading order
   … or you might output them in ltr order opposite to reading
   order. As long as the eventual position of the glyphs match up.
   … This has an impact on how things like PDF files store
   information for accessibility purposes, when those glyphs are
   recombined for
   … operations like find. It is implementation dependent.

   Cyril: Implementations can certainly do different things. The
   question is the interoperability. How do we achieve it?
   … We should specify something but the question Nigel raised is
   important because if you apply layout first and then shear you
   might have
   … overlap in terms of glyphs. So Nigel I think we should agree
   on the visual aspects of the transformation, how it should
   look, then agree
   … on the layout, how is it placed with respect to other text or
   objects, and then translate that into specification math.
   … For example in terms of layout one big difference between
   using the centre vs a corner for transformation, unless you
   apply padding or
   … scaling, if you use the centre of the block you may have
   glyphs moving outside the original box. And that affects

   Glenn: Even if you use a corner, if you do not reduce your line
   measure and adjust accordingly then you may overflow on one
   side or the other
   … of the line areas.

   Nigel: I was about to say that

   Cyril: Only on one edge, right?

   Glenn: In the implementation I did I take the shear into
   account of the length of the original line area, and reduce it
   in order to keep the
   … aligned measure within the outer block area, without
   overflowing. I don't take into account any other consideration
   at that point.
   … Then I lay out without shear, mark the line area as having
   shear applied, and then apply the skew transformation when
   rendering the line.
   … In my case I apply the skew not based on the centre.

   SUMMARY: We need to work out what we want it to do before any
   detailed specification.

   Glenn: It gets more complicated if different segments on a line
   have different shear direction. To prevent them from colliding
   you need to
   … temporarily increase the space between them in order to avoid
   collision. Since we can specify font-shear on a character by
   character basis
   … that means that different characters on a line may have
   different shears and spacing.

  Meeting close

   Nigel: Thanks everyone, apologies if there was some confusion
   about the timing of this meeting. We're out of time so I'll
   adjourn now.
   … [adjourns meeting]

   <atsushi> ahhhh, sorry I forgot that!

    Minutes manually created (not a transcript), formatted by
    [13]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

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

Received on Thursday, 18 March 2021 17:17:57 UTC