W3C

Timed Text Working Group Teleconference

13 February 2020

Attendees

Present
Atsushi, Cyril, Gary, Glenn, Nigel, Pierre
Regrets
Andreas
Chair
Nigel
Scribe
nigel

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> 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:

TTML2 2nd Ed Implementation Report

Nigel: I can't see the spreadsheet.

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

TTML2 2nd Ed test suite analysis (Google spreadsheet)

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 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.

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> review from Jeffrey Yaskin on TTML and IMSC

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 scribe.perl version 104 (Sat Dec 7 01:59:30 2019 UTC).