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: https://
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 https://
… 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.
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: https://
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: https://
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.
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]