- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 7 Jun 2018 16:10:54 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D73F168C.5E01C%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/07-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
07 Jun 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/06/07-tt-irc
Attendees
Present
Nigel, Cyril, Pierre, Glenn
Regrets
Andreas, Thierry
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]Update requirements for claim of document (content)
compliance (#495). ttml2#651
3. [6]Resolve confusion between default and implicit
(#590). ttml2#652
4. [7]Add features for standard and high dynamic range
PNG images (#694, #6… ttml2#770
5. [8]tts:rubyReserve length component semantics
ttml2#779
6. [9]Add tts:lineShear and tts:shear style attributes
(#784). ttml2#807
7. [10]Further refinement of features (#814). ttml2#815
8. [11]TTML2 Pull Request early merges
9. [12]Meeting Close
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<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.
[15]Agenda topics for TTML2
[15] https://github.com/w3c/ttml2/labels/agenda
Update requirements for claim of document (content) compliance
(#495). ttml2#651
github: [16]https://github.com/w3c/ttml2/pull/651
[16] 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: [17]https://github.com/w3c/ttml2/pull/652
[17] 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.
[18]SMIL3 definition of default for begin
[18] https://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-ParSyntax
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
[19]https://github.com/w3c/ttml2/pull/652#issuecomment-39528825
0]
... The point of this was to help out the reader not to make
them do this chasing and miss information.
[19] https://github.com/w3c/ttml2/pull/652#issuecomment-395288250
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: [20]https://github.com/w3c/ttml2/pull/770
[20] 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: [21]https://github.com/w3c/ttml2/issues/779
[21] 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: [22]https://github.com/w3c/ttml2/pull/807
[22] 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>
[23]https://github.com/w3c/ttml2/issues/784#issuecomment-390849
465
[23] 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: [24]https://github.com/w3c/ttml2/pull/815
[24] 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
[25]https://github.com/w3c/ttml2/pull/815#discussion_r193401615
[25] 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
[26]https://github.com/w3c/ttml2/pull/815#discussion_r193402545
[26] 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. [27]Modify this pull request to deal with #694 only.
2. [28]Change the interpretation of the length component of
rubyReserve to mean the font size of ruby text for which
reserved space is created.
3. [29]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 [30]scribe.perl version
1.152 ([31]CVS log)
$Date: 2018/06/07 16:09:59 $
[30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[31] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
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, 7 June 2018 16:11:27 UTC