{Minutes} TTWG Meeting 2020-02-13

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


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

13 February 2020

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

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

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

      [4] https://www.w3.org/2020/02/13-tt-irc


Attendees

   Present
          Atsushi, Cyril, Gary, Glenn, Nigel, Pierre

   Regrets
          Andreas

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [5]Meeting minutes
         1. [6]This Meeting
         2. [7]TTML2 2nd Edition CR
         3. [8]TTML2 2nd Ed Tests
         4. [9]AOB - shear
         5. [10]AOB - IMSC 1.2 HR
         6. [11]Meeting close

Meeting minutes

  This Meeting

   Nigel: Today we have TTML2 2nd Ed CR work, mainly.
   … In AOB I'd like to raise IMSC 1.2 HR requests, which is
   w3c/ttwg#76
   … Is there any other business?

   Glenn: Chris Lilley reopened an old issue, 1070 on TTML2. I
   responded, so can we add to AOB?

   Nigel: Yes.

   Cyril: I have a small question about shear to add too.

   Nigel: OK, any more?

  TTML2 2nd Edition CR

   Nigel: First on this agenda item is the banner message on the
   TTML2 1st Ed Rec.
   … Do we have any more information about our choices here?

   <atsushi> [12]https://www.w3.org/2003/01/republishing/


     [12] https://www.w3.org/2003/01/republishing/


   Atsushi: I just talked with plh on this and there is a way to
   update the status on the previous recommendation.

   <atsushi> > 2. Permitted classes of modifications for "end
   state" documents

   Atsushi: It's as per the above link, section 2. It should be
   possible to update the SOTD not in a banner.

   Glenn: I think that's undesirable. I'd rather leave the status
   the same.
   … I doubt if anyone would go looking through the status for
   that information. They _could_ but I've never seen any
   … document do that before. We've not done it in TTWG before for
   previous documents.

   Nigel: Just checking back, does this mean we cannot choose our
   own custom message?

   Atsushi: That was the answer.

   Nigel: Do we have a menu of the messages that already exist?

   Atsushi: Updating the SOTD is the way to do it, as I
   understand.

   Glenn: I have an alternative as indicated in my comment to
   issue 1070.
   … Chris pointed out in that issue that we had not put anything
   in the Errata page for the current Rec.
   … I suggested in my comment to him that we could put a link in
   the Errata page for the current Rec pointing at
   … the new CR, and that if we wanted to we could also point at
   the changes document.

   Nigel: That sounds quite neat to me.

   Glenn: We don't want to list in the errata document for the
   existing Rec all the changes but we could
   … put a link in it to the new CR work and the changes, making
   it possible for people to find it that way.
   … That would be better than changing the SOTD of the current
   Rec in my opinion.
   … It would also probably satisfy Chris's comment and we could
   reclose #1070.

   Nigel: Does anyone see any problems with that idea?

   Atsushi: I don't think there is any issue to put something in
   the Errata page.

   Glenn: In that case I will create an edited version of the
   current Rec's Errata page and create a pull request for
   updating
   … that and once it's put into master then Atsushi can update it
   on /TR.

   Atsushi: I can deploy that, yes.

   Nigel: OK, sounds good, thank you. Any more on this part of the
   agenda?
   … No, then moving on:

  TTML2 2nd Ed Tests

   Nigel: I'm wondering if we can iterate through these and assign
   the work.

   Glenn: I've identified 11 PRs that need tests and I'm working
   on the tests.
   … I can sign myself up for all of those.
   … Unless there are some related to audio that I can't handle.
   … I've created a spreadsheet that I'm working from.
   … I'm checking for each one if it is testable or untestable.
   … At the beginning stage of that process.
   … I will also determine if there are any I cannot handle, e.g.
   relating to audio, where I might want help from you for
   example, Nigel.

   Nigel: OK

   Glenn: Maybe this week would be a good week to finish those.
   … There are 11 PRs that I've entered into the spreadsheet that
   need to be addressed.

   Nigel: Please could we make that transparent. I'd suggest
   opening an issue for each one in ttml2-tests repo,
   … so that we can record a disposition against each one, either
   as untestable or as needing a pull request.

   Glenn: I don't want the extra bureaucratic overhead.

   Nigel: I know but we need this to work together. Send me the
   spreadsheet if you want, and I'll open the issues.

   Cyril: I've made a spreadsheet also.
   … I sent this to the mailing list.

   Nigel: I did not notice that.

   Glenn: I don't think that's the same thing - did you deal with
   PRs with no tests associated with them?

   Cyril: I looked at all the PRs on TTML2 2nd Ed as listed on the
   change page, and marked them up as testable/untestable
   … and if testable, if a test is present or missing.

   Glenn: OK I need to go and look at your spreadsheet as well.

   Cyril: I thought I shared it with the group, didn't I?

   Nigel: I don't remember seeing it, apologies if I missed it.

   Cyril: I sent it 7 days ago.
   … I created the IR too:

   [13]TTML2 2nd Ed Implementation Report

     [13] https://www.w3.org/wiki/TimedText/TTML2SecondEditionImplementationReport


   Nigel: I can't see the spreadsheet.

   Cyril: It is in my response to Glenn there's a link to a Google
   spreadsheet

   [14]TTML2 2nd Ed test suite analysis (Google spreadsheet)

     [14] https://docs.google.com/spreadsheets/d/1oo9DtHBBn_t0Nhba4thDASibS0G5fZaJ9HkvlRXdTqo/edit#gid=0

   Cyril: They say "untestable" because there's a label on the PR
   of the spec.
   … If it says "NO TEST" then it is missing tests, and not
   untestable.

   Glenn: It sounds like you've already done the work that Nigel
   was asking for to share a spreadsheet.
   … I just need to update it. Is it writable?

   Cyril: I can make it writeable.
   … I can't do it right now, I'm not in front of my computer.
   … I found 9 changes that require tests.

   Glenn: I had 11, so that's close, I can tweak it as needed.

   Nigel: I could take an action to open a test repo issue for
   everything that says "no test"

   Glenn: Could you not do that please, I've been adopting a
   particular way of doing those issues.
   … I will do them, if you please.

   Nigel: OK, sure.

   Glenn: I'm linking them to the PRs in a specific way in
   descriptive terms and so forth.

   Nigel: Back to our agenda, we have an iteration and Glenn will
   create the tests, except if there are any that he
   … needs assistance with, he will contact someone else to ask
   for assistance.

   Glenn: I'm not sure if the audio changes are testable. At least
   one is for a feature designation but I'm not sure if
   … that translates into any test. I need to review the
   testability of it.

   Nigel: OK
   … That's where we needed to get to for now. Anything else on
   the tests or 2nd Ed?
   … [silence]
   … OK, thank you Glenn and Cyril for taking the lead on this and
   preparing this data.

   Glenn: By the way, we had put in March 17 as the
   no-earlier-than for requesting a PR transition. That leaves us
   about
   … a month or so from now. Skynav's implementation of TTV can be
   one implementation of the tests, and I think we have
   … most of those wrapped up, and can wrap up the remaining ones
   quite quickly.
   … That leaves one other implementation, so other folks need to
   step forward and do something otherwise we will
   … be left in a holding pattern in terms of moving forward to
   PR.

   Nigel: That is correct.

  AOB - shear

  Cyril: My question is about the anchor point for the shear
   transformation. What is the origin of the coordinate
   … system when you apply a shear?

   Glenn: Very good question. We did not deal with that, did we?

   Cyril: Specifically it seems that there should be a difference
   for vertical text vs horizontal text.
   … I think for horizontal text the origin is the bottom left
   corner of the content box.
   … For left to right that is, and for right to left, probably
   the bottom right corner.
   … For vertical text, right to left, I think it should be the
   top right corner.
   … If it's top to bottom left to right then it should be the top
   left corner.

   Glenn: Since we did not deal with that issue at all I think you
   should file a new issue for 3rd Edition.

   Cyril: Why not an errata?

   Glenn: This is a substantive issue first of all.

   Cyril: We can discuss where it goes.

   Glenn: We're not going to deal with it in 2nd Ed.
   … It will have different answers based on which of the shears
   we are talking about,
   … fontShear, vs lineShear vs blockShear.

   Cyril: Yes, sure.
   … OK I'll open an issue.

   Glenn: Also there are other semantics around shear we did not
   deal with.
   … For example if you are dealing with ta te chu yoko, if you
   are switching between vertical and horizontal and
   … let's say the vertical preceding a horizontal has a shear
   applied to it, and the horizontal has a separate shear applied
   to it.
   … In order to prevent collision, you need to add extra shear
   between the two,
   … or extra white space.

   Cyril: The context is IMSC 1.1 interop testing.

   Glenn: The reason I raise the issue about collision is I
   discovered this when we implemented TTPE.
   … In different contexts when you're dealing with fontShear as
   opposed to lineShear or blockShear, you can get
   … collisions between glyph areas that are unintended. To make
   it visually acceptable
   … the rendering engine needs to add white space.
   … We ended up inserting additional white space.
   … This is outside of the spec completely.
   … There is some really tricky implementation space stuff in
   order to
   … come up with acceptable renderings around shear.
   … I'm pointing this out because if you dive down the
   rabbit-hole with shear,
   … things get a little tricky. You're starting to do that when
   it comes to asking about the origin.

   Cyril: Maybe the outcome is to leave the origin to the
   implementation.

   Glenn: Sometimes that's the better option.

   Pierre: That's only for fontShear, right? For lineShear and
   shear, the behaviour is well defined.

   Glenn: I agree

   Pierre: I'm not making a judgement call which is more pleasing.
   … In the case of block shear, the shear origin is well defined.

   Glenn: The other thing that's interesting is that for
   lineShear, in order to keep the line length from
   … going outside the block area, you end up having to shorten
   the line length.

   Pierre: Absolutely, that's another issue.

   Glenn: It's another implementation trick that we didn't go into
   with the specification.

   Pierre: Same thing with shear.

   Glenn: These are all things that can produce different output
   with regard to interoperability. There are dragons here.

   Pierre: I can't speak about fontShear, but with shear and
   lineShear, and the issue with overflow, with shear
   … allowing the shear line to extend the original boundaries of
   the line or the block, that has an impact
   … on interop. There are two obvious ways to deal with it:
   … 1. Extend the block
   … 2. Wrap the line
   … They yield pretty different results, so maybe we should have
   an opinion on that.

   Cyril: If you don't extend the block then you can get clipped
   glyphs.

   Pierre: Yes, exactly, which is the least desirable.
   … Just to add, shear is not supported by CSS so it would be
   good to have the discussion with the CSS WG.

   Cyril: I am working on that, I have contacted people and am
   discussing it before we have something publicly available.

  AOB - IMSC 1.2 HR

   Nigel: I noticed that our issue [15]https://github.com/w3c/

   ttwg/issues/76 is only partially completed.
   … Unless I did it and failed to update the issue, I think I
   have work to do.
   … Apologies for this, I'm not sure what happened, but I plan to
   get onto it and make the requests for HR for IMSC 1.2
   … This is pretty frustrating.
   … Recalling Jeffrey Yaskin's response on privacy, I think he
   answered about IMSC 1.2 as well as TTML2, I need to check.
   … I really wish there was an easier way to do HR. It's pretty
   frustrating if we've lost 3 months.

     [15] https://github.com/w3c/ttwg/issues/76


   Pierre: The changes for IMSC 1.2 do not warrant 3 months, which
   is why the Charter says should not shall have 3 months.
   … We should request review specifically of the changed feature.
   … And ask for an expedited review. Let me know how I can help,
   I'll be bugging you and please bug me.

   Nigel: Thank you for that.

   Pierre: By the way, how is it that HR doesn't start
   automatically? I find it confusing.

   Nigel: I think the idea is groups can request review before
   publishing a WD.

   Pierre: Why doesn't it start automatically at WD publication?
   We can't go prodding every group.

   Nigel: I agree, let's ask for expedited input based on the
   small set of changes.

   <gkatsev> [16]review from Jeffrey Yaskin on TTML and IMSC

     [16] https://lists.w3.org/Archives/Public/public-tt/2019Nov/0011.html


   Gary: It sounds like Jeffrey Yaskin has probably covered
   privacy already. So one less thing to do.

   Nigel: Thank you for that Gary, that's great.

  Meeting close

   Nigel: Thank you everyone, we've completed our agenda. Have a
   good week everyone. [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [17]scribe.perl version 104 (Sat Dec 7 01:59:30 2019 UTC).

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