See also: IRC log
<scribe> scribe: nigel
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.
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> 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 https://github.com/w3c/ttml1/pull/355 by the way
github: 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.
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.
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!).
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.
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.
github: 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
github: https://github.com/w3c/ttml2/issues/860
SUMMARY: @skynavga and @nigelmegitt to discuss offline
github: 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]
github: 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.
github: 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.
github: https://github.com/w3c/imsc/issues/420
Pierre: I plan to address this today, using the same text as in TTML2.
Cyril: Fine
github: https://github.com/w3c/imsc/pull/417
Pierre: I addressed your comment Nigel
Nigel: That looks great, thank
you!
... [approves pull request]
Nigel: Just noting that we have a
small flurry of last minute review comments but I'm
fairly
... relaxed about them, given their nature.
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.
Nigel: Thanks everyone for joining today. See you next week! [adjourns meeting]