W3C home > Mailing lists > Public > public-tt@w3.org > June 2018

{minutes} TTWG Meeting 2018-06-14

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 14 Jun 2018 16:25:45 +0000
To: "public-tt@w3.org" <public-tt@w3.org>
Message-ID: <D7485560.5E9D2%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2018/06/14-tt-minutes.html

In text format:


      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

14 Jun 2018

   See also: [2]IRC log

      [2] https://www.w3.org/2018/06/14-tt-irc


          Philippe, Cyril, Nigel, Glenn, Thierry





     * [3]Topics
         1. [4]This meeting
         2. [5]TPAC 2018
         3. [6]TTML2 CR2 publication
         4. [7]Applicability of tts:rubyPosition when
            tts:ruby="text". ttml2#832
         5. [8]TTML2 open issues for wide review
         6. [9]Incorporate CSS advances into TTML vertical text
            handling ttml2#277
         7. [10]TTML2 CR2 wrap-up
         8. [11]IMSC v1.1 Requirements
         9. [12]Consider adding support for "before" and "after"
            annotation position imsc-vnext-reqs#23
        10. [13]Update tts:rubyReserve values imsc-vnext-reqs#25
        11. [14]Consider adding support for
            tts:rubyAlign="spaceAround" imsc-vnext-reqs#30
        12. [15]tts:fontShear should be tts:shear
        13. [16]Exclude support for blur radius in tts:textShadow
        14. [17]Miscellaneous editorial fixes imsc#388
        15. [18]IMSC 1.1 schedule
        16. [19]Meeting Close
     * [20]Summary of Action Items
     * [21]Summary of Resolutions

   <scribe> scribe: nigel

This meeting

   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

   group: [no other business]

TPAC 2018

   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.

TTML2 CR2 publication

   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

   Philippe: Because you're making substantive changes and the
   Director has to approve it.
   ... Only CR updates with substantive changes need a transition
   ... 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> [22]https://www.w3.org/2018/06/ttml2-cr-diff.html

     [22] 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
   ... 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.



     [23] 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

   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

   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
   ... 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.

Applicability of tts:rubyPosition when tts:ruby="text". ttml2#832

   github: [24]https://github.com/w3c/ttml2/issues/832

     [24] https://github.com/w3c/ttml2/issues/832

   Nigel: This is a request for a substantive change concerning

   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

   Nigel: Pierre raised the issue, Glenn opened a pull request,

   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

   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.

TTML2 open issues for wide review

   <glenn> [25]https://github.com/w3c/ttml2/milestone/3

     [25] 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
   ... For issue #277 that's one for us to discuss.

Incorporate CSS advances into TTML vertical text handling ttml2#277

   github: [26]https://github.com/w3c/ttml2/issues/277

     [26] 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

TTML2 CR2 wrap-up

   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

IMSC v1.1 Requirements

   Nigel: Pierre, I see we have a few issues open.

Consider adding support for "before" and "after" annotation position

   github: [27]https://github.com/w3c/imsc-vnext-reqs/issues/23

     [27] 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
   ... After some digging, I think that's optimised for 2 line
   ... 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

   github-bot, end topic

Update tts:rubyReserve values imsc-vnext-reqs#25

   github: [28]https://github.com/w3c/imsc-vnext-reqs/issues/25

     [28] 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

   github-bot, end topic

Consider adding support for tts:rubyAlign="spaceAround"

   github: [29]https://github.com/w3c/imsc-vnext-reqs/issues/30

     [29] https://github.com/w3c/imsc-vnext-reqs/issues/30

   Pierre: I just opened this after working on it for a couple of
   ... 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

   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
   ... 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.

tts:fontShear should be tts:shear imsc-vnext-reqs#24

   github: [30]https://github.com/w3c/imsc-vnext-reqs/issues/24

     [30] 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

   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
   ... 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

     [31] 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

   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

   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

   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.

Exclude support for blur radius in tts:textShadow imsc-vnext-reqs#27

   github: [32]https://github.com/w3c/imsc-vnext-reqs/issues/27

     [32] 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

   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

Miscellaneous editorial fixes imsc#388

   github: [33]https://github.com/w3c/imsc/pull/388

     [33] 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

   ... here.

     [34] https://github.com/w3c/imsc/pull/388#discussion_r195347251

   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

   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

   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

   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

   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

IMSC 1.1 schedule

   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

   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

   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
   ... Okay, that gives me good confidence.

Meeting Close

   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

Summary of Action Items

   [NEW] ACTION: Pierre to raise an issue with CSS WG requesting
   support for lineShear [recorded in
   https://www.w3.org/2018/06/14-tt-irc ]

Summary of Resolutions

    1. [35]Set TTML2 CR2 deadline for comments at July 26th 2018
    2. [36]Close without marking sideways as at risk
    3. [37]Support `"before"` and `"after"` values for
    4. [38]Support `#rubyReserve` without additional constraints

   [End of minutes]

    Minutes formatted by David Booth's [39]scribe.perl version
    1.152 ([40]CVS log)
    $Date: 2018/06/14 16:21:47 $

     [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [40] http://dev.w3.org/cvsweb/2002/scribe/



This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Thursday, 14 June 2018 16:26:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 14 June 2018 16:26:14 UTC