- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 1 Feb 2018 17:44:19 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <D6990238.53CFF%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/02/01-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
01 Feb 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/02/01-tt-irc
Attendees
Present
Nigel, Thierry, Glenn, Andreas, tmichel, Cyril, Pierre
Regrets
None
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This Meeting
2. [5]Incorporate resolutions of additional TTML1 Issues.
ttml2#358
3. [6]A single length value for tts:fontSize specifies
both height and width. ttml2#548
4. [7]clarify use of tts:textCombine ttml2#619 (pull
request)
5. [8]Incorporate CSS advances into TTML vertical text
handling ttml2#277
6. [9]Sideways shouldn't be tied to tblr vs tbrl
ttml2#280
7. [10]Upright orientation involves more than just glyph
orientation ttml2#281
8. [11]How to handle mismatched sequences in complex ruby
ttml2#247
9. [12]Complex ruby is usually both mono and group ruby
ttml2#246
10. [13]How to handle mismatched sequences in complex ruby
ttml2#247
11. [14]rubyOffset and line-spacing ttml2#252
12. [15]Remove animate, begin, dur, end, region and
timeContainer of br elements (#552). ttml2#570
13. [16]APA comments
14. [17]Meeting close
* [18]Summary of Action Items
* [19]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This Meeting
Nigel: Today is for me the Big Day for TTML2, being effectively
the last day for opening
... substantive pull requests.
Glenn: If any more are opened, the Group will have to decide
what to do.
Nigel: The 2 week review period is derived from the group's
Decision Policy in the Charter.
... I just sent round a summary, and I propose that we
prioritise the issues marked for
... the agenda as usual, and also scan through all the "blocks
CR" issues.
... So I propose to do TTML2, then TTML1 - I don't think there
are any IMSC issues
... that need urgent discussion today.
... Any other business or points to discuss?
Cyril: What about the duration of the review period?
Nigel: I don't really want to open that discussion up right
now.
... I see 13 TTML2 issues and pull requests marked for agenda
right now.
[20]Issues and pull requests marked Agenda
[20] https://github.com/w3c/ttml2/labels/agenda
group: [no other business]
Incorporate resolutions of additional TTML1 Issues. ttml2#358
github: [21]https://github.com/w3c/ttml2/issues/358
[21] https://github.com/w3c/ttml2/issues/358
Cyril: I explained by email what is happening in this one.
There are two TTML1 issues
... that should be incorporated in TTML2. One of them has been
progressed by Pierre, w3c/ttml1#320,
... so that should be fine. The other is w3c/ttml1#317 on
chained referential styling.
Nigel: I opened that ttml1 issue.
Cyril: I want to close that issue or defer it. We should
possibly open an issue for TTML2
... and mark it as ttml.next or post CR1.
Nigel: I've marked the TTML1 issue as editorial and don't mind
removing it from this issue,
... since there's no action to take.
Cyril: Okay, then I just need to implement w3c/ttml1#320 here
and then we can close this.
SUMMARY: Cyril has what he needs to complete this today.
github-bot, end topic
A single length value for tts:fontSize specifies both height and
width. ttml2#548
github: [22]https://github.com/w3c/ttml2/issues/548
[22] https://github.com/w3c/ttml2/issues/548
Nigel: I'm requesting consistency here between "applies" and
"expresses" - and replacing all
... in this sentence with "defines". Is that okay, Editors?
Cyril: Fine for me
Glenn: We use applies, expresses in various places, so I have
no problem with the current language.
... I would rather change "expresses" to "applies to" for
consistency.
Nigel: That would be inconsistent with, for example, the way
that "applies" defines the
... significance of a style attribute on an element.
Glenn: If you review use of these terms you'll find they are
approximately synonyms.
... Changing this here seems unnecessary without reviewing all
the other cases.
... "defines" implies "fully defines" to me, in my mind.
Nigel: "determines", then?
... I see "applies" as meaning "is relevant to".
Glenn: If you want to change "applies to" to "determines" and
"expresses" to "determines"
... then I would be okay with that.
Nigel: Okay, that works for me.
RESOLUTION: Replace "applies to" and "expresses" with
"determines".
<tmichel> Ok for me
github-bot, end topic
clarify use of tts:textCombine ttml2#619 (pull request)
Cyril: This requires a bit of work. It is related to a set of
comments from r12a about
... internationalisation. There are three issues related, on
textOrientation, writingMode and
... resolving issues #277, #280 and #281.
Glenn: Do you have a sense of whether the resolutions will be
editorial or substantive?
Cyril: Substantive I think.
... It's about adding clarification - maybe a significant
number of lines will be changed.
Glenn: My sense is that all of Richard's comments can be
resolved editorially.
Incorporate CSS advances into TTML vertical text handling ttml2#277
github: [23]https://github.com/w3c/ttml2/issues/277
[23] https://github.com/w3c/ttml2/issues/277
Cyril: My problem with this is, at least at Netflix, we want to
align better with CSS in the future,
... and I wouldn't want to make changes in TTML2 that make such
alignment impossible in the future.
Nigel: +1
Glenn: We have some study of mapping of TTML and CSS, and for
writingMode we had
... concluded that there is a mapping available.
Nigel: I believe so.
Cyril: Writing Mode in CSS has additional values we don't have.
Glenn: But we do have all of them. We just have different
keywords.
Nigel: Do we have sideways-left and sideways-right that weren't
in XSL-FO?
Glenn: Yes, you use writingMode and textOrientation together.
Cyril: I think it's okay for writingMode, because CSS defines
how to map the old values to
... the new ones for writing-mode.
... In CSS level 3 or 4, the spec defines the interaction
between writing-mode, text-orientation,
... direction, text-combine and so on. I have no idea what the
interaction between those
... properties are, for example textCombine and
textOrientation.
Glenn: They are independent.
Cyril: They cannot be, or what's the order in which they are
applied?
Glenn: textCombine only applies potentially when some segment
of text does not have the
... same text orientation as its surrounding text.
Cyril: When horizontal text is upright in vertical text.
Glenn: Yes, so if textOrientation were sideways then it would
never apply. If you put
... Japanese text inside English text for example, and the
outer portion is sideways, then I
... guess in that case you would set the Japanese text sideways
as well so textCombine would
... not apply either.
Cyril: We can find examples - my general question is I don't
know how to fix the spec without
... referring to CSS and saying do what they say.
Glenn: I don't think there's anything broken right now.
Cyril: There's nothing in the spec that defines the processing
model for textCombine and
... writingMode.
Glenn: There's a great deal not defined.
Cyril: Exactly.
Glenn: Over time we can add more language to the spec, but we
won't need additional keywords.
... So one issue it that Richard's comment is asking to add two
additional values to writingMode.
Cyril: I can say we won't do this now but might do it later.
Glenn: That's appropriate.
Cyril: Then can we resolve this?
RESOLUTION: We are willing to evaluate the use case for the new
writing-mode values but will defer this to a future version of
TTML.
github-bot, end topic
Sideways shouldn't be tied to tblr vs tbrl ttml2#280
github: [24]https://github.com/w3c/ttml2/issues/280
[24] https://github.com/w3c/ttml2/issues/280
Cyril: As per #277, I don't know how to clarify or change this
without making a lot of changes.
Glenn: The fact that the derivation was originally based on a
version of CSS that has
... since been changed doesn't change it.
Nigel: I just moved the basis across to appendix N.
Glenn: We could review the accuracy of that and add notes here
if we want to. I don't have any in mind right now.
Cyril: CSS Level 3 and Level 4 Writing Modes are the same for
text-orientation.
Glenn: The CSS application to 'vertical script' characters can
be seen as a superset of what
... we have implemented. I'm not aware of a use case for that
off-hand. I don't believe we
... are inconsistent, but possibly a subset of some expanded
semantics that allows vertical
... script characters to have sideways applied to them.
Nigel: He's worried about correct progression of text along the
line for Latin text when
... tblr is the writing-mode value.
Glenn: One way to address this would be to remove the keyword
"sideways" entirely and
... just leave sideways-lr and sideways-rl.
Cyril: I think that's the opposite of what he wants.
Glenn: The only reason I added sideways in the first place was
because it was listed in CSS.
... That language came from earlier versions of the CSS spec
language. Then they made changes.
... If we take sideways out then we don't have to clarify
anything.
Nigel: Why would we not just adopt the updated language from
the current CSS spec?
Glenn: I haven't reviewed it yet.
[25]CSS Writing Modes Level 4 WD
[25] https://www.w3.org/TR/css-writing-modes-4/
Nigel: Level 4 marks sideways-lr and sideways-rl as at risk!
Glenn: Oh boy!
Cyril: It's a FPWD and they're already talking about at risk
features - this could be a hangover from L3 CR that's not been
cleaned up (speculating).
... Glenn, you propose to remove sideways?
Glenn: I see there's another comment, about "unless this
behaviour..." - that's in fact the
... only place where we intend to use it. Actually for mixed
scripts.
... It seems like the resolution may be similar to #277. We
said we would
Nigel: You're proposing no change?
Glenn: Yes, as for #277.
Cyril: textOrientation is new in TTML2, derived from CSS, but
does not have a 1:1 mapping
... to CSS. That's an issue to me.
... Level 3 is in CR now, and nothing is marked as at risk.
Could we align with L3?
... Just in terms of keywords - they don't have sideways-left
and sideways-right.
[26]CSS Writing Modes L3 text-orientation
[26] https://www.w3.org/TR/css-writing-modes-3/#text-orientation
Nigel: [observes that this is really late to be making this
change]
Glenn: [agrees, especially since it has already been
implemented]
... I notice they have a sentence "UAs may accept
sideways-right as a value that computes to sideways if needed
for backward compatibility reasons."
... So they've said they don't like sideways-left.
... If you're doing tblr and sideways, then Latin text would
start at the bottom and go up.
... It sounds like they have no use case for that scenario.
Cyril: Why don't we mark sideways-left and sideways-right as at
risk?
Glenn: Good proposal.
RESOLUTION: We will mark sidewaysLeft and sidewaysRight as at
risk for CR and continue to review the need for those features
and their alignment with CSS.
Cyril: +1
Glenn: +1
Cyril: I'll propose a pull request to mark them as at risk.
Upright orientation involves more than just glyph orientation
ttml2#281
github: [27]https://github.com/w3c/ttml2/issues/281
[27] https://github.com/w3c/ttml2/issues/281
Nigel: It looks like Richard's proposals are certainly missing
right now and would make a
... big difference to readability for the scripts he mentions.
Glenn: You would never set arabic in upright form as he
describes there... Actually there's
... a language in one of the Maldive islands that uses arabic
letters only in their isolated form
... to write their language.
... Right now we don't say the things he proposes but that
doesn't mean that
... processors couldn't do it.
Nigel: We talk about individual glyphs, which is the problem.
Glenn: I think the language came from an earlier version of
Writing Modes, and they've
... refined those but we haven't updated ours accordingly.
Nigel: Is the task therefore to update TTML2 to match the more
up to date CSS language?
Glenn: I've avoided using grapheme cluster so far but there
were other questions about Ruby
... that mention them, so I think we may not be able to avoid
them. It's a really complex
... concept and very few people understand it. I'm not sure of
the value of introducing it
... here. I prefer to leave it under-specified and let
implementations do the right thing.
... We can resolve it editorially with notes later.
Nigel: We refer to glyphs and don't allow for groups of glyphs.
Glenn: We do allow for that.
Nigel: How do we do that?
Glenn: "glyphs from horizontal scripts" is in my mind ambiguous
- scripts do not have
... glyphs, they have characters, and glyphs are the result of
a complex mapping from characters
... to glyphs.
Nigel: We already defined "glyph area" - why don't we just
substitute "glyph" for "glyph area"?
Glenn: That would work for me. That's in fact exactly what
would happen.
... I anticipate Richard will come back with some questions.
RESOLUTION: Change "glyph" to "glyph area" in the quoted text.
Cyril: I will prepare that pull request.
github-bot, end topic
How to handle mismatched sequences in complex ruby ttml2#247
github: [28]https://github.com/w3c/ttml2/issues/247
[28] https://github.com/w3c/ttml2/issues/247
Cyril: I could not find how the mapping is done between the
container and the base text
... if there are multiple bases. Is a 1:1 mapping needed?
Glenn: I believe the answer is yes. I think he's asking if RT
items != RB items.
... TTPE implements code to handle that case and probably
applies however many RTs to
... the available RBs and if there are more then they are
ignored. We don't say anything in
... the spec text right now.
Cyril: I think we should. In #246 he is proposing to change the
example but not the base
... text, which I think is not correct. This is the "complex
ruby" example. The first part
... is a base container, containing one base element, and the
second part has only one text
... element, and he wants to change to two separate spans with
ruby text, but if you do that
... you have to change the [scribe lost track].
... I think if we say mapping has to be 1:1 then ... [look at
the complex ruby example in the spec]
... He wants to split the "before" into two sets of two
characters each, with each pair
... corresponding to a single base character.
Glenn: The rendered output would be the same either way.
Cyril: That clarifies my question to #246, that's fine. If I do
what he says, and split the
... span for before annotation into two, how do you know that
the first one applies to the
... first character?
Glenn: Good question. This goes back to the previous question
whether there's a different
... number of text to base units in the case of...
Cyril: If there's only one text, then it is group ruby and
applies to all bases. If there's the
... same number, I also understand it means mono ruby. I don't
understand if there are
... other permutations.
... We could say you have two choices: text containers = base
containers or text container = 1
... (i.e. number of them)
Glenn: Yeah, right now I don't see any way to specify both
before and after cases and
... separate the bases.
Cyril: There's nothing to prevent it, it's just not specified.
Glenn: I would need to look at the current CSS Ruby spec which
is actually quite old.
Nigel: We need a resolution to this issue.
Pierre: Does this ambiguity arise in a use case that Netflix
has?
Cyril: At the moment we don't have this use case.
Pierre: One possibility is to try to specify the behaviour in
the complex cases, another is
... to eliminate those complex cases by prohibiting them. A
third is to ignore them in TTML2
... and leave them deliberately underspecified. We might just
not have time to specify the behaviour.
Glenn: I tend to agree with leaving it underspecified. But will
Richard be able to accept that?
Pierre: How does HTML do it? Do they simply not support those
complex cases?
Cyril: They do support it. This example looks complex but it
isn't uncommon.
... My proposal would be to add constraints about texts = bases
or texts = 1.
Pierre: In TTML2?
... Fine with me. You could constrain that in a feature.
Glenn: I'm not prepared to accept that. It's related to the
other issue, which is if there is a
... different number of texts from bases, how is that resolved?
That is independent of before
... and after.
Cyril: Yes
... If you don't have the after then you just use container,
base and text, and have two
... consecutive ruby containers.
Glenn: My preference would be to resolve this post-CR with
clarification comments.
Cyril: No we have to resolve it before CR, it is not editorial.
Nigel: +1
Glenn: If I'm forced to answer, I'm going to say defer it to
the future.
Nigel: I would propose to keep the syntactic flexibility but
apply Cyril's proposed constraints
... as a feature, which provides something that we can test
sensibly.
... That allows us to add further semantics later.
Glenn: That's terrible. I would say right now, normatively,
that if the number of base items
... and the number of text items are not matched then the
behaviour is implementation
... dependent.
Cyril: That's fine by me.
... But also allow group ruby?
Glenn: Yes.
Cyril: This is enough for me to move forward.
RESOLUTION: Add a normative statement that the behaviour for
mismatched rb and rt numbers (other than a single rt) is
implementation dependent.
github-bot, end topic
Complex ruby is usually both mono and group ruby ttml2#246
github: [29]https://github.com/w3c/ttml2/issues/246
[29] https://github.com/w3c/ttml2/issues/246
Cyril: I will change the example as requested and modulo the
resolution for #247
... When it is a single rt then it is group ruby, when the
number of rt is equal to the number of rb
... then that's mono ruby. The other cases are not defined.
Glenn: Where do we specify that a single rt applies to multiple
bases?
... For that mismatch, where do we define it?
Cyril: I'm going to add that to the text.
... That's group ruby, right?
Glenn: We haven't discussed the work to do that.
... We don't have any language on group ruby in the spec, and
introducing this now would
... require a lot of elaboration at this time.
Cyril: It is nothing new.
Glenn: I want to leave it unspecified, rather than the
exception clause for the mismatch.
... There's no example of group ruby in the spec right now.
Cyril: The "Complex Ruby" example uses group ruby, and the
request in this issue is to
... introduce a mismatch.
Pierre: Then we can simply say "mismatches are not defined" and
remove the example.
Glenn: The example right now does not have a mismatch.
... We should not introduce the change, and say that doing what
the request asks would
... introduce undefined behaviour.
Pierre: Since we don't have a use case for mismatch, we can
leave that out in all cases,
... and tell the reporter that we don't define behaviour so
won't do it.
Cyril: We have use cases for mono ruby and group ruby, but not
for complex ruby mixing
... mono and group.
Glenn: In your use of group, you don't have mismatch?
Cyril: Right, unless we have 1:1. Actually the "simple ruby"
example is a group.
Glenn: That's right. There'a a one to one match in both current
cases.
... The comment here requests introducing a mismatch, which we
want to avoid. So here
... we cannot simply accept the proposed change.
RESOLUTION: We will not make the requested change because it
would introduce a mismatch between the number of texts and
bases, and we currently do not define the behaviour in that
case.
github-bot, end topic
How to handle mismatched sequences in complex ruby ttml2#247
github: [30]https://github.com/w3c/ttml2/issues/247
[30] https://github.com/w3c/ttml2/issues/247
RESOLUTION: (updated following further discussion) All
mismatches will be left as implementation dependent behaviour,
even if the number of texts is 1.
github-bot, end topic
rubyOffset and line-spacing ttml2#252
github: [31]https://github.com/w3c/ttml2/issues/252
[31] https://github.com/w3c/ttml2/issues/252
Glenn: I can accept deferring rubyOffset to the next version
RESOLUTION: Remove rubyOffset and defer it to ttml.next
Glenn: I put it in for thoroughness, not because I knew a
particular use case in subtitling and captioning.
... Since CSS doesn't have ruby offset either we can wait.
github-bot, end topic
Remove animate, begin, dur, end, region and timeContainer of br
elements (#552). ttml2#570
github: [32]https://github.com/w3c/ttml2/pull/570 (pull
request)
[32] https://github.com/w3c/ttml2/pull/570
Glenn: I think we had record to include timing etc on br before
in a change proposal.
Pierre: We resolved this differently more recently. The safest
thing at this point is to match
... TTML1. We can deal with this later on by extending TTML2.
Glenn: We could simply mark this as at risk.
<tmichel> I need to drop now. Bye.
Pierre: We don't know of any use case that requires these
features on br
Glenn: And your proposal is to use span to style and time a br?
Pierre: Yes
Glenn: It maintains an inconsistency. The options are:
... 1. Leave it in and add that display applies to br
... 2. Take it out
... 3. Mark as at risk
... Marking it as at risk allows us to get to CR and deal with
it afterwards.
Pierre: It requires a new feature too, because we're
acknowledging it was not there before.
Glenn: That's true, something like break-2 which would require
content-2.
Pierre: I don't disagree that the lack of symmetry is not
awesome and the fact that tts:display
... is mentioned in br but does not apply to it is not great,
but given the time we have the
... simplest thing to do is to add it to TTML1.
Glenn: If we remove it I would like to add a note that some
presentation processors may
... apply display styling.
Pierre: What about saying explicitly that it's important not to
specify tts:display because
... some interpretations may misinterpret it?
Glenn: Technically right now it's a non-standard extension,
which would need some parameterisation on the processor to
switch it off for strict conformance.
... I haven't checked if TTV points it out as a conformance
error right now.
Pierre: tts:display is not inheritable, so I think you don't
want people to specify tts:display
... on br because it might have an impact in TTPE where it
might not elsewhere. I'm suggesting
... we encourage authors not to add tts:display to br, which
avoids the problem because
... tts:display is not inheritable.
Glenn: [looks for test cases] I don't think I have any test
cases...
... I may regret this, but I'll remove my comment and
objection. I don't want to put a negative
... requirement in right now.
Pierre: Fine with me.
Nigel: Fine with me.
... Thanks Glenn.
APA comments
Pierre: I plan to have proposed resolutions to the APA comments
on IMSC 1.1 by next week
Meeting close
Nigel: Thanks everyone [adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [33]Replace "applies to" and "expresses" with "determines".
2. [34]We are willing to evaluate the use case for the new
writing-mode values but will defer this to a future version
of TTML.
3. [35]We will mark sidewaysLeft and sidewaysRight as at risk
for CR and continue to review the need for those features
and their alignment with CSS.
4. [36]Change "glyph" to "glyph area" in the quoted text.
5. [37]Add a normative statement that the behaviour for
mismatched rb and rt numbers (other than a single rt) is
implementation dependent.
6. [38]We will not make the requested change because it would
introduce a mismatch between the number of texts and bases,
and we currently do not define the behaviour in that case.
7. [39](updated following further discussion) All mismatches
will be left as implementation dependent behaviour, even if
the number of texts is 1.
8. [40]Remove rubyOffset and defer it to ttml.next
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [41]scribe.perl version
1.152 ([42]CVS log)
$Date: 2018/02/01 17:42:08 $
[41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[42] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 1 February 2018 17:44:47 UTC