See also: IRC log
<nigel> scribe: nigel
Nigel: Do we all know each other?
group: [almost all have met before, if only for dinner last night]
Thierry: I'm team contact for the group
Nigel: Overall goals of the
meeting
... First draft for TT future requirements
... First draft Charter Revision for TTWG
... Since then we also want to understand the situation re
WebVTT as well.
... [iterates through agenda]
... How does that look?
Glenn: I'd like a small
discussion before we go through requirements to come up with
categories for
... assigning requirements to documents. Part of that hinges on
what our thoughts are re TTML2 or TTML3.
... We don't have a record of discussion of our guidelines for
targeting TTML2 vs TTML3.
... And for IMSC we probably need some idea of what we are
targeting, a 1.2 or what.
... I think it might be useful so when we go through the
requirements we can refine with labels.
... I've been trying to go through those issues and assign
labels where appropriate.
... I think it would be useful before we go through the
requirements.
Andreas: Two ways to approach -
what Glenn said, or what Nigel proposed to go through
requirements
... first and then go through the documents. I prefer what
Nigel proposed. I think it makes sense to go
... through the requirements and see for each one which
documents they go in. I would start as soon as
... possible with the requirements.
Glenn: It might require a second
pass through the requirements after we make decisions
about
... document targets. I'm not opposed to that approach.
Nigel: We should make sure we
think about documents to target for each requirement we want to
meet.
... We can label at the time or later after the notes.
Glenn: That's okay but we need to
have some thought about which features can go into TTML2 2nd
Ed
... vs TTML3. In my mind substantive new features need to go
into TTML3 whereas substantive or
... editorial clarifications can go into TTML2 2nd Ed.
... Yes with the proviso that there may be a grey area, if we
forget we need to add a keyword value
... for an existing property, or a feature designator. Those
could potentially be in TTML2 2nd Ed.
... New properties or elements are clearer.
Nigel: Also we could consider TTML2.1 for new features.
Glenn: I'd oppose that because we
decided in the past not to use dot releases in TTML. It would
either be
... 2nd edition or TTML3, not TTML2.1
Nigel: What about IMSC, are we looking at new features going in IMSC 1.2?
Pierre: Depends what they are and on the impact on conformance.
Nigel: Everyone happy with how we target version numbers for TTML?
Andreas: Yes, I think we need to
see as we go through.
... The important thing is we decide to publish by the end of
the year.
Glenn: That's also my goal, I'd
like to get to Rec on TTML2 2nd Ed by the end of the year but
also on
... TTML3 which would depend on implementation activity and may
slip later.
... Some of these new features are out of my expertise so we
would depend on implementers.
Nigel: As always!
Glenn: Yes, and testing also.
Nigel: I would rather defer features and publish on time than let it slip.
Glenn: I would like to get to FPWD by June 1, and hope to go direct to PR.
Nigel: That reminds me Thierry was going to draft a sketch timetable for getting to publication.
Thierry: Yes I will do that, based on FPWD on 1st June.
Glenn: Modularisation might
change that, we need to discuss that.
... It's a huge amount of editing work so the editors will bear
the brunt of that.
Thierry: For my schedule, if
there are no substantive features then it is straightforward
because it does
... not change the implementation report. It could be fast
tracked.
Glenn: Both documents will have substantive changes.
Nigel: Any more questions about today?
Andreas: Our goal for the TTWG
Reqs is to decide for all of them if they will be in the next
TTML or IMSC
... publications, today?
Nigel: Yes, I think so.
Andreas: Just to make sure we get
through all of them!
... And the target is not to find a solution for the
requirement, just to support the requirement itself?
Nigel: I think if we have no idea
how to meet the requirement then we probably won't be able to
do it,
... so we should have at least some idea of what the solution
might look like.
Gary: [Shares screen]
# WebVTT implementation report starter
Gary: I used WPT as a basis.
Unfortunately some of the tests require human eyeballs and
can't be automated
... so they're not showing in here.
... Some of the tests are grouped by feature, where multiple
tests together make up a feature rather than
... each test being a feature in itself.
... This is partly because of the way WebVTT is written.
... For example a Cue includes multiple features.
... It's doable but not really clear cut.
Andreas: I think from the WebVTT
spec there are parts you can categorise like the Cue
settings.
... It might make sense to do that, and then check each
value.
... Also for pseudo-selectors and all the CSS features that are
supported, like color etc.
Gary: For the CSS stuff there is
a bunch of different ways of selecting parts of a cue, so there
are like
... 20 different tests for each one. Five tests for how text
wrapping is handled. It's not necessarily a 1:1
... correspondence.
Andreas: Would you also test that color is rendered correctly for example?
Gary: Yes. There are three color
tests, for hex, hsla and rgb.
... Some of the cue functions are not supported. They may be
relatively new additions which is why they
... are not supported. It is often the case that newer things
are less supported.
Glenn: On the spreadsheet the first line says "VTTCue Align" - is that testing the align property?
Gary: That's a folder name, which contains the two tests underneath it.
Glenn: I don't see any align property testing there, so it's confusing. Is the align property tested?
Gary: I think it is in there. The "align" one is the top one.
Glenn: You might want to change the naming to make it clearer.
Gary: yes, I'm looking at the
second tab for rendering tests.
... There are Pass and Fails and some ?s where we don't
know.
... The ?/F are likely to fail but I'm not sure yet.
... The ?/P are likely to pass I think.
... There are some changes to the spec since the FPWD and they
seem to be involved with those I'm
... not sure about. One of the things we may need to do is
update the tests for those things.
Silvia: It's a limited set, not a huge list.
Gary: Regions are one of the areas that needs work.
Glenn: I see most of the entries are blank there.
Gary: Yes, Firefox preview does
some strange things with defaults.
... VLC does better but I'm not sure.
Silvia: I think VLC might implement correctly but the tests need to be updated.
Glenn: What is the strategy for all-fail tests? Will you take out features from the spec?
Gary: I feel like it might be
better to remove features that have no support and then work on
the next
... version to add them back.
Glenn: Another strategy is to remove the tests.
group: [laughter]
Glenn: There's nothing that defines what is tested. The WG can define what tests are used.
Andreas: I'm not sure if this was
a serious proposal. If we have important features we should
test them.
... The process is there for a reason to give some fidelity for
implementers to show that there are
... implementations out there. This spreadsheet is really
great. To remove tests that fail and then push the
... specs through containing those features that we know are
not implemented correctly does not make sense.
Glenn: For a given feature, which
I understand are not enumerated, what tests are mandatory to
call it
... a tested feature is not determined. If there's at least one
test for a feature we can claim the feature
... was tested. Some of us might claim the tests were
inadequate, and they might be right. Process-wise,
... this is in the realm of the possible.
Nigel: I recall a couple of years
ago David stated the group did not want to remove features, and
I think
... that was partly for things like regions where there seems
to be an FCC requirement for them.
Gary: We need some way to move forward.
Silvia: It's a bit of a chicken
and egg thing, persuading implementers to implement. Some
implementers
... wait for Rec before going ahead.
... In the case of regions there are implementations but not
interoperable ones, or they have bugs.
... So we could take the feature out for the time being.
Pierre: Or wait for the bug to be fixed.
Gary: Because of the lack of uptake and implementation we may need to do something else.
Matt: We use VTT as a lowest
common denominator because of the lack of support for any
detailed
... features beyond text and time. If there is serious work to
address the implementation gaps it would be
... worth publicising that.
Andreas: Silvia said possibly
some potential implementing parties like browsers might wait
for spec
... stability before implementing. This would possibly be a
reason for publishing not fully implemented
... features. I see that WebVTT has been published for a long
time. The strategy was always to have a living
... spec that tracks the implementations. I see that elsewhere.
They are often fully implemented before CR.
... It is just an overhead to go further. Therefore I think it
is possibly wise what Gary said, to look at what
... we have, see if there are quick fixes, take features out to
get to publication, and if there is interest and
... expectation for new features, put them in the next
version.
Silvia: Maybe it makes sense if
we expect those features to evolve and change.
... The region spec particularly has evolved a lot. We have a
pole in the sand now for what we want to
... implement, and scrambling (slowly) to do that. The way I
look at this spec is we are putting a pole in the
... sand for the FCC required regulatory features. We went
through a rigorous process to get to here.
... Nigel has been helpful and everyone else in the WG in
making the spec better.
... I don't foresee any of the existing features making any
changes. The next step would be adding
... functionality that isn't there. It would make sense to take
everything there to Rec. We haven't
... finished checking if we have interoperability, with the JS
libraries, VLC etc.
Pierre: I don't understand what
you're proposing. It cannot be published if we haven't
demonstrated
... interop by at least 2 implementations.
Nigel: It has to meet the CR exit criteria.
Glenn: I'm not so sure, I think
publish as is to draw the line in the sand. If you roll back
the test coverage
... to get minimal testing of features I see that as a good
option for moving forward even if some people
... don't like that. It's been extremely painful to get this
far. It will be a lot of editorial work to haul out
... features. Also on Microsoft since they're switching to
chrome basically that takes one implementation
... off the table and you end up with Chrome and Mozilla as the
implementation paths.
... Is there an option to pass tests by polyfill?
Pierre: Why are we doing this? To demonstrate interop, right. This is at CR already, it's already published.
Andreas: I would support what Pierre said. It's not a problem to publish for stability.
Thierry: CR is a call for implementations.
Andreas: Exactly that. If this does not happen then it stays in CR.
Thierry: I'd like to focus on the
WG task here. It's not up to the WG to decide on moving to PR,
That's
... the Director's decision. Our task is to motivate why
features are not passing tests and make the case
... to the Director who will decide if it passes the exit
criteria and decide whether to move to PR.
... The second thing, about removing features, could be very
time consuming and also delay the spec a
... lot. If we move things out we need to publish a new CR with
at risk features listed. The current doc
... says there are no at risk features.
... A new CR doesn't take a long time. But then there will be a
lot of work for re-editing the spec,
... removing the feature, and we don't know the impact of that,
which is not an easy task either.
... The last thing is currently the Charter expires in 14
months from now and WebVTT is mentioned in
... that Charter. If we don't touch it we could wait for a
year, but if we do a new Charter then we have
... to convince the Project Lead, Philippe le Hégaret, to
include WebVTT in the new Charter.
... We have to remove features, or make the case for moving to
PR, or add to a new Charter.
Nigel: David already established
we have consensus to stop work on WebVTT if we can't move it
forward.
... I think the easiest path forward is to complete the
implementation report.
Silvia: How long do we have?
Thierry: In this scenario we're in, about a month.
Silvia: I'm concerned we might not have time to do it.
Gary: I have not tested VLC yet, or the polyfills.
Thierry: To make life easier, why
don't you focus on the features not implemented in other
browsers,
... those where you don't have enough implementations yet.
Gary: yes that makes sense
Thierry: That focuses to 20-30 tests.
Gary: Additionally some tests can
be fixed in vttJS and I planned to open issues on chrome and
Firefox.
... Some tests also need fixing.
Silvia: videoJS and JWPlayer have implementations to test too.
Gary: They both use vtt.js
Silvia: Ok
Thierry: You only need to test feature by feature.
Glenn: One small point. I heard
Thierry say we could crank out another CR quickly adding only
at risk
... features. That would provide a path for moving to PR
without requiring another CR if you were to
... remove those features. A change only to the status section
wouldn't require a new WD.
Thierry: That's right.
... It's a possibility but doesn't answer the question.
Nigel: We've only got one Gary,
so I think it makes sense to prioritise the implementation
report.
... We don't even know which features to list as at risk!
Silvia: Gary do you think we can have a full report by the end of February?
Gary: Yes I think I can make the case for that.
Silvia: Some features have
multiple tests so it would make sense to group them, and
collapse some tests
... together. I think I heard before that if there are multiple
tests they don't all need to pass.
Nigel: All the tests in the
report need to have at least two passing implementations.
... The goal is to demonstrate implementability not
interoperability.
Pierre: What we're trying to do
is make sure the spec is implementable, so if the spec is clear
and you get
... different results then there's something wrong there.
Thierry: The Director is not
going to check if all the features in the spec are tested. It's
up to the WG to
... decide if we are covering the features. If we have corner
case tests then it's our decision to remove it.
Pierre: Or if the spec is ambiguous, worse.
Andreas: It's important that the
WG understands this process. I think it makes sense what is
proposed
... to go through and structure the tests as Silvia said, and
check against other implementations, and then
... decide on it. In general if a feature has not enough
implementations that could be feedback for the spec.
... If we have the results then we can decide how to judge.
Thierry: In some cases we need to
understand why the test is failing. It could be a bug, or an
unclear spec
... where implementers disagree on the correct result. That is
very different from lack of implementation.
... Two different results based on different understandings
should be a red flag.
Nigel: We're running to the end
of this agenda topic. I think we have consensus to move ahead
by
... completing the implementation report over the next
month.
Thierry: Specifically to check
non-passing features against other implementations like
VLC.
... I would like to thank Gary for taking this on.
Gary: Thank you. The third task is that a couple of tests may need to be updated.
Silvia: That's true.
... I would start there if I was you, so you can run those
tests.
... Thanks everyone, I'm going to go.
... [leaves]
Nigel: Let's take a break for 5 minutes.
The first one is issue 1:
github: https://github.com/w3c/tt-reqs/issues/1
Nigel: Is there any more detail we can add to this now?
Glenn: No, not that I know of,
unless we want to go through the 73 issues.
... I need to start processing them right away.
... Quite a few of them are small, some were pushed forward
that may not be so small that I need to
... start on.
Andreas: Do we take it as a given that we solve them all?
Glenn: As many as possible. If we have favourite ones then ping me.
Pierre: Timetable?
Glenn: June 1 for FPWD of 2nd Ed.
Pierre: One meta-issue is setting limits on values.
Glenn: Implementation limits?
Pierre: Maximum number limits like on seconds.
Glenn: We have some in the spec
already, from TTML1 1st Ed.
... We haven't really pushed specifying limits. I think feature
definitions would be the best place.
... For example something that says how many colors are
supported.
Pierre: Right, a specific example is number of seconds.
Glenn: We haven't said anything about that.
Pierre: 32-bit or 64-bit. That's a ton of work, so we need to decide on that.
Andreas: Does it cause problems?
Pierre: It has caused problems,
because someone had used media time origin as 1970 and that
blew
... up an implementation which didn't allocate enough bits to
the number of seconds.
Nigel: We do that sometimes!
Pierre: It turned into a more complex problem than at first it appeared.
Glenn: We don't have an issue on this, do we?
Pierre: Maybe on TTML1. It could be a feature designator for minimal support, say.
Nigel: Sounds like a good idea to me.
Glenn: We couldn't retro-actively
apply it to TTML1. The ship has sailed.
... They would be in the range of a semantic restriction of an
existing feature.
Pierre: We can introduce new features.
Nigel: Yes we can.
... Take it further - if a processor feature says 32-bit number
of seconds then does that invalidate content
... with time expressions that could go beyond 32-bit
numbers?
Pierre: We began to touch on this in the TTML1 issue.
Glenn: Say we define a limits
feature and define a 32-bit one. Absent such a feature in the
processor
... profile it would effectively be undefined.
... Then in a content profile I don't know what it means.
Constrain maximum value of @length on data element. ttml2#1023
Least upper bound on supported time expression values. ttml1#307
Pierre: what's the view on this?
Nigel: I want to know more about the implementer pain levels
Pierre: We know at least about time expressions causing pain.
Andreas: I would support doing it for time expressions
Nigel: We can ask others of
course. For example I can imagine DVB implementers wanting to
know this
... detali.
... Coming back to the macro requirement, are all the
substantive issues for 2nd Ed?
Glenn: We haven't created a TTML3 repo yet.
Pierre: There are a couple tagged for TTML.next and 2nd Ed milestone but don't belong in 2nd Ed.
Glenn: Can we get a new repo for TTML3?
Nigel: Yes I don't see why not if that's how you want to do it.
Nigel: I've assigned that to Thierry
Glenn: I need to triage these. Most of the ttml.next ones need to get pushed to TTML3.
Pierre: Can you do this now so we
can go over them this afternoon. It would be awesome if we can
get
... get a good idea of it today.
Glenn: I didn't come prepared for that.
Andreas: If nobody has missed a feature and filed it then it may not be a candidate for TTML3
Glenn: I don't understand
Andreas: We opened requirements
up and if nobody raised requirements for missing features then
you
... could argue they are not in scope.
Pierre: We can't leave "resolve all issues in TTML2" open today
Glenn: That was a catch-all requirement.
Andreas: I agree with Pierre we
need to go through them today. 10 substantive features coming
in would
... change the whole picture.
Pierre: Can you make a first pass?
<tmichel> https://github.com/w3c/ttml3-tests and https://github.com/w3c/ttml3 created
Glenn: I can't do a first pass
today, I can go through it this evening and change
ttml.next
... to ttml3 where it's my first approximation and the group
can confirm it tomorrow.
... If I think there are things for 2nd ed then I'll mark that
too. It'll take me a couple of hours.
Pierre: The most important is to change the milestone.
Glenn: Once we have the TTML3 repo I need to transfer them to that repo.
Pierre: You can transfer issues on GitHub if you're an owner
Thierry: okay
Glenn: I promise not to make any other changes under the covers!
Nigel: Summarising, it is clear
which specs are being targeted. We don't have consensus yet on
which
... things to adopt, pending a more detailed review.
... For the substantive changes I want to get an idea of what
the test will look like.
Glenn: In a preliminary basis we
can describe at a high level the kind of things we need to see
tested.
... For example HDR images would require images with HDR coding
in them. That's a high level test.
<tmichel> ttml2 and ttml3 repos : added Glenn and Nigel as Admin.
Pierre: Can we change this specifically to TTML2 2nd Ed and constrain it to editorial features?
Glenn: We could add a ttml3 tag and include moving new features to ttml3.
Pierre: Just this one requirement.
Andreas: It makes sense to fix
bugs in 2nd Ed, we don't need a big discussion.
... All new features are new requirements so I expect them not
to be in TTML3. If there are important
... ones then they need to be submitted, but that period is
over.
Pierre: I totally agree.
group: [discussion of handling this requirement issue]
Glenn: I will change the issue title to Resolve open issues to TTML2 2nd Ed.
Pierre: thank you
SUMMARY: TTML3 issues to move to new repo, this issue to cover TTML2 2nd Ed changes only, @skynavga to triage issues.
Nigel: Given the agenda I think we can only scan through this now and will need to come back to it tomorrow.
Pierre: Do you see this as a core part of TTML3 or an add-on?
Nigel: Good question. I would
happily see this as a TTML3 module for dealing with sequences
of
... TTML documents arriving over time and define any additional
syntax and semantics that are needed.
Pierre: Then that can be adopted independently.
Glenn: Re modularisation, I would
make fine changes to enable new modules to be layered on top
of
... what is already there. There are issues like namespace,
conformance processing, the document
... processing module that can be tweaked to enable these
without making in-depth changes. That's
... my thinking. What I don't want to do is to think about
breaking off, say, styling, timing, animation etc
... and creating N new rec-track documents for each. That would
be nightmarish and not possible
... within the timeframe of this year. It would enable new
modules to be added on like this which would
... be a separate Rec track document.
... In regards to Charter we need to figure out if every module
is a separate Rec track document. I think
... the answer is Yes, if we take the CSS approach.
Pierre: I like that.
... If a module turns out to be universally used...
Glenn: We can bring that back in.
Nigel: I wouldn't though.
... If you have a Rec track document there's no advantage to
bringing it in.
Andreas: I propose a separate
module to allow live processing of TTML.
... At the time of publication it is a separate module which
still has the possiblity to merge later if there is a
need.
... Then for live use case I have a question about the profile
and the syntax.
... EBU-TT Live is a subset of TTML. I assume in the module you
would not publish a profile that subsets,
... just the additional vocabulary you need and a
profile.
... Then the question is where does it live, would you have a
separate profile of IMSC that includes the
... module.
Pierre: That makes sense. The
separate module relieves the pressure on TTML, and allows the
market
... to react to it.
Andreas: You need something to experiment with, the module itself is not enough.
Glenn: We need a modularisation
framework that enables features to be brought in.
... For example a convention that allows features to be
prefixed.
... We need to find a way to integrate and that's part of the
modularisation framework.
Pierre: Andreas, you're saying that if there's a module then IMSC still needs to be modified?
Andreas: Yes
Pierre: What if we don't know it is useful at the beginning?
Andreas: There's no
implementation of the complete set of TTML2. There is a need to
say what it is used
... together with, in practice.
Pierre: Sure, unless it is completely outside the scope of IMSC.
Andreas: The benefit to have it
now in W3C scope is to use it together with something
standardised by
... W3C which is IMSC. Otherwise the situation does not change
and we get to EBU-TT Live.
... In EBU-TT Live you have timebase clock supported for
example which is not in IMSC. I think it makes
... sense to discuss tomorrow if IMSC and this module can be
brought together.
Glenn: Right now we have two
namespaces, one for core and another for extensions. Each
module could
... define its own feature namespace URI and define minimum
requirements for integration into other
... profiles that use that module, and say for example that
profile foo needs to support minimal feature set.
... And in addition define new features for labelling the
module as a whole.
... That's part of what I was thinking about with the
framework.
Nigel: I have a concrete example
here which is a prototype of what Glenn describes, in the TTML
in RTP
... IETF proposal, where we will be adding a processor profile
that defines an extension feature describing
... how the times are handled.
Pierre: I have no objection to adopting this requirement especially if this is a separate module.
Glenn: It makes it easier if other Editors can take on modules.
Andreas: Tomorrow we can come
back to this but it now makes sense for EBU to contribute
EBU-TT Live
... as the basis for a new module. I think everything is
already written.
Nigel: I agree, there's editorial work needed, and probably we should write less than what is in EBU-TT Live.
Glenn: Presumably the existing
work is in an EBU namespace. I've objected to bringing into the
TTML core
... foreign namespaces but I won't to doing so in a
module.
... It would create a possible block to incorporating into the
core in the future.
Nigel: That's useful.
Glenn: It might make is easier and improve interoperability too.
Nigel: +1
Pierre: One last thing. Who is
going to be the Editor here, because I don't think we can
accept a requirement
... for which there is no resource.
Glenn: Good point.
... I see two decisions. One is to make it a module pending a
modularisation framework, and two is
... designating an editor, and it won't be me.
Nigel: It's up to the Chair to
designate Editors, and I am happy to designate myself as well
as anyone
... else who wants to additionally do it.
SUMMARY: Consensus at this stage to proceed with this requirement, as a new Rec track module to be Edited at least by @nigelmegitt.
Nigel: I think we need a Charter
addition here to allow us to define new Rec track documents as
part of
... a modularisation approach. Thierry will that likely be
okay?
Thierry: Yes.
... Do you want also to be able to define profiles as well as
modules? We can add that too.
Glenn: I view it as the base
module definitions will define features and then those can be
used by
... profiles as needed. The profiling system supports that.
SUMMARY: Add option for modules to the draft Charter
<github-bot> nigel, Sorry, I don't understand that command. Try 'help'.
github: https://github.com/w3c/tt-reqs/issues/4
Nigel: This is for a Rec track profile of TTML2 (or TTML2 2nd Ed) based on the existing work in the AD CG.
Andreas: So the idea is first to
publish a new document which would be a profile like IMSC is a
profile,
... and to make any additions or tweaks in TTML to make it
fully compatible.
Nigel: Yes
Glenn: Another Rec track document basically?
Nigel: Yes
Glenn: Is there a designated Editor?
Andreas: Are we deciding now on the changes to TTML2 or just on this document.
Nigel: I'm not sure if there are
any tweaks now, it may be that we want only to adjust the range
of values
... that, say, tta:gain takes.
Pierre: That complicates things significantly.
Nigel: I don't think so.
Glenn: It pushes it to TTML3. We
can make cases for adding values if it was left out by mistake
and
... clearly needed to support the functionality that was
implied.
Nigel: I don't think so, this is
a mistake I think, where the range of tta:gain was discussed
but what went
... in the spec was a smaller range.
Glenn: That's in a grey area, it sounds like it could be fixed in 2nd Ed.
Andreas: I added to the issue the
f2f meeting of the AD CG because there were a lot of
interesting ideas.
... I'm not sure how much they would be in scope for the
proposed document.
... For example having more on the required processor
behaviour.
... It's clearly not in TTML2 yet so the question is if you see
this in scope for this new rec track document
... and if it would be more a new module than a new
profile.
Glenn: It sounds like there may be more impact than just one document here.
Nigel: Yes I think so. The
semantics are informatively described in TTML2 so we could
either make them
... normative and more detailed in TTML2 2nd Ed or make them
normative in the profile.
Andreas: It would be good to get
a harmonised approach with browser manufacturers so they
could
... implement the same or a similar concept.
... Also something not in TTML2 is that a processor needs to
pause the video if there is not enough time
... for the descriptions.
Nigel: That's a good point.
Andreas: I want to check that this is in scope of the work.
Nigel: Yes the profile could say
something about playback behaviour, which is beyond the scope
of TTML.
... In terms of the Editor question, at the moment John Birch
is editor in the CG, and I can ask if he is able
... to continue that here - he is a member of TTWG. I'd like to
make myself an editor but am worried about
... the effort needed to do it, and chair, and look after the
live subtitle work.
... We do have an editing opportunity here for anyone who wants
to take it on, I think.
Pierre: It sounds like we don't have a commitment at this point?
Nigel: At the moment John is
editor of that profile.
... There was a stated intention in the CG to move this to the
TTWG so that won't be a surprise.
Pierre: Great.
PROPOSAL: Accept this requirement for TTWG work in 2019 and add to the 2019 Charter.
Nigel: Any questions or comments before I finalise that?
RESOLUTION: Accept this requirement for TTWG work in 2019 and add to the 2019 Charter.
Nigel: I've moved the milestone on this issue also.
github: https://github.com/w3c/tt-reqs/issues/11
Andreas: This has been
contributed by someone who works in the field of
subtitles.
... We have to ask if it is already solved, and if there is
already some syntax or mechanics, is it appropriate
... and user friendly enough to be used for the requested
feature.
Glenn: I asked the original
commenter two weeks ago for further input asking if they
believe there is
... something not accommodated by TTML2. I haven't heard
anything back since Dec 20 it looks like.
... My current assumption is there is no technical feature
being asked for, possible a desire to support
... in IMSC. I think we can close this issue. We can reopen it
if the commenter comes back.
Nigel: I see there's no response
from the commenter. I also observe that there is an overlap
here between
... this, the karaoke and the CSS extensions requirements, so
it may be that we meet the requirement
... by reference to one of those others. If it is needed I
think it would be needed in IMSC also.
... It is not obvious to me how this can be done in a user
friendly way at the moment.
Andreas: Glenn said that he asked
Pablo Romero Fresco if he agrees that TTML2 already meets
the
... requirements or if he objects. As he did not respond then
he would like to close the issue. I encouraged
... Pablo to file this issue because he has the requirement and
he is not familiar with TTML2. I also saw
... some value in what he requested. I also said to him that if
he's not familiar with the technology then
... I would help out which I'm happy to do.
... First I also support this requirement and would not like to
close it.
... The important thing for now is to say this requirement
should be met by TTML or IMSC.
... I would support that. Until we have not proven that it
could be met by existing vocabulary then it
... should not be closed. I agree with Nigel that the current
spec text does not satisfy it completely,
... especially in a user friendly way.
... How this is done is a separate issue. I can imagine some
dedicated vocabulary like fadeIn or fadeOut.
... Most important is to bring this into scope, for now I would
leave it open.
Pierre: Did you see the example that Glenn provided?
Andreas: Yes
Pierre: Is that too complicated?
Andreas: Pablo asked for key frames and control over the speed so I'm not sure if this is enough.
Glenn: We have spline and
keyframe and interpolation modes. All that is being asked for
is present.
... User friendliness is not a criteria that we have applied to
any of this technology up to now.
... For me this needs a champion within our group, who would be
responsible for determining the answer.
Andreas: I will champion this.
Glenn: I probably would not be
inclined to support new shorthand properties for this but you
could make
... the case that it is some higher level thing that could be
translated into TTML syntax.
... I don't mind leaving it open if there's a champion.
Andreas: I am happy to do it. I
think you're right that we need a balance for user
friendliness, and we may
... not need to add anything new. User friendliness does indeed
play a role in TTML, otherwise there would
... not be different syntaxes for, say, color, but this could
be delegated to another time.
... We first see if technically it meets the requirements.
Glenn: There is a principle at
stake called Maximum Orthogonality which we have applied as a
strategy
... in TTML which says one should not define alternative ways
to do the same thing.
Andreas: But we do.
... One addition: I think the request is also to have this
feature in a used profile of TTML and the only
... one I know is IMSC, so there would be a request to add it
there.
Glenn: On this particular issue
there was some back and forth on labelling, I guess we can
leave this
... open for the time being if you are going to take it forward
Andreas.
Andreas: Yes, there's no real policy on labelling so it does not represent a decision and I'm fine with any labels.
Glenn: I didn't have an objection to Nigel's change here so I didn't make any noise on this issue.
Pierre: In terms of the requirement is it on IMSC to support this at the end of the day?
Andreas: Yes
Pierre: The challenge I have is
who will make the implementation effort to make it
happen?
... Is the one interested party the tip of the iceberg or is
that it?
Andreas: I heard it also from other directions. Although it may not be a super critical feature.
Pierre: I think we need those users to show up somehow.
Andreas: The question of how we
measure the weight of the feature - often it is sufficient if
one member
... presents the case.
Pierre: I haven't heard form Movielabs on this.
Glenn: I haven't heard from Netflix on this.
Nigel: There's an interaction
here with responsive, CSS, karaoke: essentially we need to be
able to specify
... or interpolate word timings and have some presentation
effects dependent on those.
... I think Cyril suggested time markers which could be
relevant too.
Glenn: Once upon a time we had a
different timing model in TTML presented by John Birch and that
took
... a lot of time, which in the end we had no implementations
for. What you're bringing up now is
... asking if we need some small amount of that. I'm open to
thinking about it again but it's a complicated
... area for sure. Writing in processing semantics for such
heuristics is not straightforward.
... In the context of karaoke I think we are going to run into
this again so I think we will have to bite the
... bullet and look at it.
Andreas: I hear what Pierre is
saying and that there needs to be sufficient support for new
features, so
... I would ask if other stakeholders would take it up, and if
they think it is needed. It needs a balance of
... workload in what we can achieve this year.
... I think that counts of course for every feature. I would
also look at the HTML group's process for how
... they consider new features for adoption.
Pierre: We have to have this input.
Glenn: Here's a link for dynamic flow
Pierre: What do we do before we have critical mass of interest?
Andreas: I would leave it open for now.
Pierre: The question is do we
schedule it for 2019? I would object to it unless we know there
are people
... who will be testing it, implementing it, paying for it.
<glenn> https://www.w3.org/TR/2010/CR-ttaf1-dfxp-20100223/#style-attribute-dynamicFlow
Pierre: In the case of IMSC we have checked it is really what industry wants to do.
Andreas: OK I will check that.
Nigel: We wanted to come to a
decision here but at the moment we don't have consensus to
proceed
... with it or to say no.
Andreas: What is the process if we do not have a consensus on a feature.
Nigel: I propose that we proceed
with this but note for ourselves that there is additional risk
associated
... with this feature, which can be mitigated by getting more
adoption or implementation input. Actually
... this risk applies to everything we do, but in this case it
has been flagged up early. If we don't get
... enough input on this then the default should be we defer it
until such time as we have enough.
Pierre: How long will it take Andreas to get additional feedback?
Andreas: End of March because I will be out of the office most of February.
Pierre: Can we make it earlier if there's strong interest?
Nigel: When we come back at the
end of today we will have looked at karaoke and other additions
and may
... have a change of view.
Pierre: Right now I think we
can't accept it. By the way I'm not questioning the
applicability, as this is used
... today in digital cinema.
Andreas: I think Nigel's compromise is a good one for now.
Pierre: I'm saying that one
person alone is not enough.
... If we can't get input on this until end of March let's not
schedule it for 2019.
Glenn: Some groups like CSS have
an implicit operating rule which is to say that if no browsers
implement
... then nobody will pay any attention to it. We should do
something similar with respect to the content
... community, and if we have insufficient interest then it is
not adequate.
Andreas: Whatever approach we
take it is quite similar, if we don't take it in now but take
it in later. It is the same thing.
... For me there is not a clear basis and transparent basis for
external people, when a feature has
... sufficient support and backup to be expected. We now
discuss it, so we do not have a clear statement,
... and until then we cannot just say now we need more.
Pierre: Ultimately it is the
consensus of the group, the AC and the Director that
counts.
... It could be that at the end of March this is a high
priority thing.
... I would rather say without closing it that we don't
schedule it in 2019 and revisit it when there's
... more input, which could be tomorrow, next week or at the
end of March.
Glenn: I want to remind everyone that new technical requirements need to be accompanied by test content.
Andreas: I'm not happy with this,
and maybe process-wise we need to deal with the case where we
do not
... have consensus. Does that mean it is out of the list?
Nigel: Consensus does mean no
objections, normally. Here I think the only objection is due to
lack of
... perceived interest, which could change. I mean, the BBC's
requirements include transition effects too.
... They're in the CSS requirement.
Andreas: I could take this if we
apply the same rule to everything else. I cannot accept
introducing new
... barriers now. We said that the requirements would be open
for a certain time but we didn't say more.
Glenn: The Chair is responsible
for determining whether we have consensus and also whether to
overrule
... an objection, and if he declares consensus in the presence
of an objection then there's an appeals process for that.
Nigel: That's correct in terms of
process. For this specific thing I think we need a checkpoint
later like
... FPWD where we know for certain if we have enough resource
and input, and if we don't then we defer it.
... There are at least 2, maybe 3 or 4 sources for this
requirement.
Glenn: This requires TTML3 for
significant features. We could easily put an example or a note
in TTML2 2nd Ed
... describing how to use animation features in for fade in or
fade out, giving us some place to point to
... for people who ask questions about it.
... I think I have somewhere an open issue that says "add more
animation examples" so I may already have
... an issue for that, in the 75 open issues.
Pierre: I don't agree putting this into IMSC in 2019 given the current level of backing today.
Glenn: I would support Pierre's position on this.
Pierre: I don't think it should be closed though, just not scheduled.
Nigel: Okay so we can still make progress and schedule it in for 2019 later if there is backing.
Pierre: I agree. There's huge testing effort but probably it is straightforward from a specification perspective.
Nigel: Andreas, can you live with that?
Andreas: Yes
SUMMARY: Not currently scheduled for 2019, pending additional input of resource to test and implement.
<glenn> testing
<inserted> scribe: nigel_
Nigel: There's been good debate
here. The function is in wide use especially in Europe, and we
have
... some support in TTML2 but not for IMSC.
... I think the gap is in signalling.
Matt: The use case is for blind or partially sighted people which would typically be subtitled not being
<inserted> scribe: nigel
Matt: able to read the
translation. Some broadcasters can transmit the text, say in
Dutch, for the box to
... present as an additional audio track, so a Dutch speaker
listening but unable to read the words on screen
... would have some audio representation of the text
translation of the English into Dutch.
Pierre: OK, so stupid question - you could solve with alternate audio channels.
Matt: Bandwidth limitations mean
its more efficient to deliver as text.
... The TTS is done client side usually. It's a very small user
group who needs this.
Pierre: Assuming the client gets a TTML track, the client could do TTS on the track without any change.
Matt: You need some markup to distinguish ordinary captions vs text to speech
Pierre: Like forced but for audio?
Matt: Exactly. If I did this in Teletext it would be a separate stream.
Glenn: The use cases describe TTS
of existing subtitles on the client side in companion
screen.
... That's done, check!
Nigel: No way, there are loads of
gaps there.
... If you'd tried to implement that you'd find them.
Glenn: Discount the companion
screen, that's out of scope.
... OCR is out of scope
... Screen reader is an application specific thing, out of
scope.
... 4th bullet is confusing because it talks about speech to
text, which doesn't make any sense.
... The last one is application level and out of scope.
... I conclude that we don't have anything to do here because
everything is out of scope.
Nigel: I don't agree on all of
those things, I think you've thrown them out of scope too
easily.
... Take TTS of existing subtitles, this is conditional and we
don't have any way to signal in the TTML
... which text needs conditionally to be spoken. Even if you
take out the semantic description, we still
... need a syntactic option.
... Screen readers are interesting because we don't provide any
guidance to implementers on how to make
... captions or subtitles available to screen readers, and I
think we should.
... I agree with the others though.
Gary: In videoJS we have
something related. The audio descriptions, the descriptions
kind for text tracks,
... and one of our accessibility people, when the audio
description is displayed on the screen we allow
... screen readers to read it, whereas by default we don't
allow screen readers to read captions.
... We allow people to have screen readers read out those
captions.
... And so a potential solution is instead of marking up
particular cues in the TTML file for reading aloud,
... have a direction to say that if something needs text to
speech, provide a separate file.
Pierre: That's the direction industry has taken for forced subtitles.
Gary: Then it would be a standard TTML file with appropriate labelling.
Andreas: The question is if the labelling should be in the TTML or outside.
Gary: Easier outside probably.
Pierre: For forced narrative many folk wanted it inside the TTML, the direction is to have separate files.
Nigel: I would take the opposite
view which is to support the player not processing multiple
files simultaneously,
... so in BBC we prefer the forced approach.
Glenn: You said a few minutes ago
there is no supported syntax but I disagree with that. We have
the
... extensible ttm:role and ttm:role and general
metadata.
... It is a huge mistake to start trying to push application
semantics into the core of TTML language and
... we should resist that every time it comes up. However if
there is a consensus in the content industry
... on particular metadata that helps with interoperability
then it would be reasonable to propose modules
... that define application specific metadata in that
regard.
... It would be a big mistake to put this into the core of the
language. We have to find a balance between
... standardisation and innovation on the part of the industry.
Some standardisation occurs by writing down
... existing practices and others on speculating on the
industry need. The latter fail so my guidance is
... extreme caution.
Andreas: First, maybe it makes
sense to separate it because if you have a TTML file and give
it to a client
... you usually give it to a rendering application for
subtitles which wouldn't do audio rendering.
... The other question to you Nigel is how you see the overlap
with the audio description module, because
... the target audience is the same and the goal is very
similar.
Nigel: Good point. I find it very difficult to distinguish this use case from audio description.
Matt: I 100% agree and struggle to understand what other than practice would change.
Pierre: Lots of systems do silly things like deployment issue.
Nigel: From a metadata
perspective, there's a gap there for driving presentation
behaviour because we
... don't do that with metadata. We may want to add a ttm:role
value for "translation" which is absent now.
... If we handle this as AD only then there's nothing to
do.
... If we handle it as interleaved, then the TTML2 condition
construct could be used based on an application
... parameter that says "play back translations", then a
conditionalised style that includes tta:speak to trigger
... TTS of that content.
Andreas: I would like to propose
that we transfer the main part of the request to the AD module
and see
... how it could be solved by that. There is certainly a
request to add a metadata feature to TTML2 to
... identify the relevant parts. We not only need so much scope
on the rendering part, it is possible to label
... on the production side and decide later how to render and
play out as audio. That could be the path
... for us. Outside our group it would be useful to have a
workflow overview that shows how to use TTML.
Glenn: The use of metadata to
affect presentation semantics - I agree we have avoided that
for core
... semantics but I don't draw the same line for application
level semantics, so I wanted to make the point
... that it may be appropriate to define metadata or additional
namespace qualified vocabulary not using
... our metadata at all. The question is if it is worth
standardising on it and if there is a community that
... can agree to a common set of meaning. That's where pushing
innovation is dangerous.
Nigel: There is signalling in HTML and DVB for example and this is in wide use, it's not just innovation.
Glenn: There is precedent with forced for writing application semantics into the condition system.
Pierre: I suggest we summarise
what we think the requirement is. We arrived at something a lot
more specific
... to summarise on the ticket.
... I didn't hear anyone say we should not do this, so I think
we should accept it and move on.
SUMMARY: We think the requirement here is to signal translations, and describe (potential) workflows for triggering TTS based on translations.
Glenn: I would like to confirm that speculation with the author of this issue.
Pierre: We should ask the commenter if they agree, that sounds good to me.
Nigel: I'm happy to do that.
SUMMARY: Check with @porero
... Flag timed text as a translation so that it can be used to
drive text to speech.
Pierre: On much modern content
there is both a caption file and a translation subtitle file,
the latter is
... 100% translation.
Matt: In that scenario the caption file would just be descriptions of sound effects. The two would interleave.
Pierre: In this definition, what's the difference, couldn't you just text to speech all the translation subtitles?
Gary: That's my question, do we want to limit to hard translations?
Matt: That goes back to Nigel's
comment about a player constraint on one TTML file being
active.
... In that case there needs to be a mechanism of identifying
what content needs to be spoken.
Glenn: We decided not to interleave languages in the same file.
Nigel: This is all same language though.
Glenn: For me it is an
application policy. If you're authoring in TTML you might use
different stages and
... merge them upstream or downstream.
... I don't agree to anything until I hear a better description
of the requirements.
Pierre: I think someone should write down what we think the requirements are and go back to the submitter.
Nigel: I'm happy to do that.
SUMMARY: @nigelmegitt to try to recast the requirements as per the TTWG discussion and check in with @porero.
github: https://github.com/w3c/tt-reqs/issues/14
Pierre: I'd like to narrow this
to 2nd Edition of IMSC 1.1 rather than a new edition.
... I don't think "review backlog" is a requirement.
... We can fix errors and apply editorial improvement, but
permitting embedded image is a brand
... new requirement that would potentially be IMSC 1.2 or IMSC
2, so on this one we should deal with
... editorial errors.
... That's #465 and #469 for example.
... Just like we said for TTML2 2nd Ed earlier.
Nigel: I just added #469 to the
issue.
... And removed #82.
... Shall we just say we'll do this?
Pierre: Yes I'm happy to schedule this for IMSC 1.1 2nd Ed
Nigel: Do we need to do it in IMSC 1.0.1 too?
Pierre: No we should not touch that now.
Nigel: OK
... Any other views on this? Do we have consensus to
proceed?
RESOLUTION: Proceed with this requirement in IMSC 1.1 2nd Ed.
github: https://github.com/w3c/tt-reqs/issues/2
Nigel: [summarises requirement]
Glenn: The title says "CSS
property" which I'm happy to see because it does not say "CSS
Selectors".
... I want to confirm here that the ask does not include CSS
selectors, which would make things enormously
... more complicated.
... I can see a straightforward path to supporting CSS
properties.
Nigel: What's that path?
Glenn: 1. Put it in a separate
module.
... Define a new attribute tts:cssStyle= and then a value space
that is a set of CSS properties, and define
... the semantics so that if both apply in some circumstance
then the TTML property... we'd have to
... establish a priority for when there's an intersection,
let's say tts:color and tts:cssStyle="color: XXX;".
... If a system did not support the CSS style mechanism then I
would presume that the TTML property applies.
... If it supports the CSS property applies then the CSS
property could be designated to win, but I'm open
... to it being the other way around. I don't have a strong
opinion on that.
... That would be the simplest path.
Andreas: That sounds like a
feasible approach. Two comments also on the thread. First, we
need to make
... sure that there's really a defined behaviour if you apply
CSS properties inside the TTML style and layout
... system so that there is a deterministic rendering
behaviour. That does not have to be true always because
... TTML does not rely on CSS but on XSL-FO. The second thing
is I would like our long term strategy
... to align TTML and CSS. We had discussions with CSS WG 2
years ago and we had agreement to bring
... it closer however it may look. The target was TTML3 at that
time.
... I think this first idea could be a transition phase. In
general it would be worthwhile to meet the CSS WG
... about this approach and in the long term plan consider how
CSS could be handled, if it could be a way
... to make timed HTML rather than TTML.
Glenn: I would like us to limit
the scope of this particular requirement to what the title
says, which is
... adding generic CSS properties. Andreas it sounds like we're
on similar thinking in that regard, details
... to be worked out. What I do not want to mix in with this is
any discussion of general long term
... migration to a new as yet defined language that would not
be TTML if it is intended to diverge from
... an XML based language. I do not want to include that in
this issue.
... I don't object to someone opening a new issue defining a
timed version of HTML5 with a migration
... path from TTML but in my opinion that's not part of TTML
standardisation, it is part of a new language
... that could potentially be done in this working group. It
would certainly require a new Charter entry, and
... strong buy-in from the content community. Personally I
think it's a bad idea and would divert precious
... resources from an already diverse implementation field by
introducing yet another language
... ostensibly with the same goals but a different syntax. If
that ever comes up under a proposal for a
... new Charter Skynav will object to it formally because we
don't think it is justified by the industry or any
... particular use case.
Nigel: Thanks, Glenn that's my
3rd bullet effectively. Another is to add a feature designator,
which I
... don't think is contentious.
... Another was to add a class attribute to allow external
stylesheet support. That would need us to define
... how to populate the class attribute of every element in an
ISD.
Glenn: I think supporting
external CSS stylesheets and selectors would be a step further
and would like
... to exclude it for now. It would make it harder to get
consensus - I would object to it, for example!
... I'm sort of in the middle on the properties themselves. I
am trying to be amenable to your proposal Nigel,
... I see the utility in having a system that facilitates rapid
adoption of CSS properties without going through
... a language iteration on TTML, and it would facilitate
future modules where if we see a particular
... property being very important we could bring it in to TTML
directly as a TTML style attribute.
... That would certainly enable some movement on your
requirements Nigel.
... It does make things complicated and creates
interoperability problems, for example TTT is probably
... never going to support CSS style properties.
... It would have to be behind a feature for sure.
Nigel: That is part of the proposal.
Glenn: On your last bullet about
precedence, it would obviously depend on whether your system
supports
... CSS properties. I'm open to either direction for
precedence.
... I feel that CSS is somewhat of an overwrite and am not
convinced on that yet.
Pierre: What happens with
inheritance? Do you inherit CSS styles like you do TTML
styles?
... What if the inheritance rules are not the same in CSS and
TTML? What about different length units?
... What's the interaction? What's the viewport?
Glenn: Exactly, there's a whole different terminology.
Pierre: Directions and padding are both different.
Glenn: Individual properties are challenging. Syntactically it is easy, testing is hard.
Pierre: The thing I have never
fully understood is, in order to import additional styles, that
can be done
... with extension attributes, literally tomorrow. BBC can
experiment to its heart's content, and if it is
... successful and useful it can be added later. With a use,
implementation, examples, semantics it is
... trivial to add. I do not understand why this does not meet
the requirement.
Nigel: One of the requirements is low overhead of adoption, what you're describing sounds like high overhead.
Pierre: From an imsc.js perspective it is always high overhead - the property has to be parsed, inherited etc.
Andreas: [scribe missed]
Pierre: The hard part is mapping
the semantics of e.g. viewport related units. The hard part is
not in the
... syntax of the attribute.
Glenn: Adding the modularisation
system might make it much easier to add new style properties
than
... has been the case in the past.
Pierre: Exploring modularisation,
the modules can use the TT namespace, so the module can
introduce
... a new property, get it to FPWD, experiment with it, tweak
it, then publish it, without having to change
... namespace and all that stuff.
Glenn: This goes to the
modularisation framework. We enumerate all the style properties
in a table. We
... are going to have to do something to make that table
extensible so that we don't have to change that
... table every time we add a module that defines a new
property.
... When we have the modularisation framework in place it
should be a much easier process to push out
... a spec for one or a few related properties. I can see it
being used on a group of semantically related
... properties.
... I could see this turning into three requirements: 1. class
and selector, 2. new language, 3. CSS property support.
... It would be much easier to process these if we divide it
into multiple issues or requirements.
Andreas: First I think what is
different from Pierre and Glenn is to have a clear selection of
what can be
... supported specifically, i.e. which CSS properties. And then
figure out what are the problems with
... applying it to TTML and finding a good way to represent it
syntactically. I'm not sure if we need to agree
... on this today, but maybe we do need to agree today is that
it is worthwhile not just to open the door
... but make a selection of what needs to be supported and deal
with the difficulties of each property.
... I would also see it as a different module and a list of
style properties. Would that satisfy your original
... intention NIgel?
Nigel: I think it could,
potentially. One other idea as a sort of middle ground is to
create a module that
... defines some generic ways to add CSS properties, and maybe
adds some available CSS units, and then
... via a registry we could whitelist specific CSS properties,
adding them by consensus of this group, and
... for each understanding the potential overlap and clash with
TTML style attributes and how to handle
... any such clash.
Pierre: How do you see that a registry would be less work than updating a working draft?
Nigel: I wouldn't propose to keep
updating a WD, because that never gets to any kind of
standard.
... I'd propose a generic Rec and then a dynamic registry.
Pierre: From an implementation standpoint you haven't solved anything.
Andreas: What would the publishing process be for the modules? I thought they would not be Rec track?
Glenn: They would have to be Rec track.
Pierre: That's the idea.
Nigel: +1
Andreas: Then each time you want to update you have to iterate.
Pierre: Sure.
Glenn: You might have one module
defining property 1 and another defining property 2 and each
time
... you rev that you have a certain level of work to do, but we
can control the granularity.
... The TTML3 document itself would need to have some framework
and mechanisms to enable the
... modularisation process.
Andreas: Then I agree if the
module goes through the process then a separate registry would
be duplicate
... work.
Glenn: Let's say the CSS
extensions module exists and just refers to a registry, in
which we bless the CSS
... properties for use.
... Then there's a quasi-generic module that does not enumerate
the properties but refers to a registry.
... Technically speaking we don't need the registry but that
gives us a process for blessing uses which
... makes it better for testing. If we make it completely open
ended then we have no control over testing
... or blessing uses. Given there may be semantic issues with
impedance mismatches to deal with.
Pierre: I would make it a WD that we update rather than a registry.
Glenn: The other option is just to define new TT style properties directly in new modules.
Pierre: I would go down that path
from the beginning, because the work will be the same in the
end, no
... matter how you cut it.
Glenn: Then that is an
alternative option, to promote fine granular modules for making
extensions to
... the existing suite of style properties by having, say a
border style extension module and that we define
... some number of tts: property names that deal with the
border issues that Nigel wants to deal with.
... The turnaround on that module could be much shorter, for,
say, flex.
Nigel: Bad example in the context of TTML!
Glenn: You're right Pierre the work has to be done somewhere no matter what.
Andreas: What is different, the
work may be similar, but the turnaround time to publication is
different.
... The general mechanism like Nigel proposed could be done
fairly easily, camelcasing and so on, and we
... could bring this through the process to Rec, but if you
combine it with a first list of features, then you
... possibly get stuck with each feature to add. If we separate
it then the general mechanism is first, and
... if someone wants to do it then they can do in a
standardised manner.
Glenn: The risk is with interop
where content authors start throwing in CSS properties right
and left and
... make use of application specific processors and JS code to
do this.
... Then interoperability might decrease as a result. We would
have less control over testing.
Pierre: The argument I hear is that the Rec track is too slow?
Nigel: Yes, we want to be able to access CSS features that already on Rec track with minimal additional delay.
Pierre: TTML is not HTML, you cannot just adopt CSS properties so easily.
Nigel: CSS is not restricted to HTML either!
Andreas: Concerned about time for
this and other issues we have to cover. Also as an AC rep
there's a
... large number of Recs to review.
... We haven't dealt with this modularisation yet, so we should
not try to solve it now.
Nigel: Thanks for that, I think
other organisations are interested in the requirement too but
we don't
... yet know the acceptable solution.
Glenn: I just want to make clear
that if we do semantic mapping it is a non-trivial process that
we cannot
... put in a generic module definition. It would have to be on
a per-property basis. Otherwise the only
... option is to put the semantic mapping nowhere or in a
registry.
Nigel: Where are we up to here?
Pierre: I haven't heard anyone
speak against an easy path to adding style properties to
TTML.
... The obstacle to doing this on the Rec track should be
minimal overhead and we're talking about how
... to make it happen.
SUMMARY: Group agrees to look for ways to add new style properties with minimal overhead and to try to solve this in 2019.
Cyril: There are two parts - adding new style properties and adding the class attribute. Are they both in scope?
Nigel: There was some push-back against adding class
Glenn: The overall goal to reduce overhead is shared.
github: https://github.com/w3c/tt-reqs/issues/15
Pierre: Remind me why fonts wouldn't solve this?
Nigel: It's not interoperable and it is not accessible.
Glenn: You can use private use area easily.
Nigel: You have to manage
authoring and distribution fonts carefully.
... Also there's no text alternative.
Cyril: You can use glyph substitution so there is a text alternative.
Glenn: It's implementation
dependent.
... You can embed the font in the document to ensure the
private use area usage is consistent.
Nigel: If we can't use glyph substitution then you have the accessibility issue. There's no text alternative.
Pierre: You can put altText on the span containing it.
Cyril: If you have text in English how do you select altText in English.
Glenn: You can use it you can do whatever you want with it.
Cyril: Yes so you can't use it
because there's no semantic defined.
... Is glyph substitution implementation widespread?
Glenn: g subtable
Vlad: Yes it is universally implemented and supported in all browsers.
Glenn: So native TTML renderers
or translators like imsc.js it is not supported unless you map
the font
... into the browser world and pass along the string, maybe it
could be supported that way.
Vlad: Just to give me a bit better understanding of the subject, what do you think would stop this?
Glenn: For gaijin characters, and emerging emoji.
Nigel: And things like company logos.
Glenn: The idea is to use a downloaded or embedded font and use PUA code to map to a glyph.
Nigel: Or glyph substitute a set of characters like "twitter" to the twitter icon.
Vlad: That works - for example the word Zapfino in the Zapfino font gets replaced by a logo for the font.
Pierre: If you go to a text
alternative as a fallback there's a bigger issue that it may
require a different layout.
... The entire idea of having an image fallback be unstyled
simple text doesn't work very well. How do you
... specify the style (color, italics) of that fallback. That's
why in IMSC you have a separate file for images.
... The text equivalent of image is not always what is written
in the image.
Vlad: Remind you that fonts can
have glyphs defined in SVG and that glyph can be selected when
conditions
... are right. It will still be text for all intents and
purposes.
Pierre: When you substitute long text with one emoji that might affect the layout significantly.
Vlad: I agree
Pierre: that is a significant issue here.
Vlad: Rendering differences are
not as bad as they used to be. Using a particular font is
probably the only
... way to make sure the rendering is right. Assuming that some
font will be right is wishful thinking.
Glenn: We don't define line breaking or space distribution semantics so implementation dependent.
Cyril: Pierre raised an
interesting point, the layout. I agree replacing a small image
with 10 or 20 characters
... is a big change. Focusing on the requirement, is there any
objection to the requirement being agreed?
Glenn: I have a problem with the requirement because it is written in terms of images not text.
Pierre: What about recasting it in terms of glyphs?
Cyril: Using inline images with alt text does the trick, right?
Glenn: That's the traditional way
with gaijin.
... We have a terminology issue with Text and Image profiles
each being constrained.
Pierre: The entire discussion so far has been really about custom characters, right?
Nigel: Yes, I don't think we want
to support generic pre-rendered text in an image into text
profile.
... However the change doesn't make a substantive
difference.
Cyril: You can put any image into the font though, right?
Glenn: Correct you could.
Cyril: You want to say that if you don't make fonts available the content of the file should be human readable and carry the content?
Pierre: I don't agree with that
Glenn: I don't see that as a requirement.
Cyril: I'm not sure of the requirement, we're talking about solutions.
Pierre: This is for visual elements as text.
Nigel: The only requirement that ties it to text is to size the image using the font size.
Glenn: Also font kerning, spacing, scaling etc are all affected by laying out as text.
Nigel: Recasting, the request back seems to be to support custom font embedding in IMSC Text profile.
Pierre: That is how it is done in ARIB-TT.
Cyril: I don't think it is the
same thing.
... This is not the gaijin character use case. That gaijin is
readable, but the private use area character is
... not readable.
Pierre: It can be a cartoon.
Cyril: It is not accessible, as
Nigel explained earlier, if you don't process the font the text
is still readable
... by a screen reader.
Vlad: I've been listening to the
discussion. As far as the requirement is concerned there are
three
... requirements that should be connected.
... 1. Support custom fonts by embedding
... 2. Support of inline images as part of text (not how it can
be done, but that seems to be the requirement)
... 3. (blanking out on that!)
... Having font embedding functionality is a way to support
inline glyphs.
Nigel: Also we need a screen reader to do something sensible here.
Glenn: The two options are potentially orthogonal solutions to this problem.
Vlad: Not necessarily.
Glenn: The embedded font is more
consistent with treating this as text and is more compatible
with the
... text profile which does not include image, but as has been
pointed out it might not satisfy some
... screen readers but I think they are out of scope.
Nigel: No way are screen readers out of scope.
Vlad: Accessibility was my third
requirement.
... All those requirements are valid concerns and there may be
one solution that satisfies them. If we can
... agree on the requirements that would guide us and many
other implementers on the solution.
Andreas: Can we bring this to a close (time)?
Cyril: I agree with Vlad's
phrasing and support all three of those requirements.
... We could use this heavily at Netflix.
Glenn: I do not agree that we
have separate requirements for embedded glyph and image support
in text.
... They are two different scenarios for solving one
requirement, which is to support the ability to display
... as text some form of an image either as a glyph or an
inline image characters for which there is no
... standardised visual representation. There's probably
something on accessibility too if you cannot
... display the rendering. I view Vlad's first two requirements
as two different solutions to the underlying same
requirement.
Nigel: +1
SUMMARY: Solution options available, need more thought and investigation, overall requirement to find some way to present images like glyphs are presented, in an accessible way, is accepted.
github: https://github.com/w3c/tt-reqs/issues/8
Nigel: Thank you for dialling in
Peter, I'm going to take what you say as coming from Andreas as
IRT for the purpose of IPR.
... Summarise the requirement please?
Peter: The work comes from a
research project with a couple of other broadcasters,
investigating
... accessibility services in VR/360º environments.
... We tried to put a workflow together with existing
standards.
... There are a few gaps. The one corresponding to subtitles I
presented here. The first requirement
... I put there is formulated quite generally.
... The main issue is we need to find a way to refer 2D space
in IMSC into a 360º or 3D environment.
... It can be done technically, that's not a problem, we did it
with some implementations and user testing
... but there's no standardised way to do it.
... We know there is more and more 360º content on the web or
VR stores. They sometimes have
... subtitles but the quality is often very poor so we see a
need to improve it and bring the features that
... IMSC has already into that new environment.
... The requirement is that a way is provided that 3D
environments can be used as a target rendering area,
... relating the 2D subtitle into the 3D environment.
Nigel: Is that representing a position in 3D space?
Peter: Yes that's the main thing
needed, and to describe what this position could be
exactly.
... For example if we link the centre of the rendering
container to a 3D environment.
... There are different approaches for that, and this is what
my addition to this requirement is about.
... I described what we are doing and there is another approach
I described.
Glenn: Peter, we have in TTML2
appendix H on root container region semantics. We would have to
find a
... way to merge or integrate 3D into this model to make
effective use of what is being proposed here.
... Maybe it would be useful for you to review that appendix
and make some suggestions for how to tweak
... the model to include the Z axis, if we are talking about
Euclidean geometry.
Pierre: It could be spherical or cartesian models.
Glenn: Is the proposal primarily spherical?
Peter: We used spherical angles
to describe it but it is a matter of translation from one to
the other.
... We have a concrete implementation but it doesn't really
matter how this is expressed. There are good
... reasons for how. We need good definitions for how to
standardise.
Andreas: The main part in terms
of time is to focus on the decision if we want this requirement
as a new
... feature in TTML3.
... 1. Do we understand the requirement?
... 2. Is there enough backing from content providers?
... 3. Are there implementations?
... For the second part there is a need in the industry - maybe
Vlad can come in. For implementation Peter can say more.
Vlad: To try to add more clarity.
Looking at this issue, the use cases span over 360º video and
immersive
... reality. For subtitles, if we consider 360º and 2D being
basically the same, you paint an object that
... occludes anything else in the video. If you do exactly the
same in immersive reality domain, when you
... occlude something behind an object, and the occlusion is
located behind the object then that's the kind
... of occlusion that creates conflict in the human brain -
when it happens it breaks down the perception
... of the stereoscopic scene.
... This is why depth position is such an important requirement
for subtitles.
Andreas: You are also in the VR industry forum that has the issue to resolve.
Vlad: That is not a standards organisation, it helps guide the industry, but has a different scope.
Nigel: Is the requirement to
identify a 3D location associated with a content element
independently of
... the region?
Vlad: Yes that is one of the requirements.
Nigel: Is it enough to associate zero or one 3D position and allow the implementation to do the presentation to meet user requirements?
Vlad: Yes, that is definitely one
piece of the puzzle.
... Also the content provider may want to associate an
on-screen object with the character in the video.
... For example if I want an avatar per person in the screen I
may want to define that in addition to the
... location, and my content may want to use that icon to
associate the symbol with something outside
... the viewport.
... Another use case is that the content creator would want to
use something as well as a directional arrow
... to identify where the speaker is.
Andreas: Can we agree there is a
requirement to add some specification text, vocabulary and
semantics
... to position a content element or region in 3D space?
Cyril: I'm not opposed, I'm wondering where the most appropriate place is, a separate module or appendix H?
Glenn: We have defined a pan
audio property which is effectively an angle on the horizon, if
you multiply
... the range of -1 .. 1 by pi you get the full range. I wonder
if that could be used to support the first of
... the two solutions that were suggested here. I realise we
defined it for audio not 3D per se.
Nigel: I'd almost go the other way and support audio positioning in 3D space rather than the 1D pan parameter.
Glenn: I would support making this a module and it may require modification to appendix H also.
Andreas: Is this TTML3?
Nigel: I think it needs TTML3 and IMSC as it has been put.
Pierre: I think IMSC is a longer
path. There's a desire to put things in TTML before IMSC where
possible.
... If we want to go down that path TTWG is going to need to
coordinate closely with other organisations,
... I would hate to be inconsistent with other efforts. We need
a champion for this. MPEG has a significant
... effort there.
Peter: Yes we recently sent from
the VR industry forum a letter to MPEG asking questions about
their
... suggestions for handling subtitles in 3D. They also support
IMSC in their OMAF draft and I think there
... are still some gaps so they try to provide that link from
their side. It is true that needs to go hand in hand.
Pierre: The first step here is to
write down what we want to do and make sure it is consistent or
if not then
... it is for a good reason, then once there is interest adding
to IMSC is a simple editing task.
... There's a lot of work to do first.
... If someone is wiling to do the work, then yes, it's
interesting.
Glenn: This would definitely be a module.
Andreas: IRT would possibly
champion this. We already made a start with Peter working with
other
... standards organisations in the direction Pierre requested.
We need to figure this out but possibly we
... will try to push it in this group.
Vlad: I think that similar to
previous discussion there are two separate issues. First is to
agree on the
... requirement and then how. It sounds like we are all in
agreement this is a requirement to adopt and
... how is a secondary issue.
Nigel: That's a nice summary, thank you Vlad. Any dissent on that?
Glenn: IRT would provide an editor for a module?
Andreas: No we haven't decided
how to do that. I cannot commit to it yet.
... Can we defer the editor discussion for now?
Pierre: OK then this is 2019
contingent on an Editor.
... I don't mean someone to do typing, I mean caring about it,
aligning with other efforts etc.
... Someone to really make it work.
... I should say a more generic champion for this rather than
an Editor.
Peter: For me it is hard to
estimate how much work it would be so I cannot commit to it
now, which maybe
... is what Andreas is saying, it's in our interest to follow
up on this.
... I see that people start to do it in one way or another and
probably within the project and now after
... it only works in a closed environment. It would be good to
avoid letting different variations appear, which
... is happening already.
Pierre: I share your concerns!
Andreas: Can we proceed with what Nigel proposed? We have interest but cannot commit today.
SUMMARY: Group discussed this, generally supportive, contingent on effort being available to make it happen.
github: https://github.com/w3c/tt-reqs/issues/16
Nigel: This seems pretty straightforward?
Pierre: I asked a question on
w3c/imsc#82 - someone called @shobanaberlin mentioned
fragmented MP4 HLS.
... I've received no response to my question.
Gary: It's in the HLS RFC.
Pierre: Right, fMP4 supports
images so I don't understand this comment. There's literally an
MPEG spec
... for embedding images in MP4.
Glenn: What has that got to do with this requirement? Aren't you raising a separate issue?
Pierre: No because you don't need
to embed in the IMSC document if you can embed in MP4.
... The commenter asked for a way to get images in fMP4 and
there is literally a spec for it so I was trying
... to get more information on it. I haven't seen the use case
where it is impossible to do it other than
... embedding in MP4 then we could do it, but big XML documents
filled with base64 encoded images is
... not great.
Cyril: I'm with you here, there's a spec here for doing it as binary blobs, referenced by MPEG.
Nigel: We have a significant
concern here, a better alternative way of doing it in ISO/MPEG
14496-30,
... and no support, and no feedback from those who
commented.
... We have consensus to close this without taking it
forward.
RESOLUTION: Close this issue.
Peter: [has to leave]
github: https://github.com/w3c/tt-reqs/issues/10
Nigel: Cyril raised this and I supported it. Does anyone have anything bad to say about it right now?
Pierre: I think this approach is worth a try.
Glenn: My conclusion is requirement 1 is already supported and requirement 2 is problematic.
Pierre: Problematic in the solution or the requirement?
Glenn: I see it as an ask to support event based timing.
Nigel: I don't see that.
Cyril: I am not married to the
marker proposal.
... The idea is to provide not line break opportunities but
event based opportunities.
... It could be a conditional timing hierarchy for a given unit
of content.
Pierre: This is a really
important topic. I don't know the answer, but if we succeed it
will really help the
... industry so we should give it a shot.
Glenn: One solution is to produce different documents.
Pierre: There are multiple combinatory choices
Glenn: This is also needed for
karaoke where we have an algorithm for pushing content into a
display
... region dynamically.
... You can't reuse IDs so that's off the table.
Pierre: Setting aside the
solutions, do you think the requirement is relevant?
... Looking at the images.
... Being responsive to those different aspect ratios.
Glenn: I haven't given enough thought but it seems something worth considering.
Andreas: From our side we think
it is an important requirement.
... Making responsive web content is important and it would be
good to do the same for TTML.
Glenn: It is only the splitting that is an issue.
Vlad: I agree it is important to
be responsive in this way. I like the way you put it Cyril but
the samples
... don't go beyond line breaks and text size, you don't do it
justice, but the requirement is good.
... Responsive design and typography, i.e. using full scale
variability using variable font support, which
... every browser does with CSS support and we are talking
about scaling font from condensed to wide.
RESOLUTION: We will attempt to meet these requirements in 2019.
github: https://github.com/w3c/tt-reqs/issues/12
Nigel: If CSS has done this then we should do it.
Cyril: We should work with CSS
and adopt what they do.
... I'm not asking for doing this without CSS support.
... This is mostly about edge cases not fundamental Japanese
language support.
Nigel: So Cyril does that mean you will take the lead with CSS WG to get these defined?
Cyril: I will try!
Glenn: This is the case where a
module to define this would be appropriate and can be tracked
to a
... timeline that matches what CSS is doing. We can do things
in parallel with modules without having to
... waterfall it all together.
... Then we can explore with CSS their interest in solutions,
and propose something to them and see how
... they react to it. I have no strong feeling on whose
solution we adopt, the one we came up with or something
new.
Nigel: Anyone want to speak against doing this?
RESOLUTION: Proceed with additional Japanese language features in a TTML3 module in close coordination with the CSS WG.
github: https://github.com/w3c/tt-reqs/issues/9
Nigel: This is closely related to some of the other issues we discussed earlier, including granular timing and transitions.
Cyril: The use cases are quite
different. It is not about responsiveness but transition
styles, not about
... changing the layout. We would like to signal the semantics
of karaoke separately from the styling.
... For example ingesting IMSC content with karaoke styling and
then we would decide what karaoke means
... and apply styling ourselves, or in the document.
Glenn: Without agreeing with the
specific requirements or proposed solutions I'm in favour of
moving
... forward with some kind of requirement for supporting
karaoke. I need to digest this a little more and I
... also want to look at what ARIB-TT did because they defined
some support for karaoke that I haven't
... looked at in detail. It is something to map to a module if
possible.
Nigel: I see a lot of overlap
between different requirements today, for example the text
emphasis style
... seems to have something in common with the inline image
requirement.
Pierre: Emphasis style allows a quoted string so you can have the emphasis be whatever you want.
Cyril: Okay that's a potential good solution.
Glenn: It could conceivably even be an animated glyph because you can use SVG animation in an embedded font.
Cyril: I'm interested in animation between words not within the glyph.
Nigel: Isn't this a completely new layout requirement for animating a moving ball between words?
Vlad: It is and strictly animations are not permitted in SVG glyphs.
Cyril: I am fine with this in a TTML module but what about IMSC, maybe a karaoke profile?
Pierre: One data point supporting
getting it into IMSC at some point is that IMF supports karaoke
without
... this key functionality. I suggest doing the TTML3 module
first and then if there is industry support
... adding it into IMSC as a small change.
... Then if it doesn't have to be part of IMSC by end of 2019
that makes it a lot easier.
Cyril: Instead of IMSC 2019 being
published on the same date as TTML3 then we could pipeline them
and
... that would make it easier.
<Vlad> SVG glyph limitations as defined by the OpenType spec: https://docs.microsoft.com/en-us/typography/opentype/spec/svg#svg-documents
Pierre: We said we would try to publish all new specifications by end of 2019 and pick requirements based on that target.
Glenn: To raise the
modularisation approach we should be motivated to minimise what
we have to do in a TTML3 baseline document
... so we get it out the door more quickly than the modules we
define functionality in, by focusing on the
... framework for modularisation as the key thing in TTML, then
focus in parallel the modules that take
... advantage of that framework. Then we decouple to a certain
extent getting IMSC to a particular gate.
Pierre: Makes sense to me. If we
think we get it done by June in TTML3 then the feature in IMSC
by the end
... of the year is feasible.
Andreas: Is this issue accepted?
PROPOSAL: Take up the karaoke requirements in 2019
Glenn: There are a bunch of
requirements, 6 of them, I don't know if I would agree to all
those at this time
... but I think we should move those forward.
RESOLUTION: We will take these requirements forward for our 2019 work.
Nigel: Wrapping up very quickly
because we're over time.
... Today we went through all the requirements issues that were
open, and made a call on them where we
... could, and we agreed to create a modularisation framework
for TTML to allow us to work on orthogonal
... functionality in separate Rec track documents. I have the
action to draft the TTWG Charter update
... to grant us permission to do this, which I will do in the
next month.
... We meet same time tomorrow, 0830 Geneva time, and will
revisit the Live requirements.
Andreas: If someone could draft timelines for our work that would help.
Nigel: Thierry has that action.
Andreas: We need a plan for the modules work.
Pierre: Could the glue be added to TTML2 for modularisation because it doesn't affect conformance?
Glenn: Let's take that up at a later date.
Cyril: I may not be able to join tomorrow because of the timezone.
Nigel: Thanks everyone. Enjoy your evening, I'll adjourn the meeting now. [adjourns meeting]