Meeting minutes
This meeting
Nigel: Several topics for today, need to timebox them.
… TPAC Planning
… Proposal to gather new TT requirements
… IMSC font size limit
… TTML attribute value normalization
… WebVTT Rendering of multiple cues with the same time span
… WebVTT interop calls
… Any other topics?
TPAC Planning
Nigel: Any comments on the draft schedule, or agenda topics to raise for TPAC?
… I have an action that I haven't done yet to make a wiki page for TPAC
… with the current draft agenda topics listed
Atsushi: I will be remote for TPAC
Nigel: Ouch
… (for timing!)
Impact of AI technologies on Timed Text Working Group's mission
Nigel: I raised a proposal for a task force of MEIG to gather any new or unmet
… requirements for timed text, especially arising or being made more cost effective
… due to AI, which is at w3c/media-and-entertainment#122
… and that proposal is on the agenda for next week's MEIG meeting.
… I would encourage participation! Both in MEIG and in the task force if you are able.
… Please do review the proposal.
Pierre: Do you have to be a member of W3C to participate?
Atsushi: For IG invitation by Chairs is possible.
Nigel: To be a member of the task force you would need to be a member of MEIG.
… However I expect the task force to take input broadly, not just from W3C members.
Pierre: That will significantly restrict membership of the task force
Nigel: Yes.
Pierre: The big difference is this is a W3C effort not something to advertise publicly
Atsushi: Any IG member can participate.
Pierre: It's not as easy as going on social media and saying "please join"
Nigel: OK but the task force can be small to produce the deliverables but can publicise
… the request for requirements, and those inputs can come from a broad out-of-W3C constituency.
Andreas: I assume the results of the task force can be public and people can
… contribute by email, say. I'm not sure if there is a public MEIG mailing list?
Atsushi: For public lists anyone can post.
… The discussion can somehow be viewed and commented on by the general public.
Nigel: If the level of public visibility is important to you and is not clear enough in the proposal,
… please comment on the proposal in the MEIG issue.
Andreas: I'm interested to contribute but will not be available next Tuesday.
Nigel: Great, obviously you can comment on the proposal in the issue any time.
… Also worth mentioning that I described loosely this upcoming work proposal
… in the Academy's Expressive Captioning summit on Friday morning / Thursday evening
… and there was some immediate interest by people wanting to participate and contribute.
IMSC / IMSC-HRM font resource size limit
Nigel: IMSC 1.2 had a maximum font resource size limit.
… That didn't make it into IMSC-HRM, and also is not in IMSC 1.3.
… Atsushi noticed this and raised it.
Atsushi: I noticed that recently Open Type Format, which is used for font resources,
… which extends the limitation on the maximum number of glyphs in one file.
… IMSC 1.2's limit was 10 MB and the processor had to reject larger files.
… That was in the HRM part of the specification.
… This limitation has been removed.
… I also checked for differences between IMSC 1.3 and IMSC HRM but that was the
… only difference.
… I don't believe we need changes to IMSC-HRM.
… If we want a cap to the online resources to be applied by IMSC processors
… then we would need to add that text into IMSC, but I'm not sure if we want that
… kind of cap in IMSC.
Nigel: I don't know if we want it either, but there is a 3rd option.
… That would be to create a new normative specification whose purpose is to
… constrain the size of resources, and allow users of, say, IMSC 1.3, to point to the
… new resource limitating specification as a normative requirement as well.
… That would align with the IMSC-HRM approach.
… Right now, an adopter or implementer can require or not require adherence to
… IMSC-HRM independently of adherence to IMSC, so we could extend that approach.
… It's just an option.
Pierre: For practical applications having that kind of size limit is critical.
… I couldn't find any evidence why we dropped it, maybe by mistake or we forgot to write it down.
… I'm supportive of writing down the constraint.
… From experience it's critical. What constitutes a large font file is in the eye of the beholder.
… To the extent that we can help, we should.
… I know we were careful with IMSC-HRM so I am puzzled that we dropped it.
Nigel: I have no recollection of dropping it deliberately.
Pierre: We did spend a lot of time making sure we hadn't dropped anything.
… It could be a simple mistake.
Nigel: Is it better in the HRM or in the base spec?
Pierre: I think HRM would be best, but also it could be that different applications
… have slightly different requirements.
… I would say HRM is the default unless we want to do something different.
Nigel: It's feasibly a reusable constraint, independent of IMSC and of IMSC-HRM.
… It could be applied to other kinds of resources too.
Pierre: Yes absolutely.
Nigel: Any other views?
… I'm not sure what to do.
… Atsushi are there now use cases for very large font files?
Atsushi: The current discussion is to subset font files.
… At OS level the font file may be large but for websites or sharing online there is
… some use case to make an on-demand subset to minimise the size of data transfer.
… I'm not sure if a new feature would be integrated. I don't think large font files
… would be used except at OS or infrastructure level.
Nigel: That makes sense. Probably worth finding a way to set maximum resource sizes then.
Pierre: My summary is we need an issue to be filed and then we'll tackle it.
… It takes an issue and a specific recommendation and then we can decide what to do.
… I would suggest filing it against the HRM.
Atsushi: Or produce a normative short note.
Pierre: Depends on what the issue says and the reaction to it.
Atsushi: I will try to file an issue referencing the email I forwarded to public-tt.
Nigel: Thank you.
TTML attribute value normalization
Nigel: There has been some online discussion about this.
Pierre: The status of my thinking is that in the context of tts:fontFamily very specifically
… the note you found in XSL 1.1 that mentions stripping leading and trailing spaces
… from font family names is a smoking gun, and that will solve the immediate issue.
… The rest is consistent with attribute normalization being performed as though they
… are all strings. The issue is that if you trip leading and trailing spaces from all
… attributes then a ton of tests fail.
… In the short term I'm satisfied and also I really do not want us to encourage people
… to have leading and trailing spaces, because it increases complexity.
… I have filed other issues that I've found. I'll continue accumulating them.
Nigel: All TTML issues?
Pierre: Yes, for instance the w3c/ttml1-tests#14 - apparently a font family of
… initial or inherit is invalid but I have not found any prohibition anywhere.
… It probably is a bad idea!
… There's a TTML2 one that's a lot more troublesome, the use of whitepace in some
… of the combinatorial expressions like `all`. I'm happy to continue noting them
… and we tackle them at the end. Appreciated if people can respond earlier.
… We don't have to do it today.
Nigel: It might be more efficient to gather them all together and then there might
… be some principle approaches we can take to resolving them.
Pierre: Sounds great.
Nigel: Thank you.
WebVTT rendering of multiple cues with the same time span
Gary: This came up at our last interop WebVTT meeting.
… We were looking at some tests and the tests had multiple cues with the same start
… and end times and the issue is around how those cues should be rendered.
… We briefly spoke about this 4 years ago.
… Essentially from the point of view of a person looking at the WebVTT file,
… you might think they should be rendered in document order, i.e. the first rendered
… at the top, and so forth.
… What actually happens is they get rendered in reverse order,
… because the algorithm says to take each cue in turn and present it without covering
… the existing one, so it gets pushed up.
… The question is if that is something to change in the spec.
… The issue was with respect to controls, which, when they show and only overlap
… one of the cues, caused the cues to switch order.
Valid test does not match "all(" <lwsp> designators <lwsp> ")" syntax
Gary: The question is if rendering as a block makes sense and if changing it would cause
<gkatsev_cloud> previous discussion on this topic
Gary: backward compatibility concerns.
Andreas: What is a related form in TTML? It would be like timed elements like <p>.
… What would happen if there's transcoding from TTML to WebVTT?
… If each <p> is translated to a different WebVTT cue, then would the presentation
… be consistent or as expected, possibly not.
Gary: How does TTML handle it?
Nigel: In the case of TTML you'd have multiple timed elements in the same region
… that overlap in time.
… And they must be displayed in document order.
… That means that a later element becoming active while an earlier one remains active
… can cause the earlier one to move position, e.g. upwards.
… I don't know if that was something people wanted to avoid in WebVTT.
Andreas: This is block progression order, defined by the writing mode.
Nigel: That's right, but there's no bottom to top writing mode
Gary: If you have multiple regions how does that work?
Andreas: Each region is explicitly positioned.
Pierre: Correct, that's a big difference with WebVTT, there's no attempt at reflowing
… regions so that's a big difference.
Gary: With WebVTT regions they would always come in at the bottom.
Pierre: There's no attempt at reflowing cues to avoid overlap.
Nigel: Confirming writingMode has no bottom to top mode.
Gary: Nor does CSS
Pierre: Why is that important?
Nigel: It's logical order - if there were a writing mode that went bottom to top then
… you'd expect the text to move the other way.
Gary: I do know that some players auto-reverse when there are multiple cues at the same time
… to get around this.
… The main concern with me is the way the players already handle it.
Nigel: Are you saying that both behaviours exist in current live players?
Gary: I think so, some players have that based on product decisions, where they
… wanted the cues displayed in the expected order rather than the strict spec order.
… The majority, if they have each line in a separate cue, they are explicitly positioned.
… So that might reduce the impact.
… It came up because there were a couple of tests.
Nigel: I would say that cues appearing in non-lexical order is unexpected.
… And cues changing order because of controls is definitely a problem. There's no
… use case for that.
Gary: It would be good to make a decision about updating this in the spec
… even though there might be backward compatibility issues or leave it as it is
… even if that's not how it's implemented always.
Pierre: The automatic reflowing of cues - how consistently is that implemented?
Gary: For controls, or just cues?
Pierre: Just cues
Gary: I think that's pretty good
… I should spend more time checking what the spec says.
… I think it is to start at the first cue and continue rendering.
WebVTT interop calls
Gary: There are interop calls for WebVTT that Dana is chairing and that happen
… every other Wednesday at noon Eastern timezone, and we're going to try to
… make that appear on the TTWG calendar, likely as a TTWG Task Force.
… Need to figure out the locations of that and whatnot going forward..
Nigel: If you could send something round when that's in place it would be useful.
Meeting close
Nigel: Next call would be on 13th August. Neither Gary nor I are able to make it.
Nigel: Propose to cancel
Andreas: +1
Atsushi: +1
Nigel: OK, thanks everyone, see you in 4 weeks, on 2026-08-27
Nigel: Bye everyone, have a good August. [adjourns meeting]