See also: IRC log
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]
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.
Nigel: We have 2 pull requests open.
github: 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.
github: 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> 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.
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
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> 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.
Pierre: Can we talk about imsc#444?
github: 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.
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.
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]