See also: IRC log
<scribe> scribe: nigel
Nigel: For today I think we
mainly will focus on TTML2 - there are a few marked for the
agenda, which we need to close off
... today if we possibly can.
... There has been activity on IMSC too - anything to discuss
there today?
Pierre: It's not urgent so can wait in the light of other things.
Nigel: Is there any other business that isn't TTML2, or particular points to mention?
group: [silence]
Nigel: Okay let's dive into TTML2 issues and pull requests.
github: https://github.com/w3c/ttml2/pull/651
Glenn: TTML1 didn't have content
profiles and referred to an abstract document type. So it uses
the profile attribute to
... drive.
Nigel: This is different. Oh wait, maybe it isn't. [thinks again]
Glenn: The portion in item 2 of
the claims section is already in TTML1 regarding the
ttp:profile attribute. Here we just added
... the ttp:processorProfiles attribute and made a reference to
effective processor profiles.
Nigel: Ok I think I may have been misreading this.
Glenn: The goal of this as pointed out by Pierre is to address the fact that it did not take into account the new profile mechanism.
Nigel: Okay I see we are not
talking about processor conformance claims at all, just about
document conformance, and all
... that is required is to associate it with a content profile
or a processor profile.
... OK you've persuaded me, I'll approve this one. Apologies
the delay.
SUMMARY: @nigelmegitt to approve changes
github-bot, end topic
Nigel: Pierre was requested to review - are you okay for us to go ahead with this?
Pierre: Yes, no objection.
github: https://github.com/w3c/ttml2/pull/652
Glenn: It's good to remind
ourselves that the reason for this issue in the pull request is
that some time ago we added a note
... because a point was made that nowhere did we say anything
about the default value for begin. When we got into the
long
... discussion about timelines and so forth that you initiated
Nigel that came out of the discussion. But the language of
the
... note had some language "a default (implicit) value" and
someone asked about the (implicit) and it was clear that it
could
... confuse the reader since SMIL mentions implicit, so we took
out the implicit and tweaked the wording to make it more
clear
... that it was specifying a default value a bit like in a DTD.
We could have everywhere we put begin, in the element
information
... item syntax, specified a default value that would be
compatible with the other places we've done that for attributes
but
... we didn't do that, probably because SVG and SMIL didn't do
it, they built the default into their processor. That was the
only
... real intent of this. Then Nigel pointed out that the value
0 is not syntactically correct and it needs to be something
like 0s
... so we made that change. The current text, if you look at
the ED today, the paragraph already says the semantics of
the
... begin attribute are defined by [SMIL 3.0] §5.4.3 ... so we
already define that. In the note we lead off with "As defined
by
... [SMIL 3.0] ... " which is not inconsistent. The most recent
suggestion by @palemieux to refer to SMIL when no begin
... attribute is specified merely repeats what was in the
previous normative paragraph although it focuses on "when no
begin
... attribute" but we've already said that those semantics
apply. In my mind it does not clarify for the reader what the
default
... value is without considering the interpretation of the
semantics of that value. I carefully wrote the note to avoid
saying
... anything about what the semantics of the default value are.
For such a simple change of a non-normative note we have
... spent a lot of energy on that one. The no-op is to do
nothing and leave the note as is with the word (implicit) in
and with
... the value of 0 without the s on it. We should at least
clarify that because if you follow through what the SMIL
document
... says you would eventually get a value of 0 which is not
compatible. At a minimum we need to say something but we
could
... go ahead and merge as is.
Pierre: My take on this is driven
by the many hours spent trying to understand how TTML and SMIL
work together. There is
... already a sentence in SMIL that says that children of a par
begin equivalent to 0 seconds.
Glenn: SMIL is inconsistent there.
Pierre: It's a note in SMIL 3. I would either just point to that note, or copy it verbatim. I would not try to reinvent things here.
Glenn: Why does SMIL say in the normative text 0 and then have a note that says 0s?
Pierre: I don't know. My
encouragement is to copy and paste the informative note that we
like in SMIL because then we're
... consistent with SMIL and don't invent a third way.
Glenn: Do you think what's proposed here is inconsistent with SMIL 3?
Pierre: What I don't like is the notion of a default value, which is not a defined term in SMIL. There's no default as far as I can tell.
Glenn: The text in §5.4.4 defines the default value.
SMIL3 definition of default for begin
Pierre: I think this is really unfortunate. We should copy the informative note that says what we want.
Glenn: I think the note says what
we want and is not inconsistent with SMIL in that it does not
override the semantics of SMIL.
... It does the job for the reader. I noted a while ago that it
requires the reader to chase down text in SMIL 3 - even you
[pierre]
... hadn't found that yet.
... [summarises https://github.com/w3c/ttml2/pull/652#issuecomment-395288250]
... The point of this was to help out the reader not to make
them do this chasing and miss information.
Pierre: The issue is that saying the default value is 0s is not the full story.
Glenn: Of course, and that's why I don't want to paraphrase what it means to say 0s.
Pierre: I think the note is unhelpful.
Nigel: Is it misleading or wrong?
Pierre: It oversimplifies
something that's a lot more complex.
... Clearly removing (implicit) corrected the defect in the
ticket, so that's essential.
Glenn: Right, and the second change was to change 0 to 0s after Nigel noted that it was inconsistent with TTML.
Pierre: I think it's a bad note.
Nigel: I'm hearing that it
corrects the defect but that Pierre's concern is that it
doesn't direct the reader to see that there's more
... to it than just the default value.
Pierre: Right, I don't want to
paraphrase what SMIL already says.
... I don't want to change the normative text. If nobody else
thinks its a bad note then go ahead.
... I'll remove my review that blocks this.
SUMMARY: Pull request resolves the defects in the issue, so proceeding. Concern registered that the note may not direct the reader to the full complexities, however they are normatively present.
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/770
Nigel: #796 has pull #810 open
with two approvals and no changes requested so for the purpose
of discussion I think it
... can be considered resolved.
... That pull request modifies the behaviour of
luminanceGain.
Glenn: The only issue in my mind at this point is if we can refer to a WG note normatively.
Nigel: We simply don't need
to.
... There's an ITU ref for HDR.
Pierre: This is for HDR
PNG.
... My suggestion is we split into two.
Nigel: luminanceGain does not need PNG
Pierre: That's why I don't mind pushing the png hdr feature into a separate pull request that may not be approved in time.
Glenn: If we're going to make the decision to take out the feature we should close the issue.
Pierre: I can take the action
item to reach out to Mike to see how to make progress on #695.
In the meantime
... we can close #694.
Glenn: Okay so I will just remove
the aspects of this pull request that deal with #695 and
comment it in the notes of the pull
... request. Then we should be able to approve that right away
I hope?
Pierre: The PNG part, absolutely.
Glenn: Then we can consider whether to close #695 without further action separately.
Pierre: That's what I'm proposing.
Glenn: I'm fine with that.
... I want to wrap up #695 in the next day or two.
Pierre: We're waiting to hear back from @plhegar
Glenn: The issue is do we want the feature at all.
Pierre: Mike Dolan wants one, and I think it's in use today so it would be useful.
Glenn: I think so, and it's in IMSC 1.1, right?
Pierre: Just informatively.
Glenn: Maybe it is in the requirements document for IMSC vNext.
Pierre: I don't know, I can
follow up with Mike and others possibly regardless in a sense
of what Philippe comes back with.
... Maybe there's a way to mention it informatively. We can
close #694 today.
Glenn: Okay I have to do a little work but I can do that right away after the meeting.
Nigel: +1 to this suggestion from
me.
... Objections to closing #694 with this pull request and
dealing with #695 separately?
RESOLUTION: Modify this pull request to deal with #694 only.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/779
Glenn: We don't have a pull
request for this issue. The lingering question from Pierre is
how does an author come up with
... a value for length in rubyReserve. I pointed out that in my
opinion it is the same issue with a length for lineHeight,
and
... if you do specify a length then the language is clear and
the implementation aspects are clear for what that means. I
don't
... believe there's any substantive issue in using an actual
length value there.
... Then Nigel had a follow-on comment to Pierre earlier
today.
Pierre: On the first point I
think it is different than lineHeight because lineHeight does
not set the inter-line distance, as we
... have discussed many times before, whereas this sets a hard
value.
Cyril: About the fact that lineHeight does not set the inter-line distance, is that agreed?
Glenn: It goes to the definition
of per-inline-height-rectangle in the section on line areas in
XSL and whether or not one
... increases the line height on a per line basis if something
is larger than the line height value. If you look at the way
that
... line height is implemented in browsers, if you do specify a
line height then it sets it only once so it is the inter-line
distance
... effectively.
Pierre: That's not my experience with ruby, the line height changes.
Cyril: In Burlingame @fantasai said that you have to increase the line height because CSS does not do that.
Pierre: Not in Firefox.
Cyril: If you don't specify lineHeight then the distance between lines is implementation-dependent, right?
Glenn: We have an algorithm in
lineHeight for computing the nominal inline rectangle height
associated with every line, then
... on top of that you have the application of the line
stacking strategy that we say applies in the flow
transformation section,
... which says per-inline-height and XSL says that translates
to what CSS does and I believe that's true although some
implementations
... of CSS might not follow that exactly. Some things are
implementation dependent but it depends what version of CSS
you
... look at. Going back to CSS2 there was discussion of how you
discuss the nominal inline height rectangle based on the
... paragraph and the font metrics from the list of font
families that you resolve to. That text from 1998 has been
progressively
... elaborated and extended to make it more clear. The latest
CSS 2.2 ED is much closer to what is more carefully
articulated
... in XSL so if anything it is getting closer to XSL not
further away.
... That doesn't mean that implementations are consistent in
this matter. Even putting ruby aside, which is not really
specced
... out and there's not much in the way of implementations,
there are still differences in how CSS browsers like Chrome
vs
... Firefox are handling the most simple aspects of
lineHeight.
... There's still more variation in terms of CSS
implementations.
Nigel: Rewinding the stack, Cyril are you clear?
Cyril: As much as I'm going to be.
Pierre: My second point was
already covered. If ultimately the only way to do this is to
specify an absolute additional space,
... (the value "normal" should be left completely to
implementations because right now the computed length is
related to the
... used line height value and that's not available in a CSS
implementation where line-height is normal)
Glenn: One solution would be to say that if the length is not specified in rubyReserve then it is implementation dependent.
Pierre: That would address my
second point. I'd like to go back to the first point and see if
we can think of a way to
... help the user.
... When there's an explicit length, I'm trying to avoid having
the author need to play with values until it "kind of
works".
Glenn: Don't you have to do the same for lineHeight?
Pierre: Most authors use "normal" and are happy with what they get - it "just looks good", literally.
Nigel: Can we stick to rubyReserve for now - the fact there may be a problem with lineHeight too is separate.
Pierre: Can we think of a better way of doing this?
Glenn: I don't mind but after TTML2
Pierre: This is going to be a real obstacle for authors.
Glenn: I understand about dealing
with length when it is explicitly specified, from a CSS
perspective, but TTPE just increases
... the line height above or below by the specified amount,
depending. You have to take into account the ascender and
descender
... and half-leading for the inline areas. It's easy to figure
out the maximum and add it above for ascenders and below for
descenders.
Pierre: you can't do that in CSS
Glenn: I agree we have specced out things that can't be done easily or at all in CSS. That's a different issue.
Pierre: It's an important data
point - if it can't be mapped to CSS then it won't be
used.
... There are other features that are painful to implement but
can be done. This here just can't be done.
Nigel: Do we need to support it,
in which case we need an issue on CSS, or does CSS do it a
different way that we should
... adopt?
Pierre: CSS doesn't consider
this, the only suggestion is to reserve space by increasing the
line height. CSS does not have
... anything resembling rubyReserve.
Glenn: If you can divide your paragraph into multiple lines like you are already doing [in imsc.js]...
Pierre: That's different lines not different paragraphs.
Glenn: I think you can implement
this in CSS by doing line breaking then you divide into
multiple paragraphs CSS-wise and
... specify the line-height on each of those differently for
rubyReserve.
Pierre: You can't set above or below.
Cyril: Yes you'd have to change the baseline alignment also.
Glenn: There is a way to change the baseline offset in XSL, I'm pretty sure that can be done in CSS.
Pierre: I've not seen it.
Glenn: If the result is that some
space is reserved so that if you add or subtract ruby it does
not change the line spacing, then
... it might not look the greatest but it would work.
Pierre: I've implemented it by putting an empty ruby container at the beginning of each line.
Glenn: you insert `<br>`s?
Pierre: Yes
Glenn: So it's a ruby container with a strut?
Pierre: Exactly. That guarantees it is exactly as if a ruby were present.
Glenn: It sounds like you could support it then using that technique.
Pierre: Right, but if the
language for absolute length were worded where it was the
length of the strut in the ruby text line
... area, then that would work.
... I still think that even if it were possible to do this in
CSS I'm still not happy with the fact that the author has to
pick this
... absolute length. I'm trying to see if there is a better way
of doing it.
Glenn: One thing we could do is take out `<length>` completely.
Pierre: Yes, the only downside to that is that you can today override the "default" font size on ruby annotations.
Glenn: That was the intent of having `<length>` in the first place.
Pierre: My first inclination, in
the spirit of exploration, is to change `<length>` for a
font size. That does not take into account
... the exact font, decorations etc but that's closer to what
the author can specify. That was one thought.
Cyril: I don't understand about overriding the default size of ruby annotations.
Pierre: On the ruby text container you can set fontSize=200% and the ruby ends up twice as big as the base.
Cyril: Yes, and...
Pierre: That changes the size of the ruby text and therefore the amount of space that has to be reserved.
Glenn: I can see how this can be
handled for the default value, but not how it would help if you
specify an explicit length.
... If you would like to change an explicit length from being
an absolute value to being ..
Pierre: An 'em'
Glenn: Right, and act
accordingly, then that would not work if you had different font
sizes or different fonts generating
... different ruby text container.
Pierre: Or use emphasis on your ruby text.
Cyril: The way I'm using
rubyReserve at the moment is I'm setting it on div. You're
saying if the ruby font size is changed then
... that value would be wrong?
Pierre: Yes, I'm exploring how to make it easy for the user not to make a mistake.
Glenn: I'm willing to change the
semantics of length so that if you specify an absolute value
then have length not be absolute
... but pretend that this was the ruby font size used with all
ruby text in this paragraph and do it as though that were the
case.
Cyril: The maximum
Pierre: exactly.
Glenn: Then I would need to change the semantics of `<length>` as well.
Pierre: And the default has to be implementation dependent.
Glenn: Yeah... I'd like at least a note that suggests some approach.
Pierre: The reason I'm bringing
this up is I implemented the exact lineHeight="normal"
algorithm specified and the overwhelming
... feedback from users is that it was stupid and they
preferred what browsers do when line-height is normal.
... I like the idea of a note but unfortunately it should be
left to implementations.
Glenn: Even for lineHeight we have an algorithm that ascribes meaning to "normal".
Pierre: In practice that does not work. People expect normal to just look good, to have enough space for text. That's the bottom line.
Glenn: The note is "it's implementation dependent but make it look good"
Pierre: It's unfortunate. I don't know how to fix it. rubyReserve should be worded to give leeway to implementations.
Glenn: I'm interested to know if this would cause an implementation problem.
Cyril: I'll check with our guys.
Glenn: I'm happy to make a pass at making that change so implementers can review what Pierre is proposing.
Pierre: I'm happy to implement a straw man in imsc.js
Glenn: I'll get something
substantive out today or tomorrow.
... If we do this as a substantive change in TTML2 I expect to
ask for permission to merge at our next meeting.
... We have a publishing moratorium coming up, and that could
push us out even further.
Cyril: I'd like to ask that we do an early merge of all the pending merges, it is hard to review the final spec.
Glenn: I second that.
Nigel: I'm unclear of the status
of this proposal - are we saying we will prepare it and make
this a resolution, or have a go
... at doing it and then an implementation play before
confirming?
Glenn: We should do the former.
RESOLUTION: Change the interpretation of the
length component of rubyReserve to mean the font size of ruby
text for which reserved space is created.
... If the rubyReserve length component is not specified use
the default value of the ruby text font size computed from the
paragraph font size.
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/807
Glenn: As far as I can tell this is wrapped up but Nigel you want to talk about fontShear.
Nigel: The reason I haven't
approved this is because I took it that we were tidying up all
of fontShear, lineShear and shear
... and it looked as though we weren't there yet.
... One of the things I took from the discussion is that nobody
wants fontShear and that it cannot be done in CSS so
... it seems like the easiest fix is to remove fontShear.
Glenn: As I pointed out in lambdaCap there is a requirement for this.
Nigel: And you cannot shear a word individually in CSS, right?
Pierre: No you cannot.
Glenn: Popular word processors
provide a way to do this and it is not dependent on lines or
blocks but is on a per character
... basis.
Cyril: It is weird because they export CSS, so I wonder how they do that.
Pierre: What I've seen is they just use oblique
Glenn: Use of oblique could be a fallback.
Pierre: I don't know of anyone who will use fontShear for subtitles and captions.
Glenn: I have real world examples
of Japanese captions that do it on a per-character basis, where
some characters on a line
... have shear and some have no shear.
Pierre: Everyone I've asked has
been unable to provide a practical example, so I would love
(not facetiously) to see a real
... world practical example.
Cyril: We're trying to see if we are removing a feature because it might not be used. It is harmless to keep it.
Pierre: Yes, put it at risk and move on.
Glenn: I expect us to have two implementations.
Pierre: I don't mind keeping fontShear in TTML2.
Nigel: Okay, let's keep it.
<glenn> https://github.com/w3c/ttml2/issues/784#issuecomment-390849465
Nigel: Now moving to the example,
am I incorrect in thinking that glyph area fontShear should
result in glyph areas being
... spaced apart?
Glenn: The link I just added
makes that clear from the lambdaCap spec.
... It is true that if you have a boundary between different
shear values then to make it look good you have to do
something
... with spacing between that boundary. TTPE uses some
heuristics. Say you go from +ve shear to 0 shear. In a
horizontal
... layout you have slant to the right. If you did nothing then
there would be overlap at the boundary. In TTPE for glyph
or
... character widths it computes a different width just to
handle the boundary cases.
Nigel: Ok I see.
Glenn: I didn't want to dive that deep in the spec.
Nigel: Fine, so we're happy that
the examples are not incorrect.
... In that case all my comments are resolved so I'll
approve.
Cyril: I made one comment once
that the way we resolve the shear transformation is that 100%
translates to 90º and that
... resolves to an unresolved calculation. I suggested using a
formula instead.
Glenn: I didn't see that. Can we take that offline? That's a potential bug with the shear transformation section.
Cyril: It's purely editorial, I will send you the comment.
Glenn: I suggest you create an issue for that and we handle it as an editorial change.
SUMMARY: Following discussion, Nigel's change requests have been resolved.
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/815
Nigel: Why is this on the agenda?
Glenn: Because there are comments
but no approval.
... The last comment is to add a note - I wouldn't object to
such a note but I don't think it's necessary. In the interests
of
... moving on I'd prefer to get this approved now.
... We could add such a note in PR.
... It is strictly editorial.
Nigel: The more important comment is https://github.com/w3c/ttml2/pull/815#discussion_r193401615
Glenn: I wanted to say you could
support #extent-image without supporting
#extent-auto-version-2.
... I didn't want to force you to support all the values.
Nigel: Right, we're agreed on
that, but it's not clear at the moment, so I wanted to split
out auto on region from auto on image
... as two separate features.
Pierre: Yes please. The semantics are so different that it really makes sense.
Glenn: I was thinking of
#auto-version-2 as a mix-in feature - if you did not support
extent-image but you turned on
... auto-version-2 then that would apply to region and tt but
not image since image is not supported.
Nigel: But you have no way to say you support auto extent on image but not on tt and region.
Glenn: That's true, and we have
that situation in other places too, for example length-measure
implies support wherever a
... length is supported. All the length features are basically
mix-ins.
Nigel: I think it's a minor editorial task to do what I'm suggesting here.
Glenn: OK, I can do that.
... If we do that is there anything else on this that needs
more work.
Nigel: If we do that then it's particularly apposite to add the note I propose in https://github.com/w3c/ttml2/pull/815#discussion_r193402545
Glenn: How about we create `#extent-region-version-2` that implies auto support?
Nigel: That could work.
Glenn: I have enough to
proceed.
... If I get the pull request fixed today maybe you guys can
review it before the weekend.
Nigel: okay, thanks.
SUMMARY: @skynavga to address outstanding comments as discussed above.
github-bot, end topic
Glenn: Cyril proposed that we do
an early merge of outstanding pull requests.
... If we agree then I'll do it in the next couple of days.
Pierre: Can I propose that we go
for a new CR in two weeks.
... And issue a Call for Consensus today.
Nigel: We can't do that because there's work to be done.
Pierre: Can we make it contingent?
Glenn: I'm hearing a suggestion to run our review in parallel with the CfC for CR2.
Nigel: We have precedence for
that, but I can't issue a CfC for something that does not exist
yet.
... Can I suggest that the changes we agreed today are done and
we try to move all PRs by Monday, at which point I can
issue
... a call for consensus.
Pierre: That's okay.
... What we're saying is we're freezing the issues as of
today.
Glenn: Freezing them and still allowing new PRs on those issue.
Pierre: Right, and if all those PRs are merged on Monday, then initiate a consensus.
Glenn: And Nigel would make the call on Monday.
Nigel: That's right.
Cyril: I'm fine with that. Just to make sure, if we find editorial issues we can still address them during CR2, right?
Nigel: We have two windows here:
during CfC if issues arise as a result of the early merges then
they need to be addressed
... and could cause us to stop. After CR2 is published
substantive changes can only be made on the way to PR if they
are
... removal of at risk features, otherwise we need a CR3.
Pierre: I think it's important to go to CR2 as soon as possible.
Glenn: I agree
PROPOSAL: Merge outstanding pull requests on Monday with the intent of the Chair issuing a CfC for transition to CR2.
Nigel: Any objections?
RESOLUTION: Merge outstanding pull requests on or before Monday with the intent of the Chair issuing a CfC for transition to CR2.
Glenn: Thanks everyone for helping get through the issues.
Pierre: I'm available to help with the rubyReserve stuff.
Nigel: Thanks everyone! [adjourns meeting]