W3C

Timed Text Working Group Teleconference

07 Jun 2018

See also: IRC log

Attendees

Present
Nigel, Cyril, Pierre, Glenn
Regrets
Andreas, Thierry
Chair
Nigel
Scribe
nigel

Contents


<scribe> scribe: nigel

This meeting

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.

Agenda topics for TTML2

Update requirements for claim of document (content) compliance (#495). ttml2#651

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.

Resolve confusion between default and implicit (#590). ttml2#652

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

Add features for standard and high dynamic range PNG images (#694, #6… ttml2#770

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

tts:rubyReserve length component semantics ttml2#779

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

Add tts:lineShear and tts:shear style attributes (#784). ttml2#807

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

Further refinement of features (#814). ttml2#815

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

TTML2 Pull Request early merges

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.

Meeting Close

Nigel: Thanks everyone! [adjourns meeting]

Summary of Action Items

Summary of Resolutions

  1. Modify this pull request to deal with #694 only.
  2. Change the interpretation of the length component of rubyReserve to mean the font size of ruby text for which reserved space is created.
  3. Merge outstanding pull requests on or before Monday with the intent of the Chair issuing a CfC for transition to CR2.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/07 16:09:59 $