IRC log of tt on 2018-06-07

Timestamps are in UTC.

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