- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 12 Jul 2018 16:23:30 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D76D3A42.61594%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/07/12-tt-minutes.html
Please note the following proposal:
PROPOSAL: Base the meeting time on UTC rather than Boston time for future meetings, i.e. 1400 UTC every Thursday.
If there are no objections by July 26 I will consider this proposal to be a resolution and action it; I will also look at ways to send a meeting invitation to assist with getting this in calendars at the right time.
Additionally, we made one resolution:
RESOLUTION: After the editorial tweak to #355 agreed above, merge #355 and #356 early and generate a CR2 draft for review with intent to request transition after the normal 10 working day period.
When those tweaks are made I will issue the call for consensus, which will have the normal duration according to the Decision Policy in our Charter.
Those minutes in text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
12 Jul 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/07/12-tt-irc
Attendees
Present
Andreas, Nigel, Cyril, Glenn
Regrets
Thierry
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TTML1
3. [6]Update tts:lineHeight='normal' algorithm to match
TTML2 ttml1#355
4. [7]TTML1 3rd Edition CR2
5. [8]IMSC 1.1 CR2
6. [9]Future meetings timings
7. [10]TTML2
8. [11]Unicode bidi should probably not be animatable.
ttml2#881
9. [12]Clarify that construct effective
{content,processor} profile is performed only once.
ttml2#860
10. [13]Clarify that [validate document] may produce false
positive results. ttml2#876
11. [14]text profile should support anamorphic fonts
imsc#419
12. [15]tts:origin/tts:position constraint applies to Text
profile only imsc#418
13. [16]lineHeight restriction should not preclude using
the initial element imsc#420
14. [17]Address draft CR2 comments imsc#417
15. [18]IMSC 1.1 CR2
16. [19]TPAC 2018
17. [20]Meeting Close
* [21]Summary of Action Items
* [22]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Andreas: If there's time I'd like to discuss switching this
meeting to be based on UTC time
Nigel: OK
... I think we have limited W3 staff availability so probably
that means regrets from Thierry.
... For the agenda today, we have the usual TTML1, TTML2, IMSC
1.1.
... Any particular points that anyone wants us to make sure we
cover, or other business?
... (noting Andreas already raised another business agenda
item)
group: [silence]
Nigel: Okay, we'll handle the Other Business at the end.
TTML1
action-513?
<trackbot> action-513 -- Pierre-Anthony Lemieux to Look at
ttml2 backporting to ttml1 3rd ed to see if we can change the
ref from ttml2 to point to 3rd ed. -- due 2018-07-05 -- OPEN
<trackbot>
[23]https://www.w3.org/AudioVideo/TT/tracker/actions/513
[23] https://www.w3.org/AudioVideo/TT/tracker/actions/513
Nigel: Just a quick update that earlier today I managed to ask
Philippe about if it would
... be possible to make an update to TTML1 3rd Edition CR that
incorporates text
... already subject to an exclusion request from TTML2 without
causing the TTML1
... 3rd Edition Rec date to be pushed out beyond TTML2 Rec.
Pierre: All the outstanding backport changes are in pull
requests on TTML1 3rd Ed.
... I couldn't find any others.
Nigel: Okay, thank you.
Action-513: Pierre reports All the outstanding backport changes
are in pull requests on TTML1 3rd Ed.
<trackbot> Notes added to Action-513 Look at ttml2 backporting
to ttml1 3rd ed to see if we can change the ref from ttml2 to
point to 3rd ed..
Cyril: Q: Why are we considering the change to TTML1 3rd ed ref
to be substantive?
Nigel: We're not - the concern is that the TTML2 Rec
publication could be delayed if we
... have to wait for TTML1 3rd Ed to be at Rec.
... I'm hoping for a response early next week.
Cyril: What are the options?
Nigel: In an ideal world we would be able to publish both TTML1
3rd Ed and TTML2 Rec at the same time.
Cyril: That'd be great.
Glenn: The question is when - at the same time as TTML2 Rec is
currently on track for publication, or with some delay?
Nigel: Exactly.
Glenn: As a reminder, due to a question I had fielded, TTML2
now normatively references
... TTML1 because we reference it in 117 places normatively, 3
places for DFXP profiles
... and 114 places where we refer to TTML1 feature definitions.
Cyril: We're doing that for convenience, right, not because we
need to.
Glenn: The problem is it was hard to define the feature
designators in TTML1 without
... incorporating the whole text of TTML1 so we had to resort
to referring to them directly.
... We don't copy the DFXP profiles into TTML2, but refer to
the normative definition in TTML1.
close action-513
<trackbot> Closed action-513.
Nigel: Looking at TTML1 pull requests, there's one for
lineHeight="normal" text and
... I see that Andreas a concern.
Andreas: Yes, I've been away for a while and have now reviewed
it.
... I have a concern that the algorithm can not always be
followed.
... The algorithm might not have access to the font properties
of a font file, which would
... be needed. And secondly if the text is kept as is then some
terms need to be clearer.
... It is not unambiguous how altitude and descent are used.
Glenn: Text altitude and text descent are defined properties
and traits in XSL-FO and
... are referred to in CSS 2.1 under the behaviour for
line-height so I don't think there's
... any problem there.
... Re font metrics, the language is based on the availability
of access to those, and if they
... are not available then the 125% applies, so that's also
okay.
... The only place where I contemplate it might not be
available is with bitmap fonts which
... might be restricted in what metrics are available.
Andreas: I recently discussed with CSS people why some
calculations are not available
... in the browser or developer console especially the font
that is used for rendering.
... They explained that it is not available to the browser
stack because it is handled by
... a lower level in the OS so I am not really sure that it is
available.
... With altitude and descent I am not happy with that.
Normally ascender and descender
... are used and even in XSL-FO it is not always clear what it
is because in OpenType
... for example there are different general properties for
ascender and descender so it
... is not clear which is meant. The text used here is not in
XSL-FO or CSS so it is not a
... reference to those specs at all.
Glenn: I would invite you to re-read CSS 2.2 §10.8. I don't
think there's any real ambiguity.
... Regarding referencing a specific font format we don't want
to do that because it ties
... too much to implementation specifics.
... Whoever you talked to maybe didn't understand the specifics
- all of the browsers do
... in fact have access to low level font information. I've
reviewed the code in Chrome and
... Firefox and they are using them directly.
Andreas: Ok I don't think we will come to a conclusion here but
we need someone more
... familiar with browser development. The other thing is we
have introduced new text,
... in general the text is okay but it introduces some more
complexity. Possibly it would
... have been easier to just take what is in CSS than to
introduce a new algorithm.
Glenn: One important thing is the way we crafted the language
in that algorithm, in step
... 5 or 6, it says "unless there is an implementation
requirement ..." use 125% as a fallback
... so that leaves the implementation free to decide what it
wants to use, and can apply
... its own rules. So there's no technical problem with the
algorithm that prevents an
... implementation from doing what it wants.
... The CSS folks have said at least half of what is written in
CSS is wrong and they have not
... decided which half is wrong.
Andreas: Okay that does not help!
... I do not want to block publication. A minor tweak is to
make the algorithm or 125%
... equivalent. At the moment the preference is to use the
algorithm. It only gives
... a fallback option if the font details are not available. It
could be made clearer at the
... beginning that either option can be chosen.
... You can also add the constraint that in case there is no
implementation specific
... requirement to do otherwise then you could use the
algorithm or 125%.
Glenn: I'm looking now, and step 5 says if the font is
associated with ... then lh is set
... accordingly, otherwise step 6 says implementation
dependent, but in the absence
... of implementation specific requirements, use 125%. The way
that language is specified,
... font metrics are not required, and implementations can
define their own behaviour or
... use 125%. I don't see any problem with the algorithm in
implementing it or its intention.
... By the way Pierre and I carefully reviewed this and came up
with it as a compromise
... to deal with another issue so I am very reluctant to tweak
it any further.
Pierre: I think all other things being equal, my preference
would be to say it is implementation
... dependent, period, but doing that will result in a pretty
drastic change in TTML2 so
... I'm not sure that is possible right now or desirable.
There's a note that says the goal
... is to be consistent with CSS. If we find it is not
consistent then it would be easy to
... motivate a change. I think this text is an improvement to
TTML1 2nd Ed for sure.
Andreas: I agree with Pierre, to leave it completely
implementation dependent would be
... the easiest because other things confuse people more. If
there is not a strong
... opinion or support to change it then leave it as it is. I
would definitely look up the
... terms and possibly change those if necessary.
Pierre: If you want to capture what it should be as an issue
then that could be addressed
... in a future edition.
Andreas: At least in step 5 it is a minor change to tweak the
terms. Is that still feasible
... or is it too late?
Nigel: In TTML1 and TTML2?
Andreas: Both
Cyril: I think it is too late.
... I don't think it is a problem because IMSC recommends
setting a specific value.
Nigel: Pierre didn't you feed back that setting a specific
value makes nobody happy?
Glenn: One minor editorial change I would make in TTML2 and
TTML1 maybe:
... we use "altitude (A)" and "descent (D)" - we should make it
more consistent by using
... "ascent" instead of "altitude" to make it more consistent.
In TTML2 it has a note
... about the ascent and descent.
... Do you think I should make that editorial change?
Andreas: For me, I would welcome the change.
Glenn: Okay that sounds good to me, I can put an editorial
issue in to fix that.
... I'll take care of that.
Cyril: I was looking at the lineHeight constraints in IMSC, and
it still says that implementation
... of "normal" is not consistent so should not be used. The
intent is there, reading it
... now I think we should probably tweak that text also because
we have the initial
... element in IMSC 1.1, so we could set it using initial to a
value other than "normal".
Glenn: It turns out that there's a challenge with respect to
specifying a distinct line height
... value as opposed to normal. It is inherited by the inline
elements of a paragraph and
... used to calculate the half leading of the inline elements,
but if you use normal then
... the value of normal is resolved on a per inline basis but
if you specify an explicit value
... on p then that exact value is applied to each inline and
that can cause problems if
... the font size of the inline is larger than that size.
Cyril: Sure, but the author should know that if they set a line
height value explicitly then
... it should deal with the inline childrens' heights.
Glenn: If you have an inline whose font size is twice the p
font size and you specify a
... line height that is smaller then you will end up with
negative half leading, but in any
... case the author is in control. I'm wondering if that
recommendation could potentially
... cause authorial problems but maybe we don't need to deal
with that right now. I just
... wanted to take note of it.
Cyril: I will raise an issue on IMSC 1.1 so we can fix it.
Pierre: There's an informative note on TTML2 with similar
language.
Cyril: Related to initial?
Pierre: No but to setting an explicit value for lineHeight.
<glenn> using explicit LH on P may result in negative
half-leading on child SPANs, and thus cause inline glyph areas
to overlap prior or subsequent line areas
Nigel: That discussion related to
[24]https://github.com/w3c/ttml1/pull/355 by the way
[24] https://github.com/w3c/ttml1/pull/355
Update tts:lineHeight='normal' algorithm to match TTML2 ttml1#355
github: [25]https://github.com/w3c/ttml1/pull/355
[25] https://github.com/w3c/ttml1/pull/355
Nigel: See discussion above in the minutes from this meeting by
the way.
Pierre: Nigel you raised the point about the note being
removed.
Nigel: Yes, thank you for the reminder. This is about the note
that helpfully explained that
... using lineHeight="125%" and fontSize="0.8c" could be used
to get lines that fit in 1c
... height.
... The current pull request removes that note, and I wanted to
put it back.
Pierre: As we know the actual space between line boxes is not
guaranteed to be the
... specified value of lineHeight. My conclusion is that for
folks that expect to be able
... to reproduce the exact grid they were accustomed to in old
systems that cannot be
... done reliably.You can get close most of the time.
Glenn: You can construct scenarios where it can be made so, for
example by making
... none of the descendant elements specify a font size at all.
To try to explain in a note
... this very complicated subject I would prefer to leave the
note out. I'm not inclined
... to add it back in.
Andreas: My view is similar to what Pierre said - the value
"normal" interpretation is
... messed up. I think it is not really necessary to repeat the
note, because if you go
... from a grid based layout to TTML then there may be another
specification like EBU-TT
... that could point out the possible use of 125% for that
reason.
... I still think that it could be good advice for some
transformation to recommend
... transforming grid based layouts to TTML and back, although
you cannot guarantee
... the same presentation. It is still a valid recommendation
but it does not have to be in
... TTML.
Nigel: Okay, I'm not going stick this one out and have recorded
that I feel we have lost
... something helpful.
... Let's conclude not to add the note back in now.
... Moving on to the next point about resolved computed vs
computed, Glenn you had a point:
Glenn: We can't remove the "resolved computed value" and go
back to "computed value"
... because the "computed value" is the inherited value and the
special inheritance semantics
... dictate that the computed value is inherited. We can only
talk about the algorithm
... to produce the actual lineHeight to take into account the
input and the output value.
... I used the phrase "resolved computed value" which seemed
like the best option without
... adopting "used value" as per CSS which is not used in
XSL-FO.
... As to adding the special inheritance section note, Pierre
is correct that we should have
... added it in to TTML2 but failed to do that.
Nigel: I read it a different way, namely that the text changes
removed the need for that
... special inheritance semantics section.
Glenn: You might be right in part.
... It is not entirely clear.
... CSS actually explicitly says it whereas XSL-FO marginally
says it, in one place but not another.
... It's indirect in §4.5 under line areas. It's not bad to
have the explicit section on
... special inheritance here. Since we could not add it
normatively in TTML2 CR2 we had
... to resort to a note.
Nigel: Okay, I had read it a different way and Pierre and Glenn
think the special inheritance
... section is useful. I don't think it is harmful just that we
had cleverly avoided the need
... for some unnecessary spec text.
... I am happy to keep it. We should have an issue on TTML2 to
add it back in.
Glenn: I can add that issue and mark it as ttml.next.
Nigel: Okay that works for me.
SUMMARY: @skynavga to make an editorial tweak from altitude to
ascent in TTML2 and @palemieux to port that back into this pull
request; @skynavga to raise an issue to add the special
inheritance semantics back into TTML2.
TTML1 3rd Edition CR2
Nigel: I understand Pierre is requesting a CfC to publish TTML1
3rd Ed CR2 based on
... the two open pull requests #355 and #356 when the edits
just approved in principle
... have been applied to #355.
Pierre: Yes
PROPOSAL: After the editorial tweak to #355 agreed above, merge
#355 and #356 early and generate a CR2 draft for review with
intent to request transition after the normal 10 working day
period.
Pierre: That's good with me.
Nigel: Any objections?
group: [silence]
RESOLUTION: After the editorial tweak to #355 agreed above,
merge #355 and #356 early and generate a CR2 draft for review
with intent to request transition after the normal 10 working
day period.
Nigel: Okay, when those tweaks are made Pierre please ping me
and I will issue a CfC.
Cyril: Given the potential problem of timeline with TTML2 if it
helps would it be possible
... to request transition earlier than 10 working days?
Nigel: No, I don't believe it would be possible, but I also
don't believe it would help.
... The transition request cannot be executed before the
group's decision is final, though
... we could get those pull requests merged earlier.
Glenn: I agree I don't think you could squeeze those 10 days by
process.
Pierre: [drops off the call, with apologies]
Nigel: Regardless of whether or not we can squeeze TTML1 3rd Ed
out a week early,
... we still have the exclusion period question referenced
above, so I don't think it would make much difference.
Glenn: Regarding adopting TTML1 3rd Ed from TTML2 we could
change to a generic
... non-dated reference, or we could leave as is and then
anyone traversing the link would
... get a warning that it is not the latest version.
Nigel: Even so that doesn't change the semantic basis.
Glenn: That's true unless we change the reference to be
non-specific.
Nigel: True but I think we decided not do that before.
Glenn: If you pull up TTML1 2nd Ed it says that it is outdated.
Nigel: We don't have to decide this right now - I propose we
wait for a response from
... Philippe.
Glenn: I agree. To reiterate for the minutes, three options:
... 1. Leave as 2nd Ed ref, resulting in an out of date message
... 2. Supersede it formally which we could do after publishing
TTML2.
Nigel: That doesn't really help.
Glenn: If it is formally superseded that emphasises the
outdated message.
... 3. Change to a non-specific reference, which goes back on
our previous policy.
Nigel: When we supersede a spec the URL changes so we would run
the risk of
... breaking the just-published TTML2.
... You can check this with IMSC1.
IMSC 1.1 CR2
Nigel: The CfC for IMSC 1.1 CR2 ends tomorrow I believe, and
I'm not aware of any
... objections to proceeding with the request for transition at
this time.
... Since Thierry is not on the call I can't ask him now to
prepare the transition request
... but will do that offline.
... Hopefully that transition request can be raised on Monday
(if not before!).
Future meetings timings
Nigel: Andreas reminded me at the top of this call that some
groups are switching to
... have meeting times based on UTC instead of Boston time, to
simplify (slightly) the
... issue of daylight savings time changes.
Andreas: Yes, it was discussed at the AC meeting in May and I
think everybody agreed
... it would be easier not just because of DST but also if new
members join the call it
... is easier to find out when the call is. It is not urgent
but I would propose if nobody
... objects to switch to UTC instead of Boston time.
Nigel: You're not proposing to change the time?
Andreas: No, only the time zone.
Nigel: Okay.
PROPOSAL: Base the meeting time on UTC rather than Boston time
for future meetings, i.e. 1400 UTC every Thursday.
Nigel: Any objections?
group: [silence]
Nigel: Okay what I will do is highlight this resolution in the
minutes in case anyone
... has later thoughts about it or has a view but is not on
this call.
Andreas: The other proposal that is useful for new people is to
include meeting invites
... in your invitation.
Nigel: Yes that's a good idea, I think I can do that. I'll look
into how to do it. Thanks
... for the proposal, I will do that when the resolution to
change the time zone has been
... finalised. I don't think I need a special resolution for
that decision.
... Good ideas, thank you.
TTML2
Nigel: I wonder if we can get to a resolution on ttml2#867?
Glenn: We should have a private conversation because we're not
on the same page.
Nigel: Good idea, your audio is breaking up a little so
probably better than doing it now.
Glenn: Let's try to do it soon, maybe early next week?
Nigel: Yes.
Glenn: Maybe 18th-22nd I will have better connectivity.
Nigel: I'll send you an invite.
Unicode bidi should probably not be animatable. ttml2#881
github: [26]https://github.com/w3c/ttml2/issues/881
[26] https://github.com/w3c/ttml2/issues/881
Nigel: Quick update - I have asked Philippe, and hope to hear
back from him perhaps
... early next week - I think W3 staff availability is
currently limited.
SUMMARY: Request sent by @nigelmegitt to @plehegar
Clarify that construct effective {content,processor} profile is
performed only once. ttml2#860
github: [27]https://github.com/w3c/ttml2/issues/860
[27] https://github.com/w3c/ttml2/issues/860
SUMMARY: @skynavga and @nigelmegitt to discuss offline
Clarify that [validate document] may produce false positive results.
ttml2#876
github: [28]https://github.com/w3c/ttml2/issues/876
[28] https://github.com/w3c/ttml2/issues/876
Glenn: I'll fix the typos. We already have a note on false
positives that talks about a more
... generalised value syntax in the schema than the spec, in
the section on schemas.
... In section 4.1, a long note. I could refer to that note
here.
... It wasn't so much the schema false positives I was thinking
of when I wrote this
... material but the more complex restrictions that are not at
all expressible in a schema,
... for example all the constraints about ruby, as well as many
other cases.
... Unless you consider your schema to include code, which I
do, I define the set of
... potential schemas as including programming code, then that
note could make it
... less abstract.
Nigel: Yes that would work.
... More generally the reductive interpretation of this is to
say that implementations might
... not be complete, which is true of almost everything, so why
call this one out particularly?
Glenn: I agree, this note and all others could be removed
without changing the
... normative text.
... People might think that putting "prohibited" in a profile
might lead a validation processor
... to catch it. I want to ward off those kind of readings by
pointing out that the language
... on validation is based on "if something is detected" rather
than requiring detection of
... every possible error. It doesn't hurt to say it, unless you
dispute that it is factually correct.
... I would dispute that it's factually wrong.
Nigel: Ok
Glenn: We don't precisely define the behaviour of what happens
when something
... violates a constraint. In some cases we specify a fallback
but in others we don't. We
... also don't set threshold rules about when aborting should
happen.
... I'm just trying to help the reader out - my re-reading made
me think that there was
... potential for misleading the reader.
... I'll make those two fixes and maybe you can consider that.
Nigel: Okay will do.
SUMMARY: @skynavga to make edits discussed above and
@nigelmegitt to re-review
<inserted> Pierre: [rejoins call]
text profile should support anamorphic fonts imsc#419
github: [29]https://github.com/w3c/imsc/issues/419
[29] https://github.com/w3c/imsc/issues/419
Cyril: I raised this issue this morning.
Nigel: I think this needs to go to requirements first, but we
can discuss it here now.
Cyril: Anamorphic fonts is a feature we use quite heavily. It
is a de facto practice
... that was inherited from lambda cap. I suspect it is not
easy to define two glyphs
... that are completely distinguishable within the em box,
which may be why stretching
... is used instead of using specific fonts.
Nigel: Is there any other way to achieve the result than to use
fontSize with two components?
Glenn: You mentioned two specific characters, distinguished by
stretching. Practically
... speaking, just not stretching either of them and requiring
the reader to use context
... to figure out which is which is not a horrible way to deal
with this.
Cyril: Our QC team clearly told me this is not acceptable.
Glenn: Okay, I understand, though I think Japanese readers can
fill in the blanks and
... distinguish them.
Cyril: There's clearly ambiguity and we want to distinguish
these cases.
Glenn: It's a really high cost for what I consider really low
value.
Cyril: I understand that, which is why I suggested adding
restrictions. I am open to any
... suggestions.
Pierre: Before we go there, for the record, my interaction with
folks other than Cyril
... who work with Japanese subtitles has been consistent with
what I heard from Glenn.
... I think we need a separate meeting with interested parties
to work out the solution.
Cyril: Sure, I'm concerned about the timelines.
Pierre: I do not think it can be implemented in CSS.
Cyril: We can set up this meeting. I do not want to delay the
process. What I can think
... of for today is to add the feature and mark it as at risk?
Pierre: No, it is just not implementable in CSS. If you can
point to a way it could be
... implemented that would address my concerns.
Glenn: One of the things you mentioned is different glyphs. The
implementation is free
... to map to whatever glyphs it wishes. One implementation
approach would be to
... select different glyphs with intrinsically different
widths. That would not require the
... general ability to specify an anamorphic font, which is a
much costlier thing for
... implementation.
Pierre: When I experimented with fonts, some of them showed a
much bigger difference
... between those two characters than others. Like in some
Latin fonts it can be hard to
... tell an O from a 0 or an l from a 1.
Glenn: Yes that's exactly the point.
Cyril: Okay I will come back to you on this issue but it might
be a blocker for us to
... progress IMSC.
Pierre: Understood.
Glenn: In a sense I view this as a quality of implementation
issue.
Pierre: That's where I am but maybe there's more information to
bring to the table that I don't know yet.
Glenn: If this is the only example then anamorphic fonts is
overkill.
Cyril: It's not anamorphic fonts but the right restrictions to
make it not overkill.
Glenn: If you tweak the character then you're proposing a
generic property that can
... apply to any character, not just the ones that have the
problem. That's a more generic
... solution to this problem. You have to raise the cost vs
gain comparison here.
Nigel: I think looking for other ways to achieve an acceptable
result is the way forward here.
... For example in SVG you could apply a transform, and maybe
in CSS?
Glenn: Only on block containers in CSS, not inlines.
Cyril: If it is not used then why is it in LambdaCap?
... We ingest content with that feature in.
Pierre: I'm guessing here, but one possibility is there's only
one font that is used in
... LambdaCap. That could be a reason.
Glenn: Actually LambdaCap has 6-10 font families that it can
select.
... We implemented this in TTML2 with generic stretching. There
is a pretty heavy toll
... on the implementation to support anamorphic fonts. For
example you have to have
... anamorphic whitespace as well as anamorphic glyphs. There
is a whole bunch of things
... that it affects.
Cyril: Okay I'll come back to you on this one.
SUMMARY: @cconcolato to review and come back with further
thoughts.
tts:origin/tts:position constraint applies to Text profile only
imsc#418
github: [30]https://github.com/w3c/imsc/issues/418
[30] https://github.com/w3c/imsc/issues/418
Pierre: I think this is editorial, and was planning to address
it after CR2.
Nigel: Okay, knowing the plan is useful.
Pierre: This is definitely not fatal.
Nigel: I think this could be considered substantive.
Pierre: I'll address it today.
lineHeight restriction should not preclude using the initial element
imsc#420
github: [31]https://github.com/w3c/imsc/issues/420
[31] https://github.com/w3c/imsc/issues/420
Pierre: I plan to address this today, using the same text as in
TTML2.
Cyril: Fine
Address draft CR2 comments imsc#417
github: [32]https://github.com/w3c/imsc/pull/417
[32] https://github.com/w3c/imsc/pull/417
Pierre: I addressed your comment Nigel
Nigel: That looks great, thank you!
... [approves pull request]
IMSC 1.1 CR2
Nigel: Just noting that we have a small flurry of last minute
review comments but I'm fairly
... relaxed about them, given their nature.
TPAC 2018
Nigel: Don't forget the early bird rate is still available.
Pierre: And to confirm we are meeting Monday and Tuesday?
Nigel: Yes
... Note we are likely to have a significant amount of "joint
meeting" with M&E IG on the
... Monday. I'm still open to the idea that we in fact mainly
meet with them on the Monday
... and conduct our TTWG only business on the Tuesday,
depending on the volume of
... topics we have to discuss.
... Obviously as Chair I'm willing to take input on that.
Meeting Close
Nigel: Thanks everyone for joining today. See you next week!
[adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [33]After the editorial tweak to #355 agreed above, merge
#355 and #356 early and generate a CR2 draft for review
with intent to request transition after the normal 10
working day period.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [34]scribe.perl version
1.152 ([35]CVS log)
$Date: 2018/07/12 16:19:33 $
[34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[35] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 12 July 2018 16:23:57 UTC