See also: IRC log
<scribe> scribe: nigel
Nigel: I think we need to talk
about TTML2 CR2 publication, dates etc. as well as one or
two
... agenda-marked items on the repo.
... We also have some IMSC 1.1 agenda topics
Pierre: Start with requirements issues.
Nigel: Yes.
... AOB or particular other points to raise? I have TPAC to
mention
group: [no other business]
Nigel: You'll have in your
inboxes a message about registration which has just been opened
today.
... My request to resolve the clash between Media and
Entertainment IG and TTWG seems to
... have had no action taken and I've received no response, and
the clash remains on the
... published schedule for the Monday.
Pierre: FYI My attendance later
in the week has become impossible now so I have a strong
... preference for being done by Wednesday.
Nigel: I also talked to one of
the Chairs of the M&E IG who told me that their meeting
on
... the Monday is the traditional day but there's no other
reason for it.
Pierre: We should focus on
specific topics to cover in a joint meeting since moving
the
... meetings might not happen now.
Nigel: +1
<inserted> .. let's take that offline for now.
Nigel: I sent the CfC out
yesterday - a little later than agreed last week, but our
discussion
... last week did not cover the additional pull requests that
came along after the meeting,
... which took a bit of extra processing.
... The next question is, given the CfC end date, when can we
make the transition request
... and publish CR2.
Philippe: If you want to publish
on the 28th the trick is to send the transition request
on
... the 21st, with a note that the decision will be finalised
on [date]. I used that trick before.
Glenn: Why do we need a transition request if we're already in CR?
Philippe: Because you're making
substantive changes and the Director has to approve it.
... Only CR updates with substantive changes need a transition
request.
... Based on that I'd like to target the 28th June for
publishing. Is that a feasible date?
... If you send a transition request on 21st then yes it
is.
Glenn: Then that puts PR on
August 9.
... And the final Rec is sometime in September.
Philippe: Yes, the 13th to be exact.
Nigel: Who can take the action to draft the Transition Request?
Thierry: I can do that.
Nigel: Thank you
... If we can have a draft for me to look at say on Monday that
would be great.
Thierry: Okay
Nigel: Thanks for your flexibility there Philippe.
<plh> https://www.w3.org/2018/06/ttml2-cr-diff.html
Glenn: I just sent out a link to
a diff listing - thank you Philippe for sorting that manually
(the diff service is not working)
... It is actually between the branch where I'm tweaking the
CfC that has a pending pull request,
... with some minor editorial stuff there like the date on the
document and a couple of other
... little things. It's useful for doing a comparison.
Nigel: Thank you. I also want to make sure we have agreement on the earliest CR exit date.
Glenn: I made it August 9 for
entering PR.
... I'm not sure what the July date is - on your tool it listed
August 9 as PR entry.
Philippe: It also says deadline for comment July 26th.
<plh> https://w3c.github.io/spec-releases/milestones/?cr=2018-06-28&noFPWD=true
Nigel: We need to put that deadline for comments in the SOTD.
Philippe: The deadline needs to
be before you request transition otherwise it doesn't
make
... sense, and you need to request transition a week before you
publish.
Glenn: We didn't write deadline for comments in the SOTD
Nigel: We need to.
Philippe: Yes you need to make it
clear otherwise if you receive a comment a day after
... then you're in trouble.
Glenn: Okay I'll add that deadline if that's ok
PROPOSAL: Set TTML2 CR2 deadline for comments at July 26th 2018
Nigel: Any objections?
RESOLUTION: Set TTML2 CR2 deadline for comments at July 26th 2018
Nigel: I also asked if anyone has
any features to add to the at risk list, and since I've
had
... no responses, I assume there will not be any more at risk
features.
... Note that we have already added lineShear and shear
Glenn: I don't anticipate any
problem with those because we've already implemented them
... in TTPE in private, for presentation and validation and I
think that maybe Pierre has done
... something in that regard, maybe for IMSC. I anticipate
something from Netflix as well.
... I don't think either will be thrown out.
Nigel: Ok, sounds good.
... I think it's worth mentioning that the main change in your
as-yet-unmerged pull request
... is to add details of the changes since CR1.
Glenn: Yes, I made some progress
with that last night so that should be completed by
... next week's meeting.
Nigel: Anything else for transition to CR2 that I may not have thought of?
Philippe: No, I don't think so
for a CR2 transition. It should be a pretty simple
transition.
... You don't have to demonstrate that you addressed all of the
issues at this point.
Nigel: Thank you that's helpful.
Glenn: We have deferred some editorial changes to PR.
Philippe: Yes, you can do that.
Glenn: As I've mentioned to Nigel
I will be strongly opposed to any substantive change.
... Anything that looks like it is substantive has to be put
into a Note and made informative
... unless it is completely broken. I don't know of anything
that is hopelessly broken that
... we have to get into the text as normative text at this
point. Of course I can't anticipate
... what comments will come out of CR2.
Nigel: That's a good segue into the agenda item.
Glenn: There's just one.
github: https://github.com/w3c/ttml2/issues/832
Nigel: This is a request for a substantive change concerning rubyPosition.
Glenn: It is minimally
substantive but I think we can call it that. It's a change in
normative
... text that could impact conformance so it satisfies the
criteria.
Nigel: Pierre raised the issue, Glenn opened a pull request, #833
Pierre: It looks right to me. It
makes it invalid to specify position on a ruby text that
is
... within an explicit textContainer?
Glenn: Exactly, which covers the previous case that was documented.
Pierre: I will approve.
Cyril: I haven't looked at it
yet.
... I will do that.
Nigel: Glenn please hold off merging until Cyril has had a look a it?
Glenn: Sure I'll do that.
Nigel: I will treat this as
review feedback during the CfC period so I don't intend to
extend
... the CfC deadline based on this.
SUMMARY: PR Open, to merge early as a CfC feedback comment when @cconcolato's review is complete
github-bot, end topic
Cyril: I've just approved it.
Glenn: Great, I'll go ahead and merge it.
<glenn> https://github.com/w3c/ttml2/milestone/3
Nigel: I believe all those are with me for action.
Glenn: What's holding those up?
Nigel: Me being snowed under with
other things, is the answer.
... I need to send a disposition to SMPTE and another to Glenn
Goldtein.
... For issue #277 that's one for us to discuss.
github: https://github.com/w3c/ttml2/issues/277
Nigel: The status of this is that
we could mark sideways as at risk but do not have a
... feature designator for it.
... Any views?
Cyril: I vaguely remember we decided not to mark as at risk because it was implemented.
Nigel: OK I didn't recall that.
Cyril: Maybe Glenn mentioned it was implemented.
Glenn: Yes, we have all the current values implemented.
Cyril: Is there a risk to marking it as risk?
Glenn: No
Nigel: Two downsides:
... 1. Suggests non-implementation
... 2. Editorial work to add the feature designator
Cyril: I don't think the argument
for not inviting implementation is a practical problem
... given the current implementation status.
Glenn: I think it's unnecessary
work and we should not mark sideways as at risk.
... It's implemented.
Nigel: You have one implementation for it?
Glenn: I have a presentation
implementation and another member has a validation
implementation
... so it satisfies the criteria.
Nigel: Ok then we don't need to mark it as at risk.
Glenn: As a general comment I'm
worried about proliferation of feature designators. We
... went from around 114 to about 250, so we've doubled the
designators but we haven't
... doubled the number of features. Compared to TTML1.
Nigel: Can we resolve to close this with no further change?
Glenn: No objection
Nigel: Anyone else?
RESOLUTION: Close without marking sideways as at risk
github-bot, end topic
Nigel: I think that's all for
TTML2, barring the open editorial branch to complete the
changes
... etc.
Glenn: I'll leave that open for a
while to deal with other editorial points.
... [need to drop off now]
Nigel: Thank you
Nigel: Pierre, I see we have a few issues open.
github: https://github.com/w3c/imsc-vnext-reqs/issues/23
Pierre: Note that #25 may need to
change depending on what we decide for #23 here.
... Today IMSC 1.1 has requirement only for
rubyPosition="outside".
... After some digging, I think that's optimised for 2 line
presentations.
... My understanding is sometimes there are 3 lines, depending
on the authorial style.
... If they are anything other than 2 lines the author will
need more control than outside,
... and will need to position rubys before or after, so my
suggestion is simply to support
... before and after as well as outside for rubyPosition.
... From an implementation perspective there's more syntax but
in terms of layout it's
... kind of a no-op because before and after need to be
supported for outside anyway.
... This reflects feedback I have received.
Cyril: I have no objection. We
were proponents for outside but we don't have a problem
... with people using before and after if they want to. It's
not exactly a no-op for implementation
... but the cost is minimal.
Pierre: The risk is too great to not include.
Nigel: I think that's right, and
also would note that whatever syntax we accept for
... rubyPosition we also permit in rubyReserve.
Pierre: Yes.
RESOLUTION: Support `"before"` and `"after"` values for `tts:rubyPosition`.
github-bot, end topic
github: https://github.com/w3c/imsc-vnext-reqs/issues/25
Nigel: Now we resolved in #23 to support `before` and `after` we need to do that here.
Pierre: Yes, that removes the restrictions.
PROPOSAL: Support `#rubyReserve` without additional constraints
Nigel: Any objections?
RESOLUTION: Support `#rubyReserve` without additional constraints
github-bot, end topic
github: https://github.com/w3c/imsc-vnext-reqs/issues/30
Pierre: I just opened this after
working on it for a couple of days.
... The illustration is the best thing to look at.
... Today the only thing that's allowed is center, which is the
bottom illustration.
... The feedback I received is that it doesn't work when the
ruby base is very long, because
... bunching up the ruby text makes it less easy to read.
... The space around example (top example) is preferred.
Cyril: No objection, but the examples .. are they from a real example?
Pierre: I'm told this happens in real subtitles.
Cyril: Ok, I have no objection.
Pierre: I'd like more information
before finalising my own opinion. Cyril, I'll try to get
as
... many real examples as possible.
Cyril: I'll check with Netflix if we have any opinions and examples too.
Pierre: Thank you. Also there's a
subtle difference between spaceAround and spaceBetween.
... Right now my research says adding spaceAround would address
most of the concerns.
... What I hear this morning is there are no immediate concerns
to allowing it.
Cyril: To be on the safe side we
should maybe implement all values.
... Once you've implemented spaceAround and spaceBetween then
adding withBase is not
... that difficult.
Pierre: Yes, I don't know what
CSS supports other than spaceAround, which is the initial
value,
... so seems pretty safe.
Cyril: Do you prefer restricting
IMSC 1.1 to a limited set of values and then increasing
them
... later if there is CSS support.
Pierre: I'd rather go down that
path, it avoids misuse. It's not an easy question.
... Do please ask the question Cyril about supporting all of
them. If CSS supports all of them
... then that makes it a lot easier in my mind.
SUMMARY: Research continuing, consider adding all values if CSS supports them.
github: https://github.com/w3c/imsc-vnext-reqs/issues/24
Cyril: I think it should be
lineShear. I know it is not supported in CSS, because it
requires
... breaking lines into separate paragraphs, but lineShear is
what people expect in terms of
... rendering, in all the examples.
Pierre: The author can do that by creating two `p`s.
Cyril: The implementation can do it by breaking into `p`s.
Pierre: It's not simple, and it
means if you ever want block shear then you can't - you
can't
... have the flexibility to shear each `p`.
... I did ask about line breaks in Japanese subtitles and my
understanding is it is not acceptable
... to let line wrap wrap lines.
Cyril: That's not the case, we use that all the time.
Pierre: The feedback I received
is that authors want to control line breaks and you
cannot
... just break anywhere in Japanese.
Cyril: My concern is that using
multiple `p`s can mess up the timing. It makes the
document
... much simpler if you have one `p` per region or per
event.
Nigel: How are we going to figure this out?
Cyril: I think we need to gather
more feedback.
... Would it be an option so support both shear and
lineShear?
Pierre: Supporting lineShear is going to be extremely difficult.
Nigel: Because we're missing something in CSS?
Pierre: Yes it only allows shearing of blocks.
Nigel: Yes, I found that in my research too.
Pierre: The overall challenge is
turning a bunch of lines into a bunch of `p`s requires
... restructuring the entire span tree. With rubys on top of
that it's going to be hard to
... implement and also I suspect brittle. I don't want us to
underestimate the complexity
... of doing this correctly.
Nigel: I have a suggestion that
we raise this requirement with the CSS WG.
... I think the requirement is to be able to apply shear to
line areas.
Pierre: Yes, like many of our requests, CSS does not deal with lines, but we need to.
Nigel: Do we ever need to shear spans within a line?
Pierre: I'm not aware of that requirement
Cyril: Me neither - normally it is the entire line.
Pierre: I'm fairly certain that
tts:fontShear is not needed for subtitles and captions.
... Ideally both lineShear and shear would be supported, but
lineShear is challenging to implement.
... Is IMSC 1.1 broken if lineShear is not supported?
Nigel: My proposal is to support
shear for now, raise an issue with CSS WG for lineshear
... with the intent of adding support for it to a future
version of IMSC 1.1.
Pierre: I like that approach for
now.
... Also Glenn filed another issue recently with CSS recently
too, which we should track.
Nigel: I have a list in the agenda actually.
Cyril: One concern about shear is
what if the user changes the font size and suddenly you
... have line wrapping, then the alignment is not desired.
Pierre: If you shear as the
entire `p` is the result completely objectionable?
... For 2 lines there's a very subtle difference, but with 4
lines you see a pretty big difference.
... Not being Japanese, I don't know if the result is
unacceptable or just a bit strange or
... annoying.
Cyril: I'll come back to you on this one.
Pierre: Thank you, I will continue to dig on this too.
<scribe> ACTION: Pierre to raise an issue with CSS WG requesting support for lineShear [recorded in https://www.w3.org/2018/06/14-tt-irc]
<trackbot> Created ACTION-512 - Raise an issue with css wg requesting support for lineshear [on Pierre-Anthony Lemieux - due 2018-06-21].
Pierre: I think it is clear that
we will replace fontShear with shear, and deal with
lineShear
... separately?
Cyril: I'd rather make one pull request for the shear part.
Pierre: We know fontShear is bad so we need to address that now.
Cyril: Just add an editor's note to the pull request that we're considering adding lineShear
Pierre: Sounds like a good solution.
SUMMARY: @palemieux to raise an issue with CSS WG, and to add an ed note to the pull request to note ongoing query re lineShear.
PROPOSAL: Drop fontShear support and add shear support, with continuing consideration for lineShear
Cyril: We would prefer support
for lineShear but not shear. We don't think we are going
to
... use shear at all.
Nigel: OK I won't record a resolution for that.
SUMMARY: Continue to investigate options for using shear and lineShear
Cyril: I would suggest adding
both shear and lineShear and add a note to lineShear to
say
... we are investigating implementation difficulties given CSS,
and add a note to shear
... saying we are investigating line alignment issues. Then we
can add both and remove one
... or the other [or neither] later.
Pierre: That's fine with me
SUMMARY: Temporarily add shear and lineShear with editorial notes against both, pending a later resolution.
github: https://github.com/w3c/imsc-vnext-reqs/issues/27
Nigel: Looking at this, it seems
like there's good CSS support already for blur and some
of
... the examples of using a large diffuse shadow really need
blur to look good.
Pierre: The motivation here is that 708 does not support blur.
Nigel: Are you asserting that the requirement for subtitles is only derived from 708?
Pierre: Yes. For traditional subtitles text outline is used not text shadow.
Nigel: It would help if I could
dig out an example here but I am pretty sure I have seen
... examples that do use shadow. Requesting more time!
Pierre: Absolutely, that would help us make the right decision.
Nigel: In the meantime I assume
that the implementation cost is very low because you
... can just pass the blur value to CSS.
Pierre: I'm not worried about CSS
implementation here but I am worried about other
... implementation techniques, given why we support textShadow,
i.e. 708.
Nigel: We're not overall constrained by 708 for implementability.
Pierre: Right. If you could find examples that would be really good evidence.
Nigel: Okay I'll have a look.
SUMMARY: Continue to look for supporting use cases
github-bot, end topic
github: https://github.com/w3c/imsc/pull/388
Nigel: Given that Stefan and I have given feedback, what do we need to discuss in the meeting?
Pierre: I'd like to walk through
your feedback Nigel so we can close this and move on.
... It's important to merge this pull request to allow other
work to proceed.
... You've requested that features link back to
constraints.
Nigel: Yes, based on whether
there are conformance keywords, rather than just limiting
... to SHALLs and SHALL NOTs.
Pierre: Okay, I can deal with
that.
... There a bunch of things that you and Stefan noted that are
related to changes in TTML2
... but this pull request is not intended to address those. I
want to deal with the TTML2
... feature refactoring separately, and not address https://github.com/w3c/imsc/pull/388#discussion_r195347251
... here.
Nigel: Okay, have we got an issue open for it?
Pierre: We can open an omnibus issue - it's next on my list.
Nigel: Sure, I don't mind taking that approach to allow this to continue.
Pierre: [colour contrast question]
Nigel: If the answer is "no" you
haven't checked then fine, put that on and raise an issue
... to deal with it, then we can proceed.
Pierre: Okay, I can do that.
Nigel: [TTML2 prohibition comment] I think you mean introduced rather than specified?
Pierre: No, really everything in
TTML2. I think we should omit prohibited things. It's
been
... a source of errors when we tried to track features in TTML2
so it makes it easier to
... maintain if we just include features with some support, and
easier to read.
<inserted> Nigel: [TTML2 features comment]
Nigel: I think we need to include
all dependent features that are potential parts or
related
... to bigger "group" features even if they are in fact
prohibited, just for clarity. The
... `#extent-auto-version-2` comment above is a good
example.
Pierre: That makes sense, that will be done.
Nigel: We can move that into the TTML2 feature change mop-up issue?
Pierre: Yes, absolutely.
... I wanted to make sure that we didn't think that excluding
prohibited features is a
... bad idea. That is the major substantial change in this pull
request.
Nigel: Just testing the idea. Is
it clear and unambiguous? Yes.
... Is it helpful for implementers? Not sure.
Pierre: That's not clear to me
either.
... For authors it's much easier.
Cyril: It's easier from an
editor's point of view.
... I think I'm fine with that.
Nigel: One more point - the deprecation warning on ittp:progressivelyDecodable.
Pierre: I'll add that.
... If I make those changes we discussed will you be able to
approve them early tomorrow your time Nigel?
Nigel: Yes, I don't see why not.
SUMMARY: Pierre to make changes as discussed.
github-bot, end topic
Pierre: The moratorium is not at a perfect time, so it'll be hard to do a CR2 by June 28.
Nigel: We should stagger after
TTML2 so that we aren't hit in IMSC 1.1 by late
substantive
... changes to TTML2.
Pierre: Given the moratorium we
should plan for CR2 to be ready on July 17 when
publications
... resume.
Nigel: To request the transition then?
Pierre: No we should have on the Directors desk on July 17 the transition request.
Nigel: Then publication will be July 24
Pierre: Another moratorium begins July 25
Nigel: So we want publication in that window.
Pierre: Yes
Nigel: Thierry, what would you recommend to expedite this?
Thierry: I think we should get it
to the Director ahead of the "geek week" moratorium,
... during which there is poor availability for the team.
... We need both the transition request accepted and then the
publication in that window.
Nigel: Can we do a CfC on June 21
and make the transition request on July 5 to ensure
... we are good to publish in that window? Is that
feasible?
Pierre: If the CfC starts on June
28 then it ends July 12 and the transition request could
... be made on July 16.
Nigel: [concern about staff availability to draft transition request]
Thierry: I can help draft it
ahead of geek week, and we can use the trick that
Philippe
... mentioned for TTML2 earlier.
... Why don't I draft it for the 5th, then Nigel you and I can
talk through any issues on the 6th,
... then it can be submitted and be ready for the Director on
the 16th, and be published
... by the 26th (the last permitted date before the summer
moratorium).
Nigel: Okay, sounds like it would work.
Pierre: Ok
Thierry: So we should have a response on the 23rd and I can request publication on the 26th.
Pierre: Sounds like a good plan.
Thierry: Can you provide an ED close to the CR by the 5th?
Pierre: Yes, based on this plan the goal is to get CR2 ready by June 28
Nigel: +1
Pierre: Editorially that can
work, I think we have those issues regarding rubyAlign
and
... shear and I think that we will try to make progress
quickly. In the worst case we can
... add features and mark them as at risk. So it is
possible.
Nigel: Putting shear and
lineShear at risk would be an excellent way to give us time
to
... deal with those issues.
Pierre: Yes, and for rubyAlign
too, we could put some values at risk.
... Okay, that gives me good confidence.
Nigel: We've completed our agenda, thank you.
Pierre: Thanks for the great input on the issues.
Nigel: Great, let's adjourn! See you next week. [adjourns meeting]