W3C

Timed Text Working Group Teleconference

16 January 2020

Attendees

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

Meeting minutes

This meeting

Nigel: [iterates through agenda]
… Any other business?

Cyril: I tried to revive the thread on CSS WG about line shear so maybe we can talk about that.

Nigel: OK, let's cover in AOB

Nigel: If there's nothing else, let's get going.

IMSC 1.2 FPWD Next steps

Nigel: 2 issues to cover today
… First one is #506.

Glenn: I'm afraid I'm going to have to beg off on this one again.
… I will get around to looking at it. Please could you ping me on Monday so I won't forget it by next meeting?

Nigel: I'll try, but I'm a very bad PA!

font selection rules under-specified? imsc#516

github: https://‌github.com/‌w3c/‌imsc/‌issues/‌516

Nigel: 3 levels we could get to:
… 1. Informative note - you can use font-face
… 2. SHOULD use font-face
… 3. MUST use font-face
… I wanted MUST but concerns raised.

Glenn: If you make fontSelectionStrategy auto mean "use font-face" then it is no longer implementation dependent
… so not backward compatible with existing implementations.

Pierre: So if I have a TTML2 compliant implementation that does not use font-face for auto
… then that would have to be changed to conform to a new requirement specifying what auto means?

Glenn: Yes

Pierre: So it's a processor conformance issue not a document conformance one?

Glenn: Yes

Pierre: Another point Glenn made that I sympathise with is that before taking the plunge and doing a MUST at this
… point in the process and with our limited experience with IMSC 1.2 and TTML2, it is not unreasonable to have a SHOULD
… and if it turns out to be a success we can make it a MUST either in IMSC or through some scheme in TTML2,
… but there's an argument to be made about the complexity and relative age of that feature then a recommendation
… might be a good approach.

Glenn: I had previously suggested a SHOULD but in my last comment I was even not going that far and suggesting
… that SHOULD might be going too far.
… Because SHOULD add a normative aspect to it.
… I would probably make it a hint or put it in a note and say that it is something that is being considered.

Pierre: Maybe one notch above a note could be a pointer: "here's a place where an algorithm is defined"

Glenn: That's possible. If we're going to point at a CSS3 font module algorithm then we need to due some serious due
… diligence about semantic interaction with other normative language in TTML2 that may have to change or get
… modified to interact with that 5.2 language. I pointed to one area regarding the line height algorithm where clearly
… there's going to be some interactions. Just saying "use 5.2 as an algorithm" is risky at the moment. As a possible
… implementation strategy then that's okay, as long as it doesn't invalidate the semantics of TTML2's line height semantics
… and other semantics already implied by TTML2 as adopted by IMSC 1.2 then it's up to you as an implementer,
… but putting it into language in IMSC 1.2 is going to be a little tricky.

Nigel: We have time at this stage, FPWD.
… Secondly, if the line height algorithm is not orthogonal to the font selection algorithm then that's another separate issue.

Glenn: That's quite possible. It's one reason I didn't want to dive into this in TTML2 when it was originally raised, FYI.

Nigel: I made the point too that if someone provides a list of fonts where the font metrics differ substantially in terms
… of line height calculation then that's a second order issue for us, it's a real edge case.

Glenn: It's a really complex area.
… The algorithm finds F0 being a single font for the calculation of line height for the whole p.
… The actual algorithm is fine grained - you have to walk down on a per character basis and this is where the
… fontSelectionStrategy values come into play to determine whether you use character context, and what contextual
… boundaries come into play to break the context into larger or smaller pieces, for example if you have grapheme
… clusters or bidi boundaries or all kinds of other boundaries that might dictate that you do or do not consider
… context for including larger or smaller pieces of text for choosing one font family vs another font family.
… Those all feed into the algorithm that is used in §5.2 of the CSS Font module.
… The algorithm that's used in lineHeight for choosing F0 is at a much higher level for choosing a default font family
… for the line height used to drive the XSL-FO default font family for the line height algorithms that are used there.
… There's a whole bunch of complexity and it is not just something that you can easily take on in one or two meetings.
… Probably a week of reading time to work through the detail!
… Just giving an overview of the work that would be involved in doing that.
… Vladimir should probably attend that meeting!

Nigel: I don't quite buy that the lineHeight algorithm should stop us making progress.
… If the lineHeight algorithm reproduces, either identically or differently to, the font selection strategy, then they
… are not orthogonal but they possibly should be.

Glenn: It reproduces a simplified version of the algorithm for its own purposes.

Nigel: Already it is true that implementations may choose font families with a different algorithm than the lineHeight
… algorithm and that is in spec, so if we change the font family selection algorithm that would not change.

Glenn: That is probably true. I can't comment on actual interoperability across implementations.
… If we were to adopt CSS 3 font family selection and apply it to the font attribute at this time then it could be that
… the line height algorithm could continue independently even though they might produce different font selection.

Nigel: I think that would be acceptable though not ideal.

Glenn: This opens up the elephant in the room that we have not done much interop testing. We have complained about
… it with WebVTT but we have not done much testing of IMSC and TTML2 yet in my opinion.

Pierre: Just on that point, on IMSC 1.1 and IMSC 1.0 there is a lot of interop testing happening outside W3C.
… Just in February there will be another plugfest where IMSC 1.1 will be front and centre.

Glenn: That's good, will you share those results with the group?

Pierre: I'll ask, I don't know why it hasn't happened before, it's a good idea.

Glenn: That'd be great. It's the kind of feedback we should be hearing.

Nigel: Going back to the topic, if lineHeight doesn't choose the same font, it still gives predictable results even if
… they are not desirable ones.

Glenn: There's still the question of whether to do this in IMSC 1.2 or TTML2. It's complicated to know how to do that.
… My opinion is it is not really tractable to bring it into TTML2 directly because it's a core semantic change.
… It could be done via modules, and I suggested a way to do it via fontSelectionStrategy by introducing a new value,
… which would require defining a new module. That would be the way forward.

Nigel: From what I've heard I don't think it would be a problem to say in IMSC 1.2 that we SHOULD use font-face.

Glenn: Not a MAY?

Nigel: There's very little difference between MAY and SHOULD, it's just how strong the hint is.

Glenn: A processor testing regime that's testing for SHOULD compliance may reject an implementation that doesn't
… conform with it.

Nigel: That's what we want because it encourages more interoperability.

Glenn: Are there any processor SHOULD requirements in IMSC? I don't recall.

Pierre: Yes we have a couple of processor recommendations worded with a SHOULD.
… I'm really happy with MAY, SHOULD or just "hey here's a place where there's an algorithm defined".
… They're slightly different. MAY implies that we now permit something that was prohibited before.
… SHOULD is definitely stronger. If we are really confident that the algorithm works then that's what we should do.

Glenn: "is permitted"?

Pierre: That's a MAY.
… I haven't studied whether the algorithm is actually the right one. I'd like a plan from this meeting.

Nigel: Can I propose a pull request?

Glenn: I will not be happy with SHOULD but I can live with MAY or permitted.

Nigel: A testing regime that enforces SHOULD is downstream of us, and not our call.
… My argument for SHOULD is that it helps encourage implementations to work the same way.

Glenn: Practically speaking MAY and SHOULD are the same for authors because authors need to check their implementations anyway.

Pierre: One argument for not doing SHOULD is that we haven't convinced ourselves that we're really doing the right thing.

Glenn: That's my rationale too.

Pierre: It's extremely complex - I think that's a true statement!
… We don't have a body of documents or examples to guide us.
… That's a strong argument for a MAY, and making clear that if someone were to implement
… the CSS algorithm then that would not be non-compliant. We probably want to avoid that.
… That's my input to the pull request.

Glenn: We don't even have the wording to consider.

Nigel: Ok I'll take the next step then.

SUMMARY: @nigelmegitt to draft a pull request

IMSC 1.1 errata

Nigel: I think this has been fixed.

Pierre: Yes, all good.

Atsushi: I hope so!

Nigel: Thank you for sorting that out Atsushi.

Atsushi: Actually please let me say one point that I did a quick fix, so something may happen.
… Please let me know if there is any issue with the updated page.

TTML2 2nd Edition Wide Review

Atsushi: During the weekly call of i18n WG we decided that Richard would raise issues by next week so
… they may arrive by early next week. Of course input is welcome from TTWG.

Nigel: OK, thank you. I propose that we keep an eye out for those issues and make a call on them.
… If it looks like they are substantive and cannot be dealt with during Proposed Rec then we may need to pause
… our publication timeline while we address them, but we can't tell until we see them.

Glenn: Question - you said there was a review by Fuqiao, have you seen it?

Nigel: No, I just saw a message saying he'd done a review, but I don't know what the outcome was.

<atsushi> https://‌github.com/‌w3c/‌i18n-request/‌issues/‌86#issuecomment-568343266

Glenn: Can you share it with the group or forward it?

Atsushi: I posted a link with some draft comments.

Nigel: Is this a full review of the spec or just the deltas?

Atsushi: Both

Nigel: Should we be looking at only comments with a △ at the beginning?

Glenn: This looks like it is not related to changes in 2nd Edition.
… I did a quick review of all the 2nd Ed changes this morning and I posted a comment in the issue related to our meeting
… agenda that there were two issues closed related to our agenda, 1076 and 1043, one about ignoring white space
… inside a ruby container, and the other was the non-applicability of character properties in ruby container.
… None of those have any i18n semantics and none of the other substantive issues that were addressed have any
… i18n semantics as far as my review is concerned. So my review suggests there are no i18n semantics for any of the
… substantive changes. My recommendation is that we politely decline to extend the review and allow the review to
… continue into the CR period.

Nigel: I'd like to tweak that to say that if there are any comments not related to the delta between TTML2 2nd Ed and
… 1st Ed then we welcome those in our repo but will likely deal with them in a future edition.

Glenn: I agree with that.

Pierre: What Nigel said.

Glenn: Unless there are any comments about things that are truly broken.

Pierre: Yes of course.

Nigel: OK I will respond to Addison and i18n explaining the situation.

Atsushi: Thank you for that.

Glenn: I have a follow-on.
… I have sent a link to Atsushi and you Nigel to a tarball that is ready to upload to the dated URL /TR space for
… publishing on 28th. Is there any reason to hold off on putting that in place at this point?
… In the past Thierry always uploaded these dated URLs in prep for the publication.
… Ahead of time, not at the last second.
… If for some reason an update is needed because of some last minute change then we can always do that and
… overwrite it with an edited tarball.

Nigel: I don't have a view on that, certainly no objection.
… Can I suggest you take that offline Atsushi and let us know if there is anything else that needs to happen.

<atsushi> draft transition request on TTML2-2e CR https://‌github.com/‌w3c/‌transitions/‌issues/‌208

AOB CSS line shear

Nigel: We don't have much time to cover this now - Cyril perhaps you could send a summary of this to the
… group so we can have a look?

Cyril: I tried contacting Tab Atkins, can you suggest anyone else from the Chrome team?

Glenn: I will point you to someone on the layout team.

Cyril: thank you

Meeting close.

Nigel: Thanks everyone, we're 2 minutes over, so let's adjourn. [adjourns meeting]

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