- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 19 Oct 2017 16:21:14 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D60E8F4B.4C3D4%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/10/19-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
19 Oct 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/10/19-tt-irc
Attendees
Present
Nigel, Cyril, Pierre, Mike, David_Ronca, Thierry
Regrets
Andreas
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TPAC planning
3. [6]TTML1 and TTML2 compatibility in practice
4. [7]TTML2 Wide Review
5. [8]IMSC
6. [9]Add equivalent CSS properties to style attributes
#406
7. [10]Reference CSS color semantic #413
8. [11]Region constraints are the same as in IMSCvNext
#262
9. [12]Is #ruby necessary, or #ruby-non-nested
sufficient? #2
10. [13]IMSC vNext requirements
11. [14]CLDR
12. [15]Meeting end
* [16]Summary of Action Items
* [17]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
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
TPAC planning
Nigel: I don't think there's anything to do here? Not everyone
has put their names on the wiki yet.
TTML1 and TTML2 compatibility in practice
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.
TTML2 Wide Review
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>
[18]http://www.w3.org/AudioVideo/TT/tracker/actions/508
[18] http://www.w3.org/AudioVideo/TT/tracker/actions/508
Thierry: I don't think I've done that yet.
IMSC
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
Add equivalent CSS properties to style attributes #406
github: [19]https://github.com/w3c/ttml2/issues/406
[19] 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.
[20]Pull request
[20] https://github.com/w3c/ttml2/pull/470
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:
[21]https://rawgit.com/w3c/ttml2/178659af16ee4b8514adc7f16ea1ca
786fcf38a1/spec/ttml2.html
[21] 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.
Reference CSS color semantic #413
github: [22]https://github.com/w3c/ttml2/issues/413
[22] 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.
Region constraints are the same as in IMSCvNext #262
github: [23]https://github.com/w3c/imsc/issues/262
[23] 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.
[24]draft proposal
[24] https://rawgit.com/w3c/imsc/297dcb3f5aa35889029bb10e5def87ca089407aa/imsc1/spec/ttml-ww-profiles.html
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.
Is #ruby necessary, or #ruby-non-nested sufficient? #2
github: [25]https://github.com/w3c/imsc-vnext-reqs/issues/2
[25] 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.
IMSC vNext requirements
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.
CLDR
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.
Meeting end
Nigel: OK, thanks everyone, see you next week. [adjourns
meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [26]scribe.perl version
1.152 ([27]CVS log)
$Date: 2017/10/19 16:20:41 $
[26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[27] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 19 October 2017 16:21:40 UTC