14:59:56 RRSAgent has joined #tt 14:59:56 logging to https://www.w3.org/2026/07/30-tt-irc 14:59:59 RRSAgent, make logs Public 15:00:00 Meeting: Timed Text Working Group Teleconference 15:00:07 Agenda: https://github.com/w3c/ttwg/issues/344 15:00:09 scribe: nigel 15:00:12 Present: Nigel 15:00:23 Previous meeting: https://www.w3.org/2026/07/16-tt-minutes.html 15:00:29 rrsagent, make minutes 15:00:29 I have made the request to generate https://www.w3.org/2026/07/30-tt-minutes.html nigel 15:02:59 nigel has changed the topic to: TTWG Teleconference 2026-07-30. Joining details: https://www.w3.org/events/meetings/74c31b0a-54dc-4869-bc18-4d398335c084/20260730T150000/ Agenda: github.com/w3c/ttwg/issues/344 15:03:33 Present+ Pierre, Atsushi 15:04:01 Present+ Andreas 15:04:20 Topic: This meeting 15:04:39 Nigel: Several topics for today, need to timebox them. 15:04:44 .. TPAC Planning 15:04:54 .. Proposal to gather new TT requirements 15:05:04 .. IMSC font size limit 15:05:13 .. TTML attribute value normalization 15:05:32 .. WebVTT Rendering of multiple cues with the same time span 15:05:38 .. WebVTT interop calls 15:05:54 .. Any other topics? 15:06:06 Topic: TPAC Planning 15:06:21 -> draft schedule https://www.w3.org/calendar/tpac2026/grid/ 15:06:38 Nigel: Any comments on the draft schedule, or agenda topics to raise for TPAC? 15:07:05 .. I have an action that I haven't done yet to make a wiki page for TPAC 15:07:16 .. with the current draft agenda topics listed 15:07:43 Atsushi: I will be remote for TPAC 15:07:45 Nigel: Ouch 15:08:10 atai has joined #tt 15:08:35 .. (for timing!) 15:08:55 Topic: Impact of AI technologies on Timed Text Working Group's mission 15:09:18 Nigel: I raised a proposal for a task force of MEIG to gather any new or unmet 15:09:31 .. requirements for timed text, especially arising or being made more cost effective 15:09:48 .. due to AI, which is at w3c/media-and-entertainment#122 15:10:02 .. and that proposal is on the agenda for next week's MEIG meeting. 15:10:22 .. I would encourage participation! Both in MEIG and in the task force if you are able. 15:11:56 .. Please do review the proposal. 15:12:05 Pierre: Do you have to be a member of W3C to participate? 15:12:17 Atsushi: For IG invitation by Chairs is possible. 15:12:36 q+ 15:12:38 Nigel: To be a member of the task force you would need to be a member of MEIG. 15:12:54 .. However I expect the task force to take input broadly, not just from W3C members. 15:13:27 Pierre: That will significantly restrict membership of the task force 15:13:33 Nigel: Yes. 15:13:50 Pierre: The big difference is this is a W3C effort not something to advertise publicly 15:14:01 Atsushi: Any IG member can participate. 15:14:12 Pierre: It's not as easy as going on social media and saying "please join" 15:14:19 danae404 has joined #tt 15:15:27 Nigel: OK but the task force can be small to produce the deliverables but can publicise 15:15:57 .. the request for requirements, and those inputs can come from a broad out-of-W3C constituency. 15:16:07 Andreas: I assume the results of the task force can be public and people can 15:16:24 .. contribute by email, say. I'm not sure if there is a public MEIG mailing list? 15:16:33 Atsushi: For public lists anyone can post. 15:17:11 .. The discussion can somehow be viewed and commented on by the general public. 15:17:39 Nigel: If the level of public visibility is important to you and is not clear enough in the proposal, 15:17:45 .. please comment on the proposal in the MEIG issue. 15:18:03 ack atai 15:18:14 Andreas: I'm interested to contribute but will not be available next Tuesday. 15:18:36 Nigel: Great, obviously you can comment on the proposal in the issue any time. 15:19:01 .. Also worth mentioning that I described loosely this upcoming work proposal 15:19:22 .. in the Academy's Expressive Captioning summit on Friday morning / Thursday evening 15:19:34 .. and there was some immediate interest by people wanting to participate and contribute. 15:20:01 q? 15:20:17 Topic: IMSC / IMSC-HRM font resource size limit 15:20:33 Nigel: IMSC 1.2 had a maximum font resource size limit. 15:20:46 .. That didn't make it into IMSC-HRM, and also is not in IMSC 1.3. 15:21:03 .. Atsushi noticed this and raised it. 15:21:40 Atsushi: I noticed that recently Open Type Format, which is used for font resources, 15:22:01 .. which extends the limitation on the maximum number of glyphs in one file. 15:22:44 .. IMSC 1.2's limit was 10 MB and the processor had to reject larger files. 15:23:03 .. That was in the HRM part of the specification. 15:23:18 .. This limitation has been removed. 15:23:35 .. I also checked for differences between IMSC 1.3 and IMSC HRM but that was the 15:23:37 .. only difference. 15:23:54 .. I don't believe we need changes to IMSC-HRM. 15:24:10 .. If we want a cap to the online resources to be applied by IMSC processors 15:24:21 .. then we would need to add that text into IMSC, but I'm not sure if we want that 15:24:24 .. kind of cap in IMSC. 15:24:44 Nigel: I don't know if we want it either, but there is a 3rd option. 15:24:57 .. That would be to create a new normative specification whose purpose is to 15:25:40 .. constrain the size of resources, and allow users of, say, IMSC 1.3, to point to the 15:25:53 .. new resource limitating specification as a normative requirement as well. 15:25:58 .. That would align with the IMSC-HRM approach. 15:26:17 .. Right now, an adopter or implementer can require or not require adherence to 15:26:40 .. IMSC-HRM independently of adherence to IMSC, so we could extend that approach. 15:26:46 .. It's just an option. 15:27:19 Pierre: For practical applications having that kind of size limit is critical. 15:27:39 .. I couldn't find any evidence why we dropped it, maybe by mistake or we forgot to write it down. 15:27:50 .. I'm supportive of writing down the constraint. 15:28:05 .. From experience it's critical. What constitutes a large font file is in the eye of the beholder. 15:28:14 .. To the extent that we can help, we should. 15:28:32 .. I know we were careful with IMSC-HRM so I am puzzled that we dropped it. 15:28:48 Nigel: I have no recollection of dropping it deliberately. 15:29:02 Pierre: We did spend a lot of time making sure we hadn't dropped anything. 15:29:06 .. It could be a simple mistake. 15:29:22 Nigel: Is it better in the HRM or in the base spec? 15:29:34 Pierre: I think HRM would be best, but also it could be that different applications 15:29:40 .. have slightly different requirements. 15:29:54 .. I would say HRM is the default unless we want to do something different. 15:30:19 Nigel: It's feasibly a reusable constraint, independent of IMSC and of IMSC-HRM. 15:30:30 .. It could be applied to other kinds of resources too. 15:30:34 Pierre: Yes absolutely. 15:31:07 Nigel: Any other views? 15:31:28 .. I'm not sure what to do. 15:31:37 .. Atsushi are there now use cases for very large font files? 15:31:50 Atsushi: The current discussion is to subset font files. 15:32:15 .. At OS level the font file may be large but for websites or sharing online there is 15:32:33 .. some use case to make an on-demand subset to minimise the size of data transfer. 15:33:03 .. I'm not sure if a new feature would be integrated. I don't think large font files 15:33:10 .. would be used except at OS or infrastructure level. 15:33:30 Nigel: That makes sense. Probably worth finding a way to set maximum resource sizes then. 15:33:56 Pierre: My summary is we need an issue to be filed and then we'll tackle it. 15:34:06 .. It takes an issue and a specific recommendation and then we can decide what to do. 15:34:23 .. I would suggest filing it against the HRM. 15:34:32 Atsushi: Or produce a normative short note. 15:34:41 Pierre: Depends on what the issue says and the reaction to it. 15:34:58 Atsushi: I will try to file an issue referencing the email I forwarded to public-tt. 15:35:01 Nigel: Thank you. 15:35:04 Present+ Gary 15:35:08 Chairs: Nigel, Gary 15:35:38 Topic: TTML attribute value normalization 15:35:57 Nigel: There has been some online discussion about this. 15:36:30 Pierre: The status of my thinking is that in the context of tts:fontFamily very specifically 15:36:47 .. the note you found in XSL 1.1 that mentions stripping leading and trailing spaces 15:36:57 .. from font family names is a smoking gun, and that will solve the immediate issue. 15:37:13 .. The rest is consistent with attribute normalization being performed as though they 15:37:24 .. are all strings. The issue is that if you trip leading and trailing spaces from all 15:37:30 .. attributes then a ton of tests fail. 15:37:48 .. In the short term I'm satisfied and also I really do not want us to encourage people 15:37:57 .. to have leading and trailing spaces, because it increases complexity. 15:38:08 .. I have filed other issues that I've found. I'll continue accumulating them. 15:38:15 Nigel: All TTML issues? 15:39:04 Pierre: Yes, for instance the w3c/ttml1-tests#14 - apparently a font family of 15:39:18 .. initial or inherit is invalid but I have not found any prohibition anywhere. 15:39:22 .. It probably is a bad idea! 15:40:00 .. There's a TTML2 one that's a lot more troublesome, the use of whitepace in some 15:40:13 .. of the combinatorial expressions like `all`. I'm happy to continue noting them 15:40:27 .. and we tackle them at the end. Appreciated if people can respond earlier. 15:40:31 .. We don't have to do it today. 15:40:58 Nigel: It might be more efficient to gather them all together and then there might 15:41:06 .. be some principle approaches we can take to resolving them. 15:41:09 Pierre: Sounds great. 15:41:23 Nigel: Thank you. 15:41:40 Topic: WebVTT rendering of multiple cues with the same time span 15:42:06 Gary: This came up at our last interop WebVTT meeting. 15:42:19 .. We were looking at some tests and the tests had multiple cues with the same start 15:42:32 .. and end times and the issue is around how those cues should be rendered. 15:42:48 .. We briefly spoke about this 4 years ago. 15:43:07 .. Essentially from the point of view of a person looking at the WebVTT file, 15:43:17 .. you might think they should be rendered in document order, i.e. the first rendered 15:43:25 .. at the top, and so forth. 15:43:33 .. What actually happens is they get rendered in reverse order, 15:43:47 .. because the algorithm says to take each cue in turn and present it without covering 15:44:00 .. the existing one, so it gets pushed up. 15:44:11 .. The question is if that is something to change in the spec. 15:44:30 .. The issue was with respect to controls, which, when they show and only overlap 15:44:37 .. one of the cues, caused the cues to switch order. 15:45:05 -> https://github.com/w3c/ttml2-tests/issues/287 Valid test does not match "all(" designators ")" syntax 15:45:24 .. The question is if rendering as a block makes sense and if changing it would cause 15:45:26 -> https://github.com/w3c/webvtt/issues/503#issuecomment-1084785995 previous discussion on this topic 15:45:29 .. backward compatibility concerns. 15:45:43 q+ 15:46:11 ack at 15:46:38 Andreas: What is a related form in TTML? It would be like timed elements like

. 15:46:47 .. What would happen if there's transcoding from TTML to WebVTT? 15:47:12 .. If each

is translated to a different WebVTT cue, then would the presentation 15:47:18 .. be consistent or as expected, possibly not. 15:47:23 Gary: How does TTML handle it? 15:47:47 Nigel: In the case of TTML you'd have multiple timed elements in the same region 15:47:49 .. that overlap in time. 15:48:00 .. And they must be displayed in document order. 15:48:29 .. That means that a later element becoming active while an earlier one remains active 15:48:37 q+ 15:48:44 .. can cause the earlier one to move position, e.g. upwards. 15:48:56 .. I don't know if that was something people wanted to avoid in WebVTT. 15:49:03 ack at 15:49:23 Andreas: This is block progression order, defined by the writing mode. 15:49:56 Nigel: That's right, but there's no bottom to top writing mode 15:50:16 Gary: If you have multiple regions how does that work? 15:50:25 Andreas: Each region is explicitly positioned. 15:50:37 Pierre: Correct, that's a big difference with WebVTT, there's no attempt at reflowing 15:50:43 .. regions so that's a big difference. 15:50:53 Gary: With WebVTT regions they would always come in at the bottom. 15:51:02 Pierre: There's no attempt at reflowing cues to avoid overlap. 15:51:56 Nigel: Confirming writingMode has no bottom to top mode. 15:52:01 Gary: Nor does CSS 15:52:08 Pierre: Why is that important? 15:52:26 Nigel: It's logical order - if there were a writing mode that went bottom to top then 15:52:34 .. you'd expect the text to move the other way. 15:52:51 Gary: I do know that some players auto-reverse when there are multiple cues at the same time 15:52:55 .. to get around this. 15:53:05 .. The main concern with me is the way the players already handle it. 15:53:19 Nigel: Are you saying that both behaviours exist in current live players? 15:53:33 Gary: I think so, some players have that based on product decisions, where they 15:53:43 .. wanted the cues displayed in the expected order rather than the strict spec order. 15:54:01 .. The majority, if they have each line in a separate cue, they are explicitly positioned. 15:54:07 .. So that might reduce the impact. 15:54:16 .. It came up because there were a couple of tests. 15:55:14 Nigel: I would say that cues appearing in non-lexical order is unexpected. 15:55:25 .. And cues changing order because of controls is definitely a problem. There's no 15:55:28 .. use case for that. 15:55:39 Gary: It would be good to make a decision about updating this in the spec 15:55:50 .. even though there might be backwards compatibility issues or leave it as it is 15:55:59 .. even if that's not how it's implemented always. 15:56:10 Pierre: The automatic reflowing of cues - how consistently is that implemented? 15:56:19 Gary: For controls, or just cues? 15:56:22 Pierre: Just cues 15:56:26 Gary: I think the 15:56:32 s/the/that's pretty good 15:57:02 .. I should spend more time checking what the spec says. 15:57:10 .. I think it is to start at the first cue and continue rendering. 15:57:37 Topic: WebVTT interop calls 15:57:57 Gary: There are interop calls for WebVTT that Dana is chairing and that happen 15:58:11 .. every other Wednesday at noon Eastern timezone, and we're going to try to 15:58:22 .. make that appear on the TTWG calendar, likely as a TTWG Task Force. 15:58:31 .. Need to figure out the locations of that and whatnot going forwards. 15:58:37 s/rds/rd. 15:58:48 s/rds/rd 15:59:10 Nigel: If you could send something round when that's in place it would be useful. 15:59:15 Topic: Meeting close 15:59:34 .. Next call would be on 13th August. Neither Gary nor I are able to make it. 15:59:58 s/.. Next/Nigel: Next 16:00:06 Nigel: Propose to cancel 16:00:08 Andreas: +1 16:00:36 Atsushi: +1 16:01:10 Nigel: OK, thanks everyone, see you in 4 weeks, on 2026-08-27 16:01:20 -> https://github.com/w3c/ttwg/issues/346 Agenda for 2026-08-27 16:01:35 .. Bye everyone, have a good August. [adjourns meeting] 16:01:38 rrsagent, make minutes 16:01:38 I have made the request to generate https://www.w3.org/2026/07/30-tt-minutes.html nigel 16:03:57 Present+ Dana 16:05:10 scribeOptions: -final -noEmbedDiagnostics 16:05:15 zakim, end meeting 16:05:15 As of this point the attendees have been Nigel, Pierre, Atsushi, Andreas, Gary, Dana 16:05:18 RRSAgent, please draft minutes v2 16:05:18 I have made the request to generate https://www.w3.org/2026/07/30-tt-minutes.html Zakim 16:05:24 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:05:26 Zakim has left #tt 16:07:38 jcraig has joined #tt 16:08:25 rrsagent, excuse us 16:08:25 I see no action items