W3C

Timed Text Working Group Teleconference

01 Feb 2018

See also: IRC log

Attendees

Present
Nigel, Thierry, Glenn, Andreas, tmichel, Cyril, Pierre
Regrets
None
Chair
Nigel
Scribe
nigel

Contents


<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.

Issues and pull requests marked Agenda

group: [no other business]

Incorporate resolutions of additional TTML1 Issues. ttml2#358

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

A single length value for tts:fontSize specifies both height and width. ttml2#548

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

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: 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: 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.

CSS Writing Modes Level 4 WD

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.

Upright orientation involves more than just glyph orientation ttml2#281

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

How to handle mismatched sequences in complex ruby ttml2#247

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

Complex ruby is usually both mono and group ruby ttml2#246

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

How to handle mismatched sequences in complex ruby ttml2#247

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

rubyOffset and line-spacing ttml2#252

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

Remove animate, begin, dur, end, region and timeContainer of br elements (#552). ttml2#570

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.

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. Replace "applies to" and "expresses" with "determines".
  2. 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. 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. Change "glyph" to "glyph area" in the quoted text.
  5. Add a normative statement that the behaviour for mismatched rb and rt numbers (other than a single rt) is implementation dependent.
  6. 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. (updated following further discussion) All mismatches will be left as implementation dependent behaviour, even if the number of texts is 1.
  8. Remove rubyOffset and defer it to ttml.next
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/02/01 17:42:08 $