Meeting minutes
This meeting
Nigel: DAPT, IMSC, and TPAC. Anything else?
(nothing)
DAPT
Add section about mapping from TTML to the DAPT data model w3c/dapt#216
github: w3c/
Nigel: Is there anything left?
Cyril: The PR as a whole makes sense, it's good and consistent. We're making it more complicated by allowing flexibility on use of nested divs
… for a potential future use case
… Pierre suggested making breaking changes for new requirements
… I suggest reflecting on that during the PR phase, and based on feedback
… I'd like the ability to roll back the nested divs if too complicated in implementation
Nigel: I don't mind marking it as at risk
Cyril: Could mark nested divs as being prohibited
Nigel: We could, my only hesitation is that removing it would mean also removing other things, so it would have a bigger editorial impact
… But that's fine, and good to get the implementer feedback, and mark it is at risk
… and see how things go
Nigel: I'd prefer to add the at-risk feature in a new issue
… I just created issue #237 for that
… Any other comments on this PR before merging?
Cyril: Thank you for the work on it
SUMMARY: Pull request merged
Issues review
Cyril: We have a few issues that are duplicates, and some at risk, audio resources related
… For example, #113
Nigel: There are question issues, referenced in the spec, then adding at-risk status issues. Those are marked as PR must-have. We'd decide on those at PR time
Cyril: [Reviews CR must-have issues]
Nigel: I'd like us to attempt to raise PRs for those CR must-have issues, so ready to resolve at TPAC
Cyril: Script events, represents attribute or xml:id
Nigel: I'm thinking about document verbosity and inheritance of these properties
… There's a combinatorial thing, if represents replaces the script event type. What if they don't agree with each other
… Painful if you have to inspect the entire document
… Should it be reasonable to omit event type or represents? Then you'd need some other way
Cyril: What if any div that's a leaf is a script event? And then you inherit the script type or represents, and change it locally if needed
Nigel: So a leaf doesn't contain any div elements?
Cyril: Yes
Nigel: Another thing about xml:id, in operational scenarios, trying to identify to someone where a document change is needed, the xml id makes it unambiguous
… So guiding people to use xml:id encourages good practice
Cyril: You may also want to identify groups by xml:ids
Nigel: Yes. The other way is to be explicit, e.g., a dt attribute, with different values for script event or script event group. But then you require it on every div...
Cyril: I'd change the PR to remove the part that requires mandatory properties of a script event. So only leaf divs are script events
… At the same time remove the script event type property and use represents, and explicitly override if you don't want the inherited value
Cyril: The same inheritance rules as xml:lang
Nigel: ttm:role has a different inheritance model so we do need to be clear about the inheritance model
Cyril: We can work on a concrete proposal for the spec text
Nigel: Need to think about making it mandatory
… Good discussion. We have a target to request CR transition at TPAC
SUMMARY: Any other DAPT topics?
no other topics
IMSC
Superscript/subscript support w3c/imsc#583
github: w3c/
Pierre: This was brought to my attention by a platform that has a presence in France
… There's no way to signal superscript or subscript text. It's an issue in French more than in English for ordinal numbers, where it's better to use superscript
… It's in their style guide as something that should be supported
… I looked into it, and there is a TTML2 font-variant attribute that allows super/subscript glyphs to be selected for a particular font
… The spec says it's derived from the equivalent CSS feature
… It's not a layout feature, it's a glyph-selection feature
… I tried it in CSS, but couldn't find a font that supports it
… So I tried to find where the TTML2 feature came from
… An issue raised 10 years ago, based super/subscript support in CEA 708
… I'm not convinced tts:font-variant is the answer, but I'd like input, so we do it right
… Unicode does have super/subscript characters, but not enough coverage for all ordinals, or not meant to be used that way
Nigel: I researched how you'd do this in HTML and CSS. There seem to be two ways:
… The <sup> and <sub> elements, but there's also a CSS vertical-align feature where you can set the baseline of an element
… Parents have a subscript baseline and a superscript baseline and on inline elements you can set to one or other of those
… So there are two ways, I don't know if one is better than the other
Pierre: The HTML elements are widely used
Nigel: Every browser supports vertical-align too
… You can understand tts:vertical-align being a TTML style attribute, whereas introducing new elements isn't very TTML-ish
Pierre: One option, if we decide tts:font-variant isn't great because of it's mapping to CSS font-variant, we could redefine the mapping to something else
… tts:font-variant was introduced to support superscript and subscript
Nigel: The CSS font-variant selects glyphs but doesn't change their position, but if you want to change the alignment then you should use vertical-align
… Sounds not ideal to have a TTML style property that does something different to the CSS style of the same name
Pierre: I agree, but not sure why we went with that at the time
Nigel: A possibility could be to use a font explicitly defined to include glyphs with super/sub font variant forms
Pierre: Potential next steps: confirm it's a real issue, think about how to fix
Nigel: Yes, and by "real issue" do you mean that there's no workaround?
Pierre: Yes, but also if there are subtitle guidelines to discourage use of super/subscript
… The fact it's in CEA708 gives us a good reason to support it
Nigel: Do you have any input on the accessibility of super/subscript text?
Pierre: Yes, the people in France were wondering why they couldn't do it, probably following a guideline for PNG based subtitles
… My sense is they're incentivised to help. Maybe give some time, to after IBC, then think about how to fix?
Nigel: Could be a topic for TPAC as well, need to think about things that affect TTML and IMSC together
Nigel: Any other thoughts on this?
Cyril: I'm enquiring internally on the importance, so will update you
Nigel: I don't expect BBC to have any data points
… I could ask the EBU media access technology group. If you're a member, you could ask on their reflector
… It's a good forum for input on non-English European languages
Pierre: I can ask there, possibly also on social media
Nigel: Thanks
SUMMARY: Investigation into requirements to continue, agenda+ for TPAC
TPAC 2024
Nigel: I created a wiki page for the TPAC agenda and logistics
… Please add yourself to the table if you'll be participating
… Goals for this year's TPAC:
… Move forward with DAPT, agree to publish CR
… Decide what to do with TTML2. It seems to be static, nobody actively editing. I want to be able to push it on. It could need another editor, to get it to Rec
… Joint meetings with MEIG and APA WG, seems vague
… Future topics
… I have a list of topics, but not mapped to specific timeslots
… Will we really have a MEIG/TTWG joint meeting, then on Friday another one: APA/TTWG/MEIG
… Talking with Chris, that seems to be the intent
cpn: They're different things. The Friday one was at the request of APA.
… The Monday one was to bring TT and MEIG together as we've done before.
… It's up to you what you would like the agenda for that session to be.
… If you don't need all of the time then more time for MEIG specific topics would be helpful.
… Depends on what you'd like to cover.
… The Friday session: I haven't had a response from APA about what they'd like to talk about.
… It's their request.
… There may be some MediaWG things I could bring, like specs that will need horizontal review, that
… we could introduce. At this stage I'm unclear as to what we want to use that time for.
Nigel: On the Monday meeting, we'd like to share current TTWG status, show the design and intent for DAPT, to circulate that more widely
… There are likely to be more MEIG people on the Monday than the Friday
… We also talked about raising captions in MSE
… I have talked with BBC colleagues, and they see a potential advantage in code simplicity and buffer management, even if the rendering is dealt with separately
… That's enough to justify the meeting on its own
… I'll write it into the agenda
Cyril: So if someone is only interested in TTWG, meetings are on Monday, Thursday, Friday?
Cyril: I'm considering being remote on Monday, then travelling for Friday. I could come on the Thursday if we need an editing session
Nigel: I think that would be helpful
… There's a joint meeting with Audio Description CG on Thursday morning
Nigel: I don't know what input we'll get from the AD CG, so could be an editing session
Meeting close
Nigel: Thanks all, we're a couple of minutes over. [adjourns meeting]