{Minutes} TTWG meeting 2020-04-01

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


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

01 April 2021

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

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

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

      [4] https://www.w3.org/2021/04/01-tt-irc


Attendees

   Present
          Andreas, Atsushi, Gary, Nigel, Pierre

   Regrets
          Cyril, Glenn

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]WebVTT - Added unbounded TextTrackCue.endTime
       w3c/webvtt#493
    3. [7]TTML2 Mention fingerprinting vectors in privacy
       considerations. #1189
    4. [8]Shear calculations and origin of coordinate system.
       w3c/ttml2#1199
    5. [9]Cadence of future meetings
    6. [10]Implementation news regarding the AD profile of TTML2
    7. [11]Meeting close

Meeting minutes

  This meeting

   Nigel: Today we have 2 TTML2 issues, and a WebVTT issue.
   … and I'd like to agree the cadence of our upcoming meetings,
   and
   … I have some AOB about Audio Description.
   … Any other business?

   group: [no other business]

  WebVTT - Added unbounded TextTrackCue.endTime w3c/webvtt#493

   github: [12]https://github.com/w3c/webvtt/pull/493


     [12] https://github.com/w3c/webvtt/pull/493


   Gary: Two issues that are discussed in the pull request. I
   think we should be clear on what the PR is
   … and whether there are any objections about that progressing
   and then we can talk about the other part.
   … The PR is about updating the VTTCue API to be able to have an
   unbounded end time, i.e. set to infinity.
   … It lines up with the HTML spec for TextTrackCue, and was
   brought up mostly as a way for metadata but I think it makes
   sense for anything.
   … Since this PR only covers that, are there any objections for
   that part of it?

   Nigel: Note we discussed this 28 days ago at [13]https://
   github.com/w3c/webvtt/pull/493#issuecomment-790758189
   … We wanted tests, and to ask if a syntax change is needed.
   … Formally, I think it is _not_ required to have a syntax
   change to agree to this change.

     [13] https://github.com/w3c/webvtt/pull/493#issuecomment-790758189


   Gary: Yes, and as the discussion brought up, there are a lot of
   complications to doing that, and what it would mean,
   … so it is good to decouple it so we are not holding up this
   change elsewhere while we figure out the syntax.
   … As David Singer said, even in ISOBMFF, they don't really
   specify how these unbounded cues might come to be.

   Nigel: We need to be careful - ISOBMFF is only a file format
   wrapper, so for them to be even considering unbounded VTT cues
   without
   … any syntax to represent them is a bit disturbing.

   Gary: I think there are use cases for the syntax change but
   figuring them all out and the semantics is definitely not just
   slapping a change in
   … to the cue settings - it's probably not good enough on its
   own.

   Nigel: Are there any tests?

   Gary: I don't know if there are yet. Rob Smith did say he would
   write some. I don't know if he's got around to it yet.
   … I think we can wait for tests, and that can be the only
   blocker for this PR.

   Nigel: Makes sense.

   Gary: Do we want to discuss syntax, or punt on it for now?

   Nigel: I think raise it as a separate issue.

   Gary: Yes, makes sense.
   … If Rob doesn't make that issue then I will make one.

   SUMMARY: 1. No objections to this PR as is, though we are
   blocked on tests. 2. Move the unbounded cue syntax question
   into a separate issue.

  TTML2 Mention fingerprinting vectors in privacy considerations. #1189

   github: [14]https://github.com/w3c/ttml2/issues/1189


     [14] https://github.com/w3c/ttml2/issues/1189


   Nigel: This issue has been closed, but was closed without
   confirmation from the issue raiser that they were satisfied.
   … @jyasskin responded to say that he considers some parts of
   the original issue not to have been addressed.
   … The original analysis from Glenn was that most of the issues
   are already in TTML1 and several are covered in general by the
   … appendix on security and privacy considerations.
   … What we need to decide is if we think the current text is
   adequate given this Horizontal Review comment, or if we can and
   should
   … call out specific possibilities as per the issue.
   … I'd suggest if we do call out the possibilities we do them as
   "for example" style notes.
   … Any views?
   … Looking at the current CRS Privacy section, I think some of
   the vectors are already covered but maybe not in detail.
   … I'll go through each of the listed vectors and show where it
   is, or if it is not mentioned, and come up with a proposal for
   addressing the resulting gaps.
   … Make sense?

   Pierre: I suspect we're going to have this discussion again
   where the commenter wants us to be more explicit than we have
   wanted to be in the past.
   … I'm not sure how we resolve it. It is a larger architecture
   issue. What you're proposing is a good idea, but we have to be
   prepared to
   … have the broader discussion again about whether every single
   W3C specification has really specific implementation
   recommendations or
   … if there should be a central spec.

   Nigel: I'm comfortable listing the considerations that apply
   specifically to the domain of TTML, and I don't think this
   issue is asking for more than that.

   SUMMARY: @nigelmegitt to review the vectors in detail and
   propose how to resolve any gaps.

   Nigel: I will also reopen this issue.

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

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


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


   Nigel: This is about block shear. Cyril raised a comment
   recently about the formula for reducing the inline progression
   dimension
   … prior to shear transformation.
   … Has anyone been able to review that comment?

   Pierre: No

   Nigel: That would be a substantive issue if it is wrong.
   … I weighed in a couple of weeks ago with something that's
   possibly more concerning
   … if people are implementing now.
   … There's a computational impact that I don't think we
   realised.
   … Unless there's a strong requirement I think we should
   consider dropping the feature.

   Pierre: What saves us here is that it is always possible for
   the author to give sufficient space to guarantee that
   … line wrapping will not happen because it is really
   undesirable in the case of Japanese, especially if there are
   rubys involved.
   … In practice it has not been a big issue.
   … A more complicated answer is that CSS cannot support line
   shear today, which is a huge limitation.
   … More importantly there's an ongoing debate. I've seen
   arguments on both sides.
   … If you shear ruby annotations and ruby base text how should
  they be arranged?
   … It can change the alignment if you shear separately from
   shearing together.
   … I've heard strong opinions both ways that you must shear them
   separately or together.

   Atsushi: On the point, i18n WG Japanese task force reached out
   to someone working in typography but there was
   … no consensus or good suggestion.

   Pierre: In fact, if you don't care about the relationship of
   alignment between ruby annotations and ruby base then you can
   … just use fontShear, but that does not work for tate chu yoko.
   … It is complicated. The potential for overflow or line
   wrapping in block shear has not been a problem so far.
   … The potential is really terrible.
   … Font shear would work great but in the case of ta te chu yoko
   you need block shear or line shear.
   … And another aspect, which is somewhat arbitrary but needs
   thinking about: do we want block shear or line shear to
   … change if you're writing rtl or ltr for Hebrew vs English for
   instance. One could argue you should never use them
   … but we still need to specify what happens.
   … So far in imscJS just as a data point nobody has complained
   about block shear.

   Nigel: In imscJS does the resulting parallelogram from the
   shear go outside the boundaries of the original block area?

   Pierre: Yes, the CSS skew just allows it to go outside the
   boundaries.

   Nigel: And it's only in the inline progression direction that
   you get an overflow?

   Pierre: Correct.
   … In Japanese it isn't really an issue in practice, because the
   authoring guarantees that lines won't wrap, and there's
   … plenty of padding and no background, so in practice it seems
   to work.
   … Line shear would be awesome and solves all problems but is
   not possible to implement in CSS today.
   … And some people might object to it. As pointed out I'm not
   sure there's a consensus.

   Nigel: And my assumption is line shear would include the rubys
   on the line?

   Pierre: Yes absolutely, and the tate chu yoko when that's used.

   Nigel: That feels like the answer - doesn't everyone just want
   that?

   Pierre: If supported in CSS, maybe. We would need to go back to
   the original issue.
   … The reason it was not picked for IMSC is the lack of support
   in CSS.

   Nigel: Going back to the Japanese language task force, my
   understanding is that shear is mostly used in electronic
   displays, and very little
   … on paper?

   Atsushi: In daily life I very rarely see shear in daily life,
   on either kind of display. I don't think I saw anything this
   week.
   … The consensus in the Japanese task force is that it is an
   interesting question but who cares?

   Nigel: This came to us because of its use in captions - is that
   an aspect you would notice in daily life?

   Atsushi: I think there is use in captions for some scenarios in
   movies, say, but for television captions I think it is still
   quite rare.

   Nigel: Okay, thanks.
   … Nevertheless we clearly have a requirement for it, certainly
   from Netflix.

   Atsushi: Captions in movies import styling meanings from
   western languages so they import the same semantic meaning as
   italics,
   … but I believe using shearing or italic case is quite a
   specific use case, say for non-on-screen communications
   perhaps.

   Nigel: But a real one?

  Atsushi: Yes, that's correct.
   … To be honest, some older typographic designers say there's no
   italic in Japanese so they don't want to implement it even in
   fonts.

   Pierre: It is in widespread use in cinemas.

   Atsushi: In other words, there is no widely used common
   standard for how to shear or how to make italics.

   Pierre: There's a cinema standard.

   Atsushi: If cinema standard is well written, and has well
   considered definitions it may be possible to borrow it but I'm
   not sure if it is or not.

   Pierre: This was already provided by the way, to W3C.
   … The cinema standard.
   … In an issue.

   Nigel: We have sources for this so it might be worth going back
   and reminding ourselves what they say.
   … I think the easy thing to do here, the direction question
   aside, is to say that the shear may result in an overflow in
   the inline progression
   … direction, and it's then up to implementations to try to do
   anything more complicated, and authors can apply padding as
   needed to avoid
   … it if they like.
   … It may not be entirely interoperable, but it is at least
   implementable.

   SUMMARY: Outstanding questions remain, regarding direction, and
   scaling. Real world computational issues have not yet arisen.

  Cadence of future meetings

   Nigel: Is the 2 weekly cadence working for everyone?

   Pierre: Seems right to me.

   Atsushi: I will follow you

   Gary: No objections

   Andreas: Fine for me.

   Nigel: Great, I will set up a recurring meeting in the new
   calendar system, so we don't need ICS files,
   … and I will also open the GitHub issues which continue to work
   well in managing the agenda and conversation.

  Implementation news regarding the AD profile of TTML2

   Nigel: Hot off the press, I just pressed the button this
   afternoon, to open up our adhere AD profile of TTML2 to be open
   source.

   [16]Adhere library

     [16] https://github.com/bbc/adhere-lib


   [17]Demo page

     [17] https://bbc.github.io/Adhere/


   Nigel: We split out the core underlying code from the demo page
   to be in a separate library.
   … This means you can play with it as you see fit!
   … Hopefully that will unlock other implementations as well.
   … I'll send a separate message to the implementers I think are
   waiting on this.

   Andreas: Thanks Nigel that's really good news.

   Nigel: Yes, it's taken a long time and it's far from perfect!

  Meeting close

   Nigel: Thanks everyone, regrets for me for 2 weeks time, I'll
   leave this call in your capable hands everyone!
   … [adjourns meeting]


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

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