See also: IRC log
<scribe> scribe: nigel
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.
Issues and pull requests marked Agenda
group: [no other business]
github: 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
github: 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
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.
github: 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
github: 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.
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.
CSS Writing Modes L3 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.
github: 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
github: 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
github: 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
github: 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
github: 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
github: https://github.com/w3c/ttml2/pull/570 (pull request)
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.
Pierre: I plan to have proposed resolutions to the APA comments on IMSC 1.1 by next week
Nigel: Thanks everyone [adjourns meeting]