See also: IRC log
<scribe> scribe: nigel
Nigel: Today, we have TPAC
planning (if there is any - reminder there are 2 calls
between
... now and the face to face meeting).
David_Ronca: [will be present for first hour only]
Nigel: That's apart from
today.
... We should review Cyril's compatibility document, and look
at TTML2 Wide Review issues,
... to work out our disposition.
... For IMSC, there were some comments raised on the vNext
Requirements doc to go through.
... Then hopefully resolve to publish as a WG Note
... We have some pull requests to look at for TTML2 also.
... I don't see anyone who can discuss WebVTT today but we will
try to get to that if they join.
... Any other topics to mention, or other business?
group: [no]
Pierre: [will have to drop off after the first hour too]
Cyril: In IMSC 1.1 we should revisit the issue about subsetting of TTML2.
Pierre: I thought that was the primary topic.
Nigel: I see this as two
questions (or three):
... 1) Compatibility between TTML1 and TTML2,
... 2) Inclusion of IMSC features in TTML2
... 3) Subsetting of TTML2 to generate IMSC vNext
Nigel: I don't think there's anything to do here? Not everyone has put their names on the wiki yet.
Cyril: I want to go through the
document, but not in too much detail (that's for
offline).
... Just for recapping: I did a side by side manual comparison
of TTML1 and TTLM2 to
... identify changes, and then assessed if they are critical
for compatibility, i.e. whether an
... TTML1 document would be rendered by a TTML2 processor in an
acceptable way according
... to TTML1, taking into account fonts, rendering etc.
... I hope you all had a chance to look at the document.
... My general feeling after this is that there are some subtle
differences but either TTML2
... is more precise because TTML1 was ambiguous, in which case
it's okay, TTML2 rendering
... would be acceptable as a TTML1 rendering; OR there are
features that are different, but
... for features that are specified in TTML1 but not used in
IMSC1, like pixelAspectRatio,
... that is, the features with differences are not actually
used.
... The problems I identified are the orange ones -
pixelAspectRatio, direction (TTML2
... fixes a TTML1 problem, maybe a good candidate for TTML1
Third Edition), overflow - a
... MUST statement has been removed in TTML2, then a section on
computed style set
... processing, where a filtering step in which TTML1 does not
filter <set> elements but
... TTML2 does filter them, so the computed value would be
different. My understanding is
... that's a problem in TTML1, so could be fixed in TTML1 Third
Edition. That's it.
Nigel: For `<set>` exclusion I think that was an omission in TTML1.
Mike: This all came about to
ensure IMSC 1.1 compatibility with TTML2. The exclusion
of
... set becomes a problem.
Nigel: You should check the
impact of this - I believe it was an oversight in TTML1
and
... you could say it was implied.
Pierre: We came to a decision on
this - see ttml1#216 - the plan is to include it in TTML1
... Third Edition. It's just a bug in TTML1, and would have
been in TTML2 if we had not found it in TTML1.
Cyril: I'd like to know if anyone thinks I've missed something?
Pierre: A good thing to check is if every difference has an issue in TTML1.
Cyril: I'll do that to make sure.
Pierre: If yes then you have agreement, otherwise we should go over them.
Cyril: Assuming I haven't missed
anything, do you share the feeling that there's no
... significant gap between TTML1 Third Edition and TTML2 and
that the renderings can be compatible?
Pierre: That was the goal from
the beginning. So I agree with you - that's why those
issues
... were filed against TTML1 and TTML2 was corrected
accordingly.
Mike: I'm not sure what
"significant" means here - we've identified some areas that
could
... be done differently depending on which version is being
used.
... We still need the [statement about no differences]
Nigel: Why do we need that
statement? Put another way, if TTML1 is ambiguous and
... TTML2 is less ambiguous, is that a problem?
Mike: If we publish TTML1 Third Ed and then the differences are removed, it's not a problem.
Pierre: I'm with Mike in the
sense that we should capture that goal, because we seem
to
... keep coming back to it even though everyone agrees that its
the goal. I don't understand
... the reluctance.
Nigel: My reluctance is
"unintended consequences" - especially if there are multiple
goals
... and they could come into conflict, it's a hostage to
fortune if we state them; it's the work
... of this WG to resolve them, and if we intend TTML1 Third
Edition and TTML2 to be
... compatible in the way that we agree, we just make it so,
without having to state it in the spec.
Mike: This isn't about us, it's about the readers of the spec.
Cyril: There's section §3.4.2 in the spec about backwards compatibility.
Mike: I had an action to propose some wording.
Nigel: That's issue ttml2#458.
Cyril: Where's the actual text proposal?
Nigel: The only tonal difference
I want to see is that we don't state a guiding principle
... but a statement of our understanding of what we have
achieved.
Cyril: Why don't we put something
like I put in the top of my analysis document, that
... a TTML1 document processed by a TTML2 processor would
produce an acceptable
... result when processed by a TTML1 Third Edition
processor.
... I don't care where that goes - in §3.4.2 or in the
Scope.
Nigel: We have a dependency on TTML1 Third Edition here, which needs some work on it.
Mike: We're not jumping to TTML2
Rec tomorrow so we have some time.
... I know Glenn has done some work on TTML1 Third Edition.
Pierre: May I encourage the Chair to follow up with Glenn offline?
Nigel: Yes, I will.
Mike: It doesn't change the
principle here - we can still state the same principle
regardless
... of TTML1, because that's our intent.
Cyril: I agree.
... If the wording is about TTML2 being designed for acceptable
results except for edge
... cases X, Y and Z would that work for you Nigel?
Nigel: Yes, sounds good.
Cyril: Everyone else?
Mike: Yes, sounds good.
Cyril: I'll propose text in ttml2#458.
action-508?
<trackbot> action-508 -- Thierry Michel to Check if there are editorial/substantive labels for ttml2 issues and add if not. -- due 2017-10-12 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/508
Thierry: I don't think I've done that yet.
Pierre: There's been a lively
discussion on the reflector; now we've addressed the
TTML1/TTML2
... compatibility, the outstanding issue is for IMSC 1.1 to be
a subset of TTML2. It's been in
... the requirement of IMSC 1.1.
Cyril: Please clarify "subsetting"? What is "subset"?
Pierre: It means it doesn't
introduce any extension, it only constrains features of
TTML2.
... I thought that was the goal, but maybe that's the first
question. Then there are two options
... for getting there. One is to hoist into TTML2 the syntax of
IMSC 1.0.1; the other is to
... deprecate the syntax of IMSC 1.0.1 and use the syntax of
TTML2.
... First I want to check that IMSC 1.1 is supposed to be a
subset of TTML2?
Cyril: Yes
Mike: It's contingent on the previous discussion and arriving at some language.
Nigel: I'm concerned both about
the cleanliness and tidiness of TTML2 and the difficulty
... of content providers creating documents that work in
current IMSC 1.0.1 players and not
... having to produce multiple flavours of the same
document.
Pierre: What about IMSC 1.1 being
a pure subset of TTML2 with the exceptions of IMSC 1.0.1
... features that are deprecated for backward compatibility.
That's what the requirements
... currently state.
Cyril: I don't understand what this means.
Pierre: Take any IMSC 1.0.1
extension, say ittp:aspectRatio - we have two options, one
to
... import into TTML2 the syntax from IMSC 1.0.1, and stop
there; the other option is to
... support but deprecate the IMSC 1.0.1 feature and support
the TTML2 feature. Those
... options exist for every extension.
Nigel: I would also state what
the mapping to the new syntax is and what the rule is if
... both are present.
Pierre: It's even more
complicated - fillLineGap doesn't say the same thing in TTML2
as
... in IMSC 1.0.1.
... For each extension, we can figure out what we want to
do.
Nigel: Seems reasonable.
Pierre: I think the goal is for IMSC 1.1 to be a subset of TTML2.
Nigel: If we want to end up with
IMSC 1.1 extension features having a mapping to TTML2
... then we could do that either by choosing the option and
putting into TTML2, so TTML2
... can support IMSC 1.0.1 syntax, or we could state the rules
directly into IMSC 1.1 and not
... add the extensions into TTML2.
David_Ronca: I think I'm with
Pierre that we can add the IMSC 1.0.1 features to TTML2
and
... use a deprecation model.
Nigel: So you'd put the IMSC 1.0.1 extension features in TTML2 as deprecated?
David_Ronca: No, I don't think they need to be in TTML2.
Nigel: So you'd put the deprecation language in IMSC 1.1 then?
David_Ronca: Yes because the
extension features wouldn't be in TTML2.
... There are two ways forward, one pure TTML2 and one
backwards compatible with IMSC 1.0.1
... and they would both be supported by an IMSC 1.1
processor.
Pierre: Just to clarify, you're not objecting to move extensions into TTML2. right?
David_Ronca: It would be weird to
put ittp:aspectRatio into TTML2 but for things that don't
... exist in TTML2 they could be added.
Pierre: I'd like the flexibility to deal with each extension one by one.
David_Ronca: I agree with that.
I'd expect TTML2 aspect ratio to have equivalent
functionality
... to IMSC 1.0.1 ittp:aspectRatio, and not have both in
TTML2.
Pierre: At TPAC we will have to
ensure that the TTML2 semantics achieve what is in IMSC
1.0.1
... I'm proposing taking each extension one by one.
David_Ronca: I agree we have to do it that way.
Nigel: I think the result of that
is that IMSC 1.1 would be a subset of TTML2 with the
... exception of deprecated features.
Cyril: yes
Pierre: That's what the requirements say.
Cyril: And for each deprecated feature there is a mapping to a TTML2 feature.
Pierre: Each one may take some discussion.
Cyril: There are only 6 right?
Pierre: As a result of this
exercise some changes will be needed in TTML2.
... I'm particularly thinking about fillLineGap. There have
been some exchanges about that
... in IMSC 1.0.1 and having different semantics in TTML2 would
be really damaging.
... My plan is to proceed with a game plan for the group to
review for each extension.
Nigel: Sounds good.
Cyril: Mike, are you still concerned that an IMSC 1.1 document with tts:disparity might be rendered differently?
Mike: Given the history I'm sceptical but I'm also optimistic that you will come up with the right language!
Cyril: Ok
github: https://github.com/w3c/ttml2/issues/406
Nigel: A couple of things here. First, I opened a Pull Request for review by anyone who can.
Nigel: And Cyril, you found
transform::skew for fontShear.
... There are two actions. First, to update the CSS
Requirements wiki to point to it;
... second to create an issue linking to #406 mapping fontShear
to transform::skew.
Cyril: I will create that issue.
Nigel: I don't mind doing the work to add it to the pull request.
Cyril: How can we review the pull request?
Nigel: I committed the regenerated HTML so it can be reviewed, so you can open it at:
https://rawgit.com/w3c/ttml2/178659af16ee4b8514adc7f16ea1ca786fcf38a1/spec/ttml2.html
Cyril: Great, thank you.
... I'll have to review that.
... So in principle you're building this annex based on the
wiki page?
Nigel: Yes with the additional
filter of the CSS 2017 Snapshot so I check each feature
... against the latest snapshot version of the spec.
Cyril: At some point there should
be a top level thing in the wiki page pointing to the
... new section in TTML2 in case they diverge.
Nigel: Good idea, when we've
merged the pull request.
... However it's much easier to read in the wiki page so it
might be worth updating.
Cyril: just having a sentence pointing to the more accurate information would be good.
Nigel: +1
... On this pull request I'd be interested in any suggestions
for better formatting.
... The new section N.2.1 has a bunch of small tables, which
blend into each other a bit.
Cyril: Yes it's not very compact.
Nigel: I agree - it has the right information in it I believe, but I don't like how it looks.
github: https://github.com/w3c/ttml2/issues/413
Nigel: It looks like Glenn
doesn't want to add anything, but I don't know why we
don't
... just align with the CSS set while also keeping the
additions already defined in TTML1.
Cyril: Eventually we should have the same list as in CSS, so we may need to ask CSS to add some new names.
Mike: I don't see any harm, and
would be happy to get to alignment.
... Taking out named colors would have no benefit. It's trivial
enough to translate the
... handful of named colors into the sRGB hex
representation.
... §4.2 of the SVG 1.1 spec has a big table of named
colors.
Nigel: I think it doesn't include transparent.
Mike: It would be a disservice to remove named colors in TTML2.
Nigel: +1
Mike: It would make TTML1 documents non-conformant that would be a bad idea.
Cyril: SVG supports CSS2 plus an
expanded list of names. I think it should not be too
difficult
... to have the CSS WG adopt the SVG color keywords. I might be
wrong!
... On top of these we're just defining transparent, because
there's no alpha channel defined
... in the SVG keywords.
Mike: We have to be careful about
defining transparent because it is the initial value of
the
... tts:backgroundColor.
Nigel: I think we have consensus to get alignment with the CSS color set while not removing any existing colors.
Mike: I'm okay with that, if the goal is to better align with CSS.
Pierre: I'm not against it but I
see no advantage in adding "orange'.
... Recall that as long as there is a delta between CSS and
TTML a lookup table is still needed.
... I would rather not touch it.
Nigel: I think it's about direction of travel.
Pierre: Adding "orange" now would
cost implementors time for no benefit, because we still
... wouldn't be aligned with CSS, so that's no benefit now.
Nigel: I can see that, maybe we
should go to CSS WG and ask them to align named colors
... with SVG, and then defer any change to TTML until that
decision has been made.
Cyril: I like that.
Pierre: +1
SUMMARY: We will not add "orange" now but ask CSS WG to align named colors with SVG and then look at this again.
github: https://github.com/w3c/imsc/issues/262
Nigel: this is also about
imsc#260
... The issue here is about the differences between IMSC 1.0.1
and IMSC 1.1 and about region constraints.
Pierre: The idea is to say IMSC
1.1 is IMSC 1.0.1 verbatim unless there's a divergence.
... Whatever text helps I'm happy to put that in.
Cyril: In the light of the
discussion on TTML2 we will need to change that section.
... We said we'd go for a model where IMSC 1.1 imports features
from IMSC 1.0.1 and TTML2
... and the IMSC 1.0.1 extensions to TTML1 are deprecated where
there are alternatives in TTML2.
Pierre: That's a different issue but yes.
Cyril: The compatibility with 1.0.1 documents is true but is not always the preferred way, in the case of deprecations.
Pierre: #260 is handled by the appendix [L2]
Cyril: The pull request is okay to satisfy the two issues.
Pierre: except for Nigel's
concerns about the new text.
... If we removed that new text would the issues still be
addressed?
Cyril: I would prefer for each section a sentence saying "this is the same as in IMSC 1.0.1"
Pierre: We don't do that in TTML,
and some sections are numbered.
... Purely for an implementor, they should be able to review
the differences.
Nigel: Can I propose a minor
change of wording, to:
... Relative to [ttml-imsc1.0.1] any additions or deprecation
of features are summarised at Appendix L.
Cyril: Okay, good.
Pierre: Fine with me. I'll change it.
Cyril: I'll raise a separate issue to clarify the relationship with TTML2 in the Abstract, so it doesn't get lost.
Pierre: OK
SUMMARY: Update wording in Abstract.
github: https://github.com/w3c/imsc-vnext-reqs/issues/2
Nigel: I was able to ask someone
from NHK in Japan about this yesterday and he provided
... a data point that in his opinion ruby on ruby is never
used. He did think there may be a
... use case for textEmphasis on ruby though.
Nigel: There's no issue for this
yet, but the ARIB-TT use case mixes image and text in the
... same document, and my contact at NHK said that's really
important for them, so this
... may be relevant for us thinking about image vs text
profile.
Mike: Currently that's forbidden
of course. At odds with this are all the changes we're
... making in IMSC 1.1, I think, that it will obviate the need
for image profile at all.
Nigel: Good point, however his
use case is that even in subtitles and captions they
place
... e.g. company logos next to the names, so imagine, say a
Dolby logo or a Nike swoosh etc
... placed next to the company name.
... Apparently this is a matter of reflecting current
practice.
Mike: That's an interesting
situation - taking it to the extreme we could merge the
two
... profiles.
... It would simplify the spec actually.
... In US closed captions there's a symbol that folk came up
with that doesn't exist in Unicode.
Nigel: Did they ask to add it to Unicode?
Mike: I don't think so. It's 2x
"C" characters in the symbol to represent closed
captions.
... These days people just use (CC). Anyway it would be a way
to implement it.
... It's an interesting use case to put a non-Unicode symbol in
on the fly.
Pierre: Another example I've been
given in SE Asia is a symbol for a ringing telephone when
... there's the sound of a telephone ringing. With a simplistic
left-right-left animation.
Mike: Sounds like we need to file it as an issue and discuss it more.
Nigel: Yes, I will.
Pierre: It would be really good to get ARIB to contribute.
Mike: Especially if we have to merge Text and Image profiles to achieve it.
Nigel: The same person suggested
one way forward is to try to add the caption characters
... into ISO 10646, which would have to be done quickly.
... My sense is that the status quo is not ideal but is
okay.
Pierre: It's not been a complaint so far.
Mike: Is there an issue for this?
Nigel: No, there's no action to
take until CLDR does something.
... The issue here is that IMSC 1 Appendix B refers to CLDR and
we asked Unicode to keep
... a record of code points commonly used in subtitles and
captions as part of the CLDR
... initiative, but they haven't really dealt with the request
yet, at least we haven't seen any
... usable outcome.
Nigel: OK, thanks everyone, see you next week. [adjourns meeting]