- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 16 Jan 2020 17:25:02 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <0F968C7D-933B-45DF-A64E-24AE23679E04@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2020/01/16-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
16 January 2020
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2020/01/09-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/89
[4] https://www.w3.org/2020/01/16-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Glenn, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
* [5]Meeting minutes
1. [6]This meeting
2. [7]IMSC 1.2 FPWD Next steps
3. [8]font selection rules under-specified? imsc#516
4. [9]IMSC 1.1 errata
5. [10]TTML2 2nd Edition Wide Review
6. [11]AOB CSS line shear
7. [12]Meeting close.
Meeting minutes
This meeting
Nigel: [iterates through agenda]
… Any other business?
Cyril: I tried to revive the thread on CSS WG about line shear
so maybe we can talk about that.
Nigel: OK, let's cover in AOB
Nigel: If there's nothing else, let's get going.
IMSC 1.2 FPWD Next steps
Nigel: 2 issues to cover today
… First one is #506.
Glenn: I'm afraid I'm going to have to beg off on this one
again.
… I will get around to looking at it. Please could you ping me
on Monday so I won't forget it by next meeting?
Nigel: I'll try, but I'm a very bad PA!
font selection rules under-specified? imsc#516
github: [13]https://github.com/w3c/imsc/issues/516
[13] https://github.com/w3c/imsc/issues/516
Nigel: 3 levels we could get to:
… 1. Informative note - you can use font-face
… 2. SHOULD use font-face
… 3. MUST use font-face
… I wanted MUST but concerns raised.
Glenn: If you make fontSelectionStrategy auto mean "use
font-face" then it is no longer implementation dependent
… so not backward compatible with existing implementations.
Pierre: So if I have a TTML2 compliant implementation that does
not use font-face for auto
… then that would have to be changed to conform to a new
requirement specifying what auto means?
Glenn: Yes
Pierre: So it's a processor conformance issue not a document
conformance one?
Glenn: Yes
Pierre: Another point Glenn made that I sympathise with is that
before taking the plunge and doing a MUST at this
… point in the process and with our limited experience with
IMSC 1.2 and TTML2, it is not unreasonable to have a SHOULD
… and if it turns out to be a success we can make it a MUST
either in IMSC or through some scheme in TTML2,
… but there's an argument to be made about the complexity and
relative age of that feature then a recommendation
… might be a good approach.
Glenn: I had previously suggested a SHOULD but in my last
comment I was even not going that far and suggesting
… that SHOULD might be going too far.
… Because SHOULD add a normative aspect to it.
… I would probably make it a hint or put it in a note and say
that it is something that is being considered.
Pierre: Maybe one notch above a note could be a pointer:
"here's a place where an algorithm is defined"
Glenn: That's possible. If we're going to point at a CSS3 font
module algorithm then we need to due some serious due
… diligence about semantic interaction with other normative
language in TTML2 that may have to change or get
… modified to interact with that 5.2 language. I pointed to one
area regarding the line height algorithm where clearly
… there's going to be some interactions. Just saying "use 5.2
as an algorithm" is risky at the moment. As a possible
… implementation strategy then that's okay, as long as it
doesn't invalidate the semantics of TTML2's line height
semantics
… and other semantics already implied by TTML2 as adopted by
IMSC 1.2 then it's up to you as an implementer,
… but putting it into language in IMSC 1.2 is going to be a
little tricky.
Nigel: We have time at this stage, FPWD.
… Secondly, if the line height algorithm is not orthogonal to
the font selection algorithm then that's another separate
issue.
Glenn: That's quite possible. It's one reason I didn't want to
dive into this in TTML2 when it was originally raised, FYI.
Nigel: I made the point too that if someone provides a list of
fonts where the font metrics differ substantially in terms
… of line height calculation then that's a second order issue
for us, it's a real edge case.
Glenn: It's a really complex area.
… The algorithm finds F0 being a single font for the
calculation of line height for the whole p.
… The actual algorithm is fine grained - you have to walk down
on a per character basis and this is where the
… fontSelectionStrategy values come into play to determine
whether you use character context, and what contextual
… boundaries come into play to break the context into larger or
smaller pieces, for example if you have grapheme
… clusters or bidi boundaries or all kinds of other boundaries
that might dictate that you do or do not consider
… context for including larger or smaller pieces of text for
choosing one font family vs another font family.
… Those all feed into the algorithm that is used in §5.2 of the
CSS Font module.
… The algorithm that's used in lineHeight for choosing F0 is at
a much higher level for choosing a default font family
… for the line height used to drive the XSL-FO default font
family for the line height algorithms that are used there.
… There's a whole bunch of complexity and it is not just
something that you can easily take on in one or two meetings.
… Probably a week of reading time to work through the detail!
… Just giving an overview of the work that would be involved in
doing that.
… Vladimir should probably attend that meeting!
Nigel: I don't quite buy that the lineHeight algorithm should
stop us making progress.
… If the lineHeight algorithm reproduces, either identically or
differently to, the font selection strategy, then they
… are not orthogonal but they possibly should be.
Glenn: It reproduces a simplified version of the algorithm for
its own purposes.
Nigel: Already it is true that implementations may choose font
families with a different algorithm than the lineHeight
… algorithm and that is in spec, so if we change the font
family selection algorithm that would not change.
Glenn: That is probably true. I can't comment on actual
interoperability across implementations.
… If we were to adopt CSS 3 font family selection and apply it
to the font attribute at this time then it could be that
… the line height algorithm could continue independently even
though they might produce different font selection.
Nigel: I think that would be acceptable though not ideal.
Glenn: This opens up the elephant in the room that we have not
done much interop testing. We have complained about
… it with WebVTT but we have not done much testing of IMSC and
TTML2 yet in my opinion.
Pierre: Just on that point, on IMSC 1.1 and IMSC 1.0 there is a
lot of interop testing happening outside W3C.
… Just in February there will be another plugfest where IMSC
1.1 will be front and centre.
Glenn: That's good, will you share those results with the
group?
Pierre: I'll ask, I don't know why it hasn't happened before,
it's a good idea.
Glenn: That'd be great. It's the kind of feedback we should be
hearing.
Nigel: Going back to the topic, if lineHeight doesn't choose
the same font, it still gives predictable results even if
… they are not desirable ones.
Glenn: There's still the question of whether to do this in IMSC
1.2 or TTML2. It's complicated to know how to do that.
… My opinion is it is not really tractable to bring it into
TTML2 directly because it's a core semantic change.
… It could be done via modules, and I suggested a way to do it
via fontSelectionStrategy by introducing a new value,
… which would require defining a new module. That would be the
way forward.
Nigel: From what I've heard I don't think it would be a problem
to say in IMSC 1.2 that we SHOULD use font-face.
Glenn: Not a MAY?
Nigel: There's very little difference between MAY and SHOULD,
it's just how strong the hint is.
Glenn: A processor testing regime that's testing for SHOULD
compliance may reject an implementation that doesn't
… conform with it.
Nigel: That's what we want because it encourages more
interoperability.
Glenn: Are there any processor SHOULD requirements in IMSC? I
don't recall.
Pierre: Yes we have a couple of processor recommendations
worded with a SHOULD.
… I'm really happy with MAY, SHOULD or just "hey here's a place
where there's an algorithm defined".
… They're slightly different. MAY implies that we now permit
something that was prohibited before.
… SHOULD is definitely stronger. If we are really confident
that the algorithm works then that's what we should do.
Glenn: "is permitted"?
Pierre: That's a MAY.
… I haven't studied whether the algorithm is actually the right
one. I'd like a plan from this meeting.
Nigel: Can I propose a pull request?
Glenn: I will not be happy with SHOULD but I can live with MAY
or permitted.
Nigel: A testing regime that enforces SHOULD is downstream of
us, and not our call.
… My argument for SHOULD is that it helps encourage
implementations to work the same way.
Glenn: Practically speaking MAY and SHOULD are the same for
authors because authors need to check their implementations
anyway.
Pierre: One argument for not doing SHOULD is that we haven't
convinced ourselves that we're really doing the right thing.
Glenn: That's my rationale too.
Pierre: It's extremely complex - I think that's a true
statement!
… We don't have a body of documents or examples to guide us.
… That's a strong argument for a MAY, and making clear that if
someone were to implement
… the CSS algorithm then that would not be non-compliant. We
probably want to avoid that.
… That's my input to the pull request.
Glenn: We don't even have the wording to consider.
Nigel: Ok I'll take the next step then.
SUMMARY: @nigelmegitt to draft a pull request
IMSC 1.1 errata
Nigel: I think this has been fixed.
Pierre: Yes, all good.
Atsushi: I hope so!
Nigel: Thank you for sorting that out Atsushi.
Atsushi: Actually please let me say one point that I did a
quick fix, so something may happen.
… Please let me know if there is any issue with the updated
page.
TTML2 2nd Edition Wide Review
Atsushi: During the weekly call of i18n WG we decided that
Richard would raise issues by next week so
… they may arrive by early next week. Of course input is
welcome from TTWG.
Nigel: OK, thank you. I propose that we keep an eye out for
those issues and make a call on them.
… If it looks like they are substantive and cannot be dealt
with during Proposed Rec then we may need to pause
… our publication timeline while we address them, but we can't
tell until we see them.
Glenn: Question - you said there was a review by Fuqiao, have
you seen it?
Nigel: No, I just saw a message saying he'd done a review, but
I don't know what the outcome was.
<atsushi> [14]https://github.com/w3c/i18n-request/issues/
86#issuecomment-568343266
[14] https://github.com/w3c/i18n-request/issues/86#issuecomment-568343266
Glenn: Can you share it with the group or forward it?
Atsushi: I posted a link with some draft comments.
Nigel: Is this a full review of the spec or just the deltas?
Atsushi: Both
Nigel: Should we be looking at only comments with a △ at the
beginning?
Glenn: This looks like it is not related to changes in 2nd
Edition.
… I did a quick review of all the 2nd Ed changes this morning
and I posted a comment in the issue related to our meeting
… agenda that there were two issues closed related to our
agenda, 1076 and 1043, one about ignoring white space
… inside a ruby container, and the other was the
non-applicability of character properties in ruby container.
… None of those have any i18n semantics and none of the other
substantive issues that were addressed have any
… i18n semantics as far as my review is concerned. So my review
suggests there are no i18n semantics for any of the
… substantive changes. My recommendation is that we politely
decline to extend the review and allow the review to
… continue into the CR period.
Nigel: I'd like to tweak that to say that if there are any
comments not related to the delta between TTML2 2nd Ed and
… 1st Ed then we welcome those in our repo but will likely deal
with them in a future edition.
Glenn: I agree with that.
Pierre: What Nigel said.
Glenn: Unless there are any comments about things that are
truly broken.
Pierre: Yes of course.
Nigel: OK I will respond to Addison and i18n explaining the
situation.
Atsushi: Thank you for that.
Glenn: I have a follow-on.
… I have sent a link to Atsushi and you Nigel to a tarball that
is ready to upload to the dated URL /TR space for
… publishing on 28th. Is there any reason to hold off on
putting that in place at this point?
… In the past Thierry always uploaded these dated URLs in prep
for the publication.
… Ahead of time, not at the last second.
… If for some reason an update is needed because of some last
minute change then we can always do that and
… overwrite it with an edited tarball.
Nigel: I don't have a view on that, certainly no objection.
… Can I suggest you take that offline Atsushi and let us know
if there is anything else that needs to happen.
<atsushi> draft transition request on TTML2-2e CR [15]https://
github.com/w3c/transitions/issues/208
[15] https://github.com/w3c/transitions/issues/208
AOB CSS line shear
Nigel: We don't have much time to cover this now - Cyril
perhaps you could send a summary of this to the
… group so we can have a look?
Cyril: I tried contacting Tab Atkins, can you suggest anyone
else from the Chrome team?
Glenn: I will point you to someone on the layout team.
Cyril: thank you
Meeting close.
Nigel: Thanks everyone, we're 2 minutes over, so let's adjourn.
[adjourns meeting]
Minutes manually created (not a transcript), formatted by
[16]scribe.perl version 104 (Sat Dec 7 01:59:30 2019 UTC).
[16] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 16 January 2020 17:25:10 UTC