- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 6 Sep 2018 16:41:08 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <D7B715E5.669B6%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/2018/09/06-tt-minutes.html
Please note we discussed the at-risk #lineShear feature of IMSC 1.1 and Pierre proposed to remove it; there were no objections. If you have a view on this please comment at https://github.com/w3c/imsc/issues/455
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
06 Sep 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/09/06-tt-irc
Attendees
Present
Glenn, Pierre, Nigel, Thierry, Cyril
Regrets
Andreas
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]Timeline check-in
3. [6]TTML1
4. [7]Move edition number to subtitle (#352) ttml1#353
5. [8]TTML1 3ED tests ttml1#361
6. [9]TTML1 (continued)
7. [10]TTML2
8. [11]IMSC
9. [12]Strictly negative = negative. imsc#444
10. [13]IMSC (continued)
11. [14]IMSC #lineShear and #shear features.
* [15]Summary of Action Items
* [16]Summary of Resolutions
__________________________________________________________
This meeting
Nigel: Today we should check against the timeline to see if
we're on schedule.
... In terms of discussion topics, I don't think there's
anything on the agenda.
Pierre: I'd like to suggest one that's relevant to the tests,
the issue regarding negative.
... I have some new thoughts regarding the tests that I think
is relevant to the tests
... themselves.
Nigel: We have one issue marked for agenda, but I'm not sure if
it should be, for TTML2.
... Anything else for today's agenda?
group: [silence]
Timeline check-in
[17]Specifications timeline
[17] https://www.w3.org/AudioVideo/TT/specs-timeline.html
Nigel: For TTML1 3rd Ed, today is the deadline for comments,
and I'm not aware of any.
... Is anyone else aware of any incoming comments?
group: [silence]
Nigel: Then I think we have no comments to respond to.
... The next step for TTML1 is to prepare the PR version for
review so I can issue a CfC.
... Obviously we need to have satisfied the exit criteria
before we can request the transition.
Pierre: That's a question I had - it sounded like the
implementation report has to be
... completed before the desired transition date.
Nigel: You mean the transition request date?
Glenn: I don't think so, it's not part of the CfC review
process.
... It does mean that for example for TTML2 I have 6 days to
resolve the outstanding
... PR issues, which are all editorial. I am going to need help
from folks to review and
... approve, and I need to submit them very quickly.
Nigel: Time flies!
Glenn: It does.
Pierre: On TTML1 I have 3 issues right now.
... One is just to match TTML2.
... Consider moving "3rd Edition" to a subtitle - are you
opposed to that?
Nigel: Let's come to those in the TTML1 agenda item.
... We don't necessarily need the draft for a CfC tomorrow if
we are willing to slip TTML1
... to match TTML2, as we agreed, but we do need a version
ready to go very soon, say
... in the next 6 days to match TTML2.
... Moving on to TTML2, we have 5 days of comment period
remaining, and the plan has
... me issuing a CfC for PR transition on 12 September.
... And the implementation report needs to be finalised on 27
September. Time is very
... tight for all of these.
... Lastly, IMSC 1.1 deadline for comments expired on 23rd
August, which we did not note
... last week. Again, I'm not aware of any incoming comments,
so there's nothing to respond to.
... There have been a lot of pull requests very recently for
IMSC 1.1 which are all now in
... an approved state I think. (need to double check) Do they
resolve all the open issues?
Pierre: There is only one that's unresolved, opened yesterday,
and there's a proposed
... resolution that makes sense so we can implement that today.
It's editorial I guess.
... It's really not substantive because the requirement that
was implied could not have
... occurred anyway.
Nigel: Yes.
Pierre: The only decision that the WG has to take is whether or
not to keep lineShear.
Nigel: Added to the agenda for today.
... Another thing to clarify is that we don't believe the test
suite has any entries in it.
Pierre: Correct.
Nigel: This will be much clearer I think to the Director if we
make the PR transition requests
... for TTML2 and IMSC 1.1 together, because all the referenced
test requirements are met
... by the TTML2 test suite.
... By the way, last week we discussed the CR exit approach for
TTML2 and I took an action
... to write to the Director informing him of our plans, and I
did that on Friday last week.
... I have received no response, which from the way the note
was drafted, suggests the
... Director has no concerns to raise with us about that
approach.
... Any other questions arising from the timeline?
... My summary is we're just about on target but it's very
tight.
Glenn: On TTML2 at least I'm confident that Skynav will have
finished all of its work on
... the test suite and the implementation for the IR. We are
awaiting at least one other
... implementation of transformation or validation
functionality. There are also a couple
... of items under audio that haven't been checked off yet.
Nigel: I've drafted presentation tests for the audio and am
wrestling with getting our
... implementation to recognise the test directory structure
properly. I'm now generating
... examples of the audio output to place with the test
material.
Glenn: I had another somewhat related question about audio.
Nigel: I was just going to mention our reference to the Web
Audio spec.
... I've been chasing on this - one of my colleagues at the BBC
Chairs the Web Audio WG,
... and he's told me that their WG meeting today has as the
main agenda topic to decide
... to publish the CR, in which case the transition request
should happen over the next few days.
... I'll provide an update as soon as I have one later today.
Glenn: As a minimum we need to update the Web Audio WD date. If
we go to PR with that
... still in it then we have some risk.
Nigel: Let's not take immediate action - if it turns out there
is no chance of that being
... published as a CR over the next couple of weeks we may need
to turn that into an
... informative reference.
Glenn: We only actually have an informative use of it in the
spec, it only appears in two
... notes, so technically we don't need to have a normative
reference.
Nigel: Oh, okay [slight surprise]
Glenn: [checks if the reference is informative already]
... It is already informative.
Nigel: Oh yes so it is.
Glenn: Then we do not have a technical problem, we can
reference a WD.
... The only thing I need to do is update the date in the
reference, at a minimum.
Nigel: OK, that's reassuring (in a way)!
Glenn: If they should happen to go to CR in the next 5 days
then we could always update
... it but it is not procedurally necessary.
Nigel: Yes, one of my targets for 2nd Ed would be to tighten
the audio references and semantics up somewhat.
TTML1
Nigel: We have 2 pull requests open.
Move edition number to subtitle (#352) ttml1#353
github: [18]https://github.com/w3c/ttml1/pull/353
[18] https://github.com/w3c/ttml1/pull/353
Nigel: This was assigned to Philippe who has not commented
further on it. There were
... two views on how we present the title and subtitle, and
Glenn was against making the
... proposed change.
... Glenn, has your position altered?
Glenn: No it hasn't.
Nigel: Anything more to add?
Pierre: I don't understand Glenn's position and think it would
be an improvement but
... let's not spend time on this.
Nigel: We don't have consensus here, so I'm going to declare
that we will not make the
... change in TTML1 3rd Edition.
... We can bump this to some v.next milestone while we await
further data points from
... Philippe.
Pierre: I will remove the milestone.
Nigel: Thank you.
SUMMARY: No consensus to adopt this proposal in TTML1 2nd
Edition, deferring until further data points are available to
support the change.
TTML1 3ED tests ttml1#361
github: [19]https://github.com/w3c/ttml1/pull/361
[19] https://github.com/w3c/ttml1/pull/361
Nigel: This was opened 29 days ago, and it took a while to
review. Looking at the review
... status, one person has requested changes, and that was me!
... Most of the changes I requested are minor.
Pierre: Are they all necessary?
Nigel: We need to check we have a shared understanding of the
intent of the zIndex text.
... I don't think the missing EOLs on the ends of the files are
a big deal.
... The use of single quotes around an attribute is not a big
deal.
Pierre: I think that must have come from the original TTML1
test.
Glenn: If a font family name consists of more than one token
then you need to quote it
... so you might see both sets of quote characters in that
attribute, the outer one for the
... attribute itself and the inner one for the family name with
multiple tokens.
... In this case there are no multiple token family names.
Nigel: Conversely there's no requirement to change it.
Glenn: That's right, ok.
Pierre: Can you propose a pull request for the
BrImplicitDuration.ttml test?
Nigel: It's just, as discussed, to change the backgroundColor
of one of the paragraphs.
Pierre: You wanted to change the text too?
Nigel: Oh, that's another solution, I think the background
color change is a more elegant
... solution to the same issue, and we don't need to do both
things.
Pierre: On Direction.ttml...
Nigel: We discussed this on 9th August, my proposal is just an
XML comment that
... explains that the test intentionally sets direction="rtl"
and that the text "Left to right"
... appears correctly that way because tts:direction only sets
weak directionality.
Pierre: Can you propose the comment text?
Nigel: Sure.
Pierre: The next one is about the hebrew text.
Nigel: I just added that comment as a note for posterity.
Pierre: I have proposed some alternate text that says "Right to
left" which is how the Hebrew
... text should appear (taken from Google translate)..
Nigel: Okay I'll check it out with an Israeli colleague.
... In PlainSpanImplicitDuration.ttml I suggested a small
wording change. Would that
... be an issue to make that change?
Pierre: That's good, I'll make that change.
Nigel: ZIndex.ttml is the next one.
Pierre: The issue is only about the stacking relative to the
root container so it does not
... matter if the regions do not overlap.
Nigel: I don't really understand this test - what is it
showing?
Pierre: "Does a region with tts:zIndex < 0 appear underneath
the root container?"
Nigel: What does that even mean?
Pierre: I don't know, what does it mean if a region has a
negative zIndex?
Glenn: The definition of zero is in CSS, a reference frame
(don't have it here). Negative
... indices are permitted in CSS. I don't remember what that
meant.
Pierre: The spec modification is about the root container
region establishing the root of
... the stacking context. The previous spec said "auto" was
defined by XSL 1.1 but did not
... state that the semantics for values other than auto were
also defined by XSL and it did
... not say that the tt element established a root stacking
context for scenarios other than
... zIndex being "auto". The new text says the tt element
always establishes a root stacking
... context.
Glenn: By the way if you go back to CSS 2.1 it says that for
integer types it always establishes
... a new stacking context and for auto it does not unless it
is a root element, so we needed
... to say what the root element was. It was only adding useful
information in the case of auto.
<glenn>
[20]https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#p
ropdef-z-index
[20] https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#propdef-z-index
Pierre: We've had this discussion, the issue is the previous
text did not state what was the
... root context.
Nigel: What does the text show?
Pierre: It makes sure that all those values yield to a region
that is displayed.
Nigel: Right, so the relative zIndex is not important, it is
just that they should all appear?
Pierre: Yes, that is how it is constructed.
Nigel: Thank you, I will propose text in the metadata that
states that, so people coming
... to this in the future can understand what we were
demonstrating.
... Is that ok?
Pierre: Yes, absolutely.
... The "left to right" data could be in the metadata too.
Nigel: Yes, I was thinking the same thing.
SUMMARY: Changes to be made over the next 24 hours.
Pierre: In terms of implementation, TTPE renders them all.
Glenn: I didn't check TTPE does too, but will do that ASAP.
Pierre: TTV already validates all of them, so the one that
would be ideal would be to check
... that TTPE does too, especially for two value font sizes.
Nigel: Ideally, since the changes don't affect validation, we
should have two presentation
... implementations for each change.
Pierre: We don't have a second implementation for two value
fonts.
Glenn: In Geneva I was able to run the old DFXP Viewer which
supported anamorphic fonts.
... We signed off on that for the initial IR for first edition.
Nigel: If that shows the behaviour we want, it would be good
enough.
Glenn: Why are we testing this?
Pierre: We made a substantive change in a way that we expect
matches implementations.
... I believe it should work with old implementations.
Glenn: Ok
... By the way that was a different organisation than Skynav at
that time.
... It was Extensible Formatting Systems Inc, XFI, which has
now closed its business.
... Skynav inherited the source code for it. The team that
implemented it is no longer with
... Skynav, although I was one of the implementers.
Pierre: When can we determine if we have a real problem here?
Nigel: I'd like to check there is no validation change.
Pierre: There is no validation change.
Glenn: This begs the question why we have the test here.
Pierre: We discussed this, the change is to clarify the intent.
Nigel: The Director asked for tests on the substantive changes.
... I wonder if the Flash player implements anamorphic fonts.
Glenn: You could ask Andrew Kirkpatrick.
Nigel: OK I'll send him a message.
Pierre: If there's no independent implementation of a
presentation engine with
... anamorphic fonts, what happens?
Nigel: We only need to show that existing implementations
already exhibit the clarified
... behaviour, that's why I've been asking about other
implementations.
Pierre: I'll see if I can drive DFXP Viewer to work with this
test.
TTML1 (continued)
Nigel: Those are both the pull requests; there are some open
issues with the 3rd Ed PR
... milestone, which I believe are editorial.
... We need pull requests for those.
Pierre: I can do that today.
Nigel: Fantastic, thank you.
... I think that's all on TTML1
TTML2
action-443?
<trackbot> action-443 -- Glenn Adams to Prepare a document
showing mapping arib ruby extension features to ttml2 for use
as a liaison document to arib. -- due 2018-08-09 -- OPEN
<trackbot>
[21]https://www.w3.org/AudioVideo/TT/tracker/actions/443
[21] https://www.w3.org/AudioVideo/TT/tracker/actions/443
ACTION-443: We are not going to be able to get a message to
ARIB at this stage in time for them to respond within the
deadline for comments.
<trackbot> Notes added to ACTION-443 Prepare a document showing
mapping arib ruby extension features to ttml2 for use as a
liaison document to arib..
Nigel: Given that we cannot grant ARIB sufficient time to
respond within the deadline for
... comments period I think it would be impolite to send a
liaison message at this time.
... I propose we close the action.
Glenn: I'm okay with that. I don't see ARIB in the member list.
Nigel: No, they're a liaison.
close action-443
<trackbot> Closed action-443.
Nigel: I see issue 695 is marked for agenda, but I believe it
is incorrectly labelled.
Glenn: Yeah, you're right, I've removed the label.
Nigel: Thank you.
... We don't have anything labelled for agenda.
Glenn: We have one open pull request for which we are awaiting
the timeout - it is
... approved so in the absence of an objection I plan to merge
that after the 2 weeks.
Nigel: Yes.
Glenn: If you think that any of the audio features will not be
covered by your work then
... I need a pull request to remove the relevant ones.
... I need to know soon, like tomorrow.
Nigel: Okay, my agenda for tomorrow is to run the tests through
my implementation and
... generate sample output so I will decide while doing that if
the features can all be supported.
Glenn: One other question, for Cyril.
... Do you have any estimate when Netflix will be able to check
the boxes in the appropriate
... column?
Cyril: No, I would say this week or early next week because of
the deadlines.
Glenn: Waiting until the last minute (27th September) would be
detrimental to out mental
... health!
Cyril: We have several implementations, I need to choose which
to show.
Nigel: You can register multiple implementations!
Cyril: I will try to fill that in at least partially this week.
... Stefan asked me what is the legend for the implementation
report. What is the
... colour code?
... I think there was a legend at some point but it isn't there
anymore.
Glenn: Green means verified and tested, yellow means "working
on it, partially implemented
... and that we have to finalise it".
Cyril: So Green is done, yellow is an intention.
Glenn: Yes.
Cyril: The next question was about the #v, #x, #t columns - do
we do that manually or is
... there a formula?
Glenn: If you add an entry then you should add to the count,
manually, and add the same
... number to #t to make the total come out correct.
Cyril: Thanks.
Glenn: I will go through and verify these numbers.
... The main thing to do is to add the entry into the
appropriate column, for example IRT
... SubCheck has a lot of entries there.
Nigel: Can we discuss non negative integers now?
Pierre: Having worked on some validation implementation, I'm
getting convinced that,
... let's take the case of tts:backgroundExtent, the expression
of the syntax is `<extent>`
... so that syntactic specification allows both positive and
negative numbers with unrestricted
... plus and minus signs. In the prose underneath the table, it
is stated that in case two
... <measure> values are used then both must resolve to
non-negative length. As an
... implementer I conclude that -0 is allowed because the
syntax is permitted but that from
... a value standpoint, not a syntactic one, the value has to
be non-negative, but that means
... that -0 resolves to 0 mathematically and therefore that's a
valid value.
Glenn: That seems correct to me.
... When I say it must resolve to a non-negative value the only
reasonable interpretation is
... that it refers to the semantic value not the syntactic one.
Pierre: We don't have to change anything now in the spec, but I
would say that the
... semantic values are constrained outside the table and is
based on the mathematical
... value rather than the lexical value in the "Values" row.
Glenn: We probably need to remind readers that if the lexical
value -0 can appear somewhere
... then it is semantic value zero, and then clarify the use of
the terms negative or non-negative.
Pierre: I do not think we need to spend any time on this now as
long as there are no
... tests where the lexical value -0 is used. We never run into
that issue.
Nigel: Does it have a wider implication for tests?
Pierre: As Glenn just confirmed, as long as no test uses -0 we
have no difficulties.
Glenn: Actually there are a number of places in the TTML2 valid
tests that has it:
... letterSpacing, gain, fontShear, disparity, pan, shear,
lineShear.
Nigel: I'm hearing that -0 is in the tests and is valid, so we
don't need to make any change, right?
Glenn: We are not clear enough. I will create an issue for 2nd
Ed to clarify this.
Pierre: The reason I'm raising it is in the light of the long
thread, we need to clarify it.
... "non-negative" is a named syntax that does not include -0
so it seems important to
... clarify that in the text the term "non negative" does
semantically include values from the
... syntactic expression "-0".
Nigel: Looking at TTML2 issues, there are 14 editorial issues
open with a target
... milestone of PR.
... Glenn, you have a lot on your plate - did you say you want
assistance on those?
Glenn: I need rapid reviews, I will post the pull requests in
the next couple of days.
... Please try not to nitpick in those reviews.
Nigel: It's all in the eye of the beholder!
... I think we've covered everything on TTML2 right now.
... Is now a good moment to transcribe the google spreadsheet
into a wiki page?
Glenn: It's being actively updated right now so let's wait for
it to settle down.
Cyril: I think it's too early.
IMSC
Pierre: Can we talk about imsc#444?
Strictly negative = negative. imsc#444
github: [22]https://github.com/w3c/imsc/issues/444
[22] https://github.com/w3c/imsc/issues/444
Pierre: Given the conversation earlier I think we don't need to
do anything right now.
Glenn: I concur.
Nigel: I propose to resolve to close with no change.
... Do we need an editorial change?
RESOLUTION: Close with no change.
IMSC (continued)
Nigel: Is there anything else for IMSC?
Pierre: I don't think so.
Nigel: I think we will need an implementation report page that
says "we've met exit criteria,
... all the new features are tested as part of TTML2"
Pierre: We have a wiki page. What do we need to say?
Nigel: I think we need to copy/paste the SOTD CR Exit Criteria,
and state that all new
... features are tested as part of the TTML2 IR test suite.
Thierry: We will remove the table.
Nigel: I was wondering if it would be helpful to copy in the
TTML2 tests, but that would be
... duplication.
Thierry: Duplication is always troublesome.
Pierre: I have update the above wiki page, please review.
Nigel: Looks good, there are some tweaks to make to the links,
and I might flesh the text
... out a bit.
Thierry: We could add the list of features targeted by the
sentence, the delta between
... 1.0.1 and 1.1.
Pierre: That's in the spec section L.2.5
... I can link to it.
Nigel: We can continue this offline.
IMSC #lineShear and #shear features.
Nigel: We need to decide if the at-risk #lineShear and #shear
features should remain or
... be removed.
... Any views?
Pierre: A couple of data points. Most importantly, it is
possible to achieve lineShear with
... only using shear if the author introduces explicit p
elements. So it is fair to say that the
... absence of lineShear is not fatal. It is not great
semantically in case there is word wrap,
... although unplanned word wrap in Japanese is already bad.
Glenn: Actually there is a well defined set of breaking rules
called kinsoku but I don't think
... we need to deal with them right now.
Pierre: They are not part of the TTML line breaking algorithm.
Glenn: We only refer to uax14 so whatever that does is what we
have specified effectively.
Pierre: My understanding is that in practice the desirable line
breaking goes beyond uax14.
Glenn: That's correct, we don't specify that anywhere and nor
does CSS.
Pierre: In Japanese, for TTML2, my understanding is that line
breaking is primarily going
... to be a manual affair and automatic word wrap will result
in undesirable effects, so although
... it is not ideal lineShear can be done with shear.
... The other data point is that implementing lineShear in CSS
is really unpleasant. It's
... more complicated than existing line breaking because ruby
containers have to be broken
... up and reassembled across lines.
Glenn: CSS is not clear here - in my mind line breaks inside a
ruby boundary are left
... implementation dependent.
Pierre: I agree. We may see some progress there, but in the
short term, realistically, it is
... unlikely that imsc.js will implement that feature. I have
pinged a couple of folks asking
... if lineShear is really important and I have not received
conclusive answers. I am personally
... leaning towards removing lineShear. If there is an
emergency we could add it back in to
... a future edition.
Glenn: TTPE internally has an implementation awaiting
integration into the public github.
... We will be reporting positive implementations of all three
shear features. That raises
... the question of if we want it in IMSC given the usage
expectation.
Pierre: Thank you, my argument for removing it is not based on
lack of implementation.
Glenn: I have no opinion on whether to include or exclude it
from IMSC.
<tmichel> I must go to another meeting. sorry.
Nigel: I have no opinion either.
<tmichel> bye.
Pierre: One option is that the outcome of this meeting is to
state which feature we plan to
... remove and there's only lineShear I think. If somebody
really has a strong reaction they
... have a short time to respond.
Nigel: Cyril, you're probably one of the more likely users.
Cyril: I don't have a strong opinion. I agree with Pierre that
you can probably do without
... lineShear if you introduce separate paragraphs, but line
wrapping... I have to think about it.
Glenn: As you're aware Cyril, the cap format uses fontShear as
opposed to lineShear and
... that's implemented in TTML2 and TTPE so I don't know what
requirements you have for
... doing lineShear or shear at the block level.
Cyril: As I said earlier the behaviour of fontShear is not
acceptable. We need either block
... shear or lineShear.
Glenn: Right, it's confusing now what's needed and what's
available.
Cyril: I agree, our implementation does block shear and line
shear now, but the difference
... would only be visible on edge cases.
Pierre: I have to chair another meeting. My proposal is to
remove lineShear to give folk
... a chance to respond.
Nigel: I will highlight this in the minutes email.
Pierre: I checked DFXP Viewer and it does not support two value
font size so we have an issue. I will continue this offline.
Nigel: Thanks, we're out of time for today. [adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [23]Close with no change.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [24]scribe.perl version
1.152 ([25]CVS log)
$Date: 2018/09/06 16:35:31 $
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[25] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 6 September 2018 16:41:35 UTC