{Minutes} TTWG Meeting 2024-08-29

Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2024/08/29-tt-minutes.html


ALL: Please review the schedule for TPAC, add your name to the TTWG TPAC 2024 wiki page<https://www.w3.org/wiki/TimedText/tpac2024> if you are attending, and let me know if you have any requests for agenda topics, or timing constraints regarding agenda topics.

Those minutes in plain text:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

29 August 2024

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2024/08/15-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/289

      [4] https://www.w3.org/2024/08/29-tt-irc


Attendees

   Present
          Chris_Needham, Cyril, Matt, Nigel, Pierre

   Regrets
          Gary

   Chair
          Nigel

   Scribe
          nigel_, cpn

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Add section about mapping from TTML to the DAPT
            data model w3c/dapt#216
         2. [8]Issues review
    3. [9]IMSC
         1. [10]Superscript/subscript support w3c/imsc#583
    4. [11]TPAC 2024
    5. [12]Meeting close

Meeting minutes

  This meeting

   Nigel: DAPT, IMSC, and TPAC. Anything else?

   (nothing)

  DAPT

    Add section about mapping from TTML to the DAPT data model
    [13]w3c/dapt#216

     [13] https://github.com/w3c/dapt/issues/216


   github: [14]w3c/dapt#216

     [14] https://github.com/w3c/dapt/pull/216


   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 [15]w3c/imsc#583

     [15] https://github.com/w3c/imsc/issues/583


   github: [16]w3c/imsc#583

     [16] https://github.com/w3c/imsc/issues/583


   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

   [17]TTWG TPAC wiki page

     [17] https://www.w3.org/wiki/TimedText/tpac2024


   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]


    Minutes manually created (not a transcript), formatted by
    [18]scribe.perl version 229 (Thu Jul 25 08:38:54 2024 UTC).

     [18] https://w3c.github.io/scribe2/scribedoc.html