Meeting minutes
This Meeting
Nigel: Agenda for today:
… IMSC-HRM
… DAPT
… Discussion of potential need for font-variant: small-caps
… Any TPAC 2023 suggestions
… Is there any other business? Or items to make sure we cover within those topics?
… Quick intro to Matt
Matt_Simpson: You may remember me from Red Bee Media / Ericsson - I'm now at ITV doing a similar role
… and particularly interested in DAPT.
Cyril: Welcome!
Nigel: I've invited Matt as an observer today, from the formal meeting attendance perspective.
group: [brief introductions]
IMSC-HRM
Nigel: Reminder that I sent a Call for Consensus to transition to CR
CfC email for transition of IMSC-HRM to CR
Nigel: Runs until 2nd June.
… I've had a couple of messages of support.
… No signals against transitioning to CR.
Pull Request including CR Exit Criteria
Nigel: If you have any issues with the CR Exit Criteria please comment on the pull request.
… Encourage everyone to review them for themselves and in the context of the current TTWG Charter.
… Any questions or points on this?
Cyril: The CR pull request has links to GitHub issues - is this still okay at this stage?
… I thought the CR was supposed to be almost final.
Nigel: Even Recs have GitHub links
Pierre: One of those is because of an at-risk feature, where we were encouraged to use a GitHub issue.
… The other was something that we hope to answer conclusively during testing.
… We use GitHub as a way to track those, and were encouraged to do that.
… As opposed to doing it offline or in the implementation report.
Nigel: Atsushi says via IRC: we need to mark feature as at-risk, if any, but no need to resolve all issues, for CR
Cyril: That answers my question!
Pierre: My plan is, as soon as the CfC concludes, hopefully positively, I'll put together test content,
… and a call for tests, and I will update the sample web app that's based on the open source code,
… to match the CR.
Nigel: We don't have a test suite now, just an empty repo.
Pierre: Correct. I wanted to wait until confirmation that we would progress before working on that.
Nigel: Any more on IMSC-HRM?
no
DAPT
Nigel: We've been merging PRs in the normal way.
… In our last Editor's meeting we marked some issues as needing to be resolved before CR.
… Any open PRs now?
Cyril: Yes, yours
Nigel: Oh yes, completely editorial, needs a review.
Cyril: I will check it.
Nigel: On the list of steps, we can confirm that we have auto-publication to WD on merging PRs to main branch.
… It's happened several times!
… Thank you Atsushi for making that work.
… I have not yet requested HR or WR from liaisons.
… I opened a tracking issue for us for that
Prepare for Horizontal Review w3c/dapt#144
Nigel: One obvious target for a liaison would be EBU, and I did present the DAPT spec to EBU in a remote meeting.
… That presentation generated some useful feedback which I have added to issues where needed.
… The main thing is tracking of work in progress as well as completed deliverables.
… In other words, support for organisation making DAPT documents, during their preparation
Mike: Should we send to ATSC and CTA too?
Nigel: We have a list of liaisons, and we can send to others even if not on that list.
Mike: The discussion of audio description has warmed up so it might be helpful to share with them.
Nigel: Thanks, I will.
… If I need any contacts perhaps I'll ask you Mike.
Matt_Simpson: I think this is a very useful thing to have, both from audio description to move away from
… proprietary formats, and also for use as structured scripts for other use cases.
… I've wanted to move away from PDFs and Word documents for inbound script data for a while.
Nigel: I received more positive feedback from someone else in EBU too.
Cyril: Can we look at #52 since Matt is here.
Nigel: Just to note, on IRC Atsushi mentioned that we can request transition to CR even before all HR GitHub tracking issues are closed.
… Worth noting, especially in the context of IMSC-HRM where there's one i18n issue still open I believe.
Collaborative editing or partial editing - do we need "unfinished" state? w3c/dapt#52
github: w3c/
Cyril: This issue is about possibly tracking state changes into a document.
… Thank you Matt for commenting on it.
… I'm asking myself and my colleagues if there is a need for interoperability in tracking changes
… while editing?
… I'm not sure for example if we would go between authoring tools where interop is needed to signal unfinished editing.
… The other thing is: possibly it could be done externally to the document, in a version control system
… or asset management system.
… At Netflix the need we identified is to see what delivery it refers to.
… For example if a script is received, the original media changes and you need to get another one.
… It's about tracking multiple finished documents pointing to different related media objects.
… We added some text about identifying related media objects recently.
… You could use that, as well as additional proprietary data in other namespaces.
… I'm looking for use cases where interop is needed between tools for fine-grained change tracking.
Matt_Simpson: Quite often we will be asked to reversion or modify a subtitle or caption file based on the results
… of compliance edits or a localisation process.
… It's very useful for the translators, captioners, subtitlers, to be driven to the changed elements rather
… than working out for themselves where the differences in the media are.
… It can be as simple as an edit to remove a section, or replacement of expletives, or some other editorial change.
… I agree, we could do it as an external diff process.
… From our point of view there is value in it travelling within the document.
… It does not need to be particularly complex.
… I can see arguments against keeping multiple versions in one file.
… But just indicating what had been edited most recently would be useful.
… We get around this now by exporting Edit Decision Lists and pointing humans to the changed timecodes.
… Does that help?
Cyril: Yes, it helps, it's very similar when you mention ETL. My colleagues are using OpentimelineIO to do the same thing.
… I still wonder how we identify the latest edits in the document.
… Have an iteration number on each script event, and increment all the touched events every time you edit?
… I would need to see a proposal. I'm not opposed.
… What Nigel suggested initially, to use ScriptType at event level, I don't think it covers your use case.
Matt_Simpson: No, for me it's almost like a "dirty" flag - what has not been seen before in this file.
Cyril: How would you track deletions then?
Matt_Simpson: True, that's equally valid.
Andreas: Question to Matt - is this particular for DAPT, or for other TTML documents?
Matt_Simpson: It would count for other TTML documents, but workflow-wise if we were to use DAPT as an
… inbound script and we have multiple versions sent to us, it would be useful to know what is different,
… i.e. the intention of the edit.
Cyril: I agree with that. The current thinking is to carry top-level metadata in the form of a change log,
… but not with a fine-grained approach.
Matt_Simpson: If we want to save human time, we would want to direct the person to the changed part rather
… then having them hunt for it.
… A DAPT document could be the input to a process, where an IMSC document might be the output,
… from a lifecycle point of view.
Cyril: My suggestion is to continue the conversation offline with examples. Do others share the same use case?
… Is this a v1 thing or can it be deferred for now? There are options.
SUMMARY: Continue discussing offline
AD embedding issues
Cyril: We're looking for feedback about the multiple ways to do the same thing with managing
… audio recordings - embedding, referencing, etc.
Nigel: Yes, there are lots of issues embedded in the document.
Cyril: It's #113, #114, #115 and #116 if people want to look at them.
Nigel: In general when we ask "do we need all the ways TTML2 has to offer" the answer is "probably not"
… but I need to have some guidance to help select the best options here in this case.
Discussion: Any requirement to support tts:fontVariant in IMSC, and allow all-small-caps?
Nigel: I was recently re-examining the FCC caption customisation requirements and saw that one of the
… options for font appearance is curiously different from all the others!
… There's a requirement there for all small capitals.
… In the past when we've discussed this I think we concluded that the requirement could be met
… by providing a specially designed font.
… I'm sure that's true, but there's a much easier way nowadays.
… That's to use the CSS font-variant property, specifically the one that allows all-small-caps,
… and that will cause a conformant user agent to choose the small capitals glyph variants in whatever
… font is chosen.
… It's simpler for the implementer because they don't need a special font, and it means that in principle
… the user can choose orthogonally the font face, e.g. serif, sans-serif etc. and whether to use all caps or not.
… Current state is TTML2 does not support this property value in tts:fontVariant,
… and IMSC does not support tts:fontVariant at all.
… I wanted to raise this in case others have also hit this curious requirement.
Pierre: First time I've heard about it.
Mike: The FCC suggests it be a separate font, and the font it uses as an example is all caps of course,
… but the capitalised letters are actually larger.
… I don't know if you get the same result with the CSS property.
… It might be a clever way to address it.
… I'm not aware of anyone who has actually implemented this, independently of TTML.
… Not sure where the best balance of energy is spent.
… If you use Engravers Gothic then it has an example.
… I'm not opposed, but concerned about putting a lot of energy into a little used feature.
MDN CSS font-variant-caps page
Nigel: Thanks for the link there Pierre. That's great - it shows that the `small-caps` value does indeed
… present actual capital letters larger than lower case letters, which are also capitalised.
… I'm not sure if this is allowed in WebVTT - I assume not?
Gary: I'll check
… ... It doesn't have it, no.
Nigel: This strikes me as a great use case for the new Process that allows us to add delta features
… without the full review cycle of entire specifications.
Mike: Could be worth discussing with CTA too, to get manufacturer's views.
Nigel: That would be useful, yes, thank you.
Matt_Simpson: Using all capitals goes against most accessibility guidance - it makes text harder to read
Mike: Is there a link to where it says that?
Matt_Simpson: I can share that later.
Mike: That'd be helpful, thanks.
Nigel: Of course the property is not needed in the captions document itself - as a customisation implementation,
… it can be applied to the render area container and gets inherited.
… Summary for this topic today is that more input is needed.
TPAC 2023 planning.
Nigel: Any thoughts of agenda topics for TPAC? This is a placeholder agenda item.
group: none so far
Meeting close
Nigel: We've concluded our agenda, let's adjourn. Thank you everyone. [adjourns meeting]