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]