W3C home > Mailing lists > Public > public-tt@w3.org > February 2018

{minutes} TTWG Meeting 2018-02-01

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


          Nigel, Thierry, Glenn, Andreas, tmichel, Cyril, Pierre





     * [3]Topics
         1. [4]This Meeting
         2. [5]Incorporate resolutions of additional TTML1 Issues.
         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
         5. [8]Incorporate CSS advances into TTML vertical text
            handling ttml2#277
         6. [9]Sideways shouldn't be tied to tblr vs tbrl
         7. [10]Upright orientation involves more than just glyph
            orientation ttml2#281
         8. [11]How to handle mismatched sequences in complex ruby
         9. [12]Complex ruby is usually both mono and group ruby
        10. [13]How to handle mismatched sequences in complex ruby
        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
   ... 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

   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

   <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

   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

   Glenn: They are independent.

   Cyril: They cannot be, or what's the order in which they are

   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

   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

   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

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

   Glenn: [agrees, especially since it has already been
   ... 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

   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

   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

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

   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

     [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

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

This archive was generated by hypermail 2.3.1 : Thursday, 1 February 2018 17:44:47 UTC