Incorporate CSS advances into TTML vertical text handling

[r12a]

10.2.52 tts:writingMode
http://w3c.github.io/ttml2/spec/ttml2.html#style-attribute-writingMode

10.2.46 tts:textOrientation
http://w3c.github.io/ttml2/spec/ttml2.html#style-attribute-textOrientation

I think it would be useful to make the text in this section more closely resemble the approach in CSS, recent developments for which, i believe, have fixed some issues related to vertical text handling which apply to the model described for TTML.

CSS has the following values for vertical writing modes:
vertical-rl (equivalent to tbrl)
vertical-lr (equivant to tblr)
sideways-rl
sideways-lr

The latter two values are intended for use with 'horizontal scripts' when one wants to set them vertically (usually alongside something). They are useful additions because they effectively rotate the progression of lines in one direction or the other, which is what you typically need for such use cases. This affects where the start and end points lie, and how text will wrap to the next line, as well as the default orientation of the characters. For example, for sideways-lr, start is at the bottom of the vertical line, Latin characters would lie on their left side, and lines would wrap when they reach the top of the vertical line. These are things that don't happen with vertical-lr.

I believe there are some technical advantages to this approach, but also it will help authors if the models for TTML and CSS are similar.

Perhaps there will be some resistance because vertical text values such as sidewaysLeft and sidewaysRight existed previously in TTML, i'm not sure. If so, and therefore things can't be removed, then i suggest that sideways-rl and sideway-lr values be added, and the user be advised to use those rather than the sidewaysLeft and sidewaysRight values of tts:textOrientation.

(The TTML model also doesn't adopt all of the values used in XSL, and so the -rl and -lr parts of tb-rl and tb-lr don't have equivalents in the vertical text values. In CSS the inline direction of the block is not indicated by an explicit -rl/-lr on the container. That is set by the direction property. I'm guessing that you don't want to go there.)

[nigelmegitt]

[scheduled for initial discussion 2017-03-23]

[r12a]

So i spoke with @fantasai about this during the i18n call, and here is a summary. The writing-modes values of sideways-lr and sideways-rl have been deferred to CSS Writing Modes Level 4 purely in order to speed up the progress of Writing Modes level3 to PR, which is hopefully imminent. There are no plans to drop the sideways- values of writing-modes, quite the contrary, CSS is just waiting on a second implementation to be completed, but want to publish the rest of the spec as a Rec sooner than that will happen. The plan is to publish Level 4, containing just those values, and move to CR almost immediately, where it will await the completion of the second implementation.

So i don't think TTML needs to worry about following a similar path in terms of adding sideways- writingMode values.

[css-meeting-bot]

The Working Group just discussed Incorporate CSS advances into TTML vertical text handling ttml2#277, and agreed to the following resolutions:

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

The full IRC log of that discussion

<nigel> Topic: Incorporate CSS advances into TTML vertical text handling ttml2#277
<nigel> github: https://github.com/w3c/ttml2/issues/277
<nigel> Cyril: My problem with this is, at least at Netflix, we want to align better with CSS in the future,
<nigel> .. and I wouldn't want to make changes in TTML2 that make such alignment impossible in the future.
<nigel> Nigel: +1
<nigel> Glenn: We have some study of mapping of TTML and CSS, and for writingMode we had
<nigel> .. concluded that there is a mapping available.
<nigel> Nigel: I believe so.
<nigel> Cyril: Writing Mode in CSS has additional values we don't have.
<nigel> Glenn: But we do have all of them. We just have different keywords.
<nigel> Nigel: Do we have sideways-left and sideways-right that weren't in XSL-FO?
<nigel> Glenn: Yes, you use writingMode and textOrientation together.
<nigel> Cyril: I think it's okay for writingMode, because CSS defines how to map the old values to
<nigel> .. the new ones for writing-mode.
<nigel> .. In CSS level 3 or 4, the spec defines the interaction between writing-mode, text-orientation,
<nigel> .. direction, text-combine and so on. I have no idea what the interaction between those
<nigel> .. properties are, for example textCombine and textOrientation.
<nigel> Glenn: They are independent.
<nigel> Cyril: They cannot be, or what's the order in which they are applied?
<nigel> Glenn: textCombine only applies potentially when some segment of text does not have the
<nigel> .. same text orientation as its surrounding text.
<nigel> Cyril: When horizontal text is upright in vertical text.
<nigel> Glenn: Yes, so if textOrientation were sideways then it would never apply. If you put
<nigel> .. Japanese text inside English text for example, and the outer portion is sideways, then I
<nigel> .. guess in that case you would set the Japanese text sideways as well so textCombine would
<nigel> .. not apply either.
<nigel> Cyril: We can find examples - my general question is I don't know how to fix the spec without
<nigel> .. referring to CSS and saying do what they say.
<nigel> Glenn: I don't think there's anything broken right now.
<nigel> Cyril: There's nothing in the spec that defines the processing model for textCombine and
<nigel> .. writingMode.
<nigel> Glenn: There's a great deal not defined.
<nigel> Cyril: Exactly.
<nigel> Glenn: Over time we can add more language to the spec, but we won't need additional keywords.
<nigel> .. So one issue it that Richard's comment is asking to add two additional values to writingMode.
<nigel> Cyril: I can say we won't do this now but might do it alter.
<nigel> s/alter/later
<nigel> Glenn: That's appropriate.
<nigel> Cyril: Then can we resolve this?
<nigel> 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.

[nigelmegitt]

@r12a Bringing the above resolution to your attention.

[fantasai]

FWIW: https://www.w3.org/TR/css-writing-modes-4/

[r12a]

[i passed this by Fantasai for a sense check before posting, and she said LGTM]

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.

I believe that conclusion is incorrect. The sideways-x values of writing modes in CSS effectively rotate the lines of horizontal text rather than rotating characters. This has significant benefits for managing side-on horizontal text (such as preserving start and end where you'd expect, and automatically wrapping text after line breaks in the right direction). It's essentially just a 90º transform of the text box.

CSS works on the basic premise that in the normal use case text-orientation is only needed for vertical-rl/lr values of writing-modes, and that those are tightly bound with Japanese, Chinese, Korean and Mongolian usage. This is where it is normal to find some characters that would normally be side-on switched to upright (eg. in acronyms such as FIFA).

My understanding is that the chance of ideographic or kana or hangul text needing to be rotated in vertically set text is extremely unlikely. The sideways value of text-orientation is, iiuc, a relic – (which explains why there's no -90º rotation) that is not expected to see much use. The sideways-rl/lr values of writing-modes should do that job.

As i understand it, therefore, In CSS and in the overwhelming majority of use cases, the text-orientation property is really only there to address the need to stand certain letters upright in vertical lines of CJKM content (or other scripts with a natural vertical text orientation).

I therefore recommend that TTML drops or marks as at-risk the sidewaysLeft and sidewaysRight values of tts:textOrientation, and possibly sideways also, in favour of increased compatibility with CSS in the next version through introduction of the sideways-rl/lr values for the writing-modes property.

[nigelmegitt]

Thank you @r12a I've added this to the agenda for tomorrow's call. It may be possible to modify our resolution so that we adopt your recommendation, which I see still defers introduction of sideways-rl/lr into tts:writingMode, in other words, it is a low cost option to mark features as at risk in CR and I think that's all you're proposing for now.

[r12a]

Btw, the at-risk notes about the sideways-rl/lr values of writing-mode in the editor's draft of CSS writing-modes level 4 are now gone.

[nigelmegitt]

@r12a Thank you, that's good to know.

[cconcolato]

Given that tts:textOrientation sidewaysLeft and sidewaysRight are already marked at risk (see w3c/ttml2#637), the only point to discuss is whether we want to mark sideways at risk too, but it is only a suggestion by @r12a . The inclusion of new values in tts:writingMode can only be envisaged in a next version of TTML.

[nigelmegitt]

The current status is that we have no feature designator exclusively for the sideways value and have not marked it as at risk. Unless there is any new call to do so, I propose that we close this issue with no further change.

[css-meeting-bot]

The Working Group just discussed Incorporate CSS advances into TTML vertical text handling ttml2#277, and agreed to the following:

• RESOLUTION: Close without marking sideways as at risk

The full IRC log of that discussion

<nigel> Topic: Incorporate CSS advances into TTML vertical text handling ttml2#277
<nigel> github: https://github.com/w3c/ttml2/issues/277
<nigel> Nigel: The status of this is that we could mark sideways as at risk but do not have a
<nigel> .. feature designator for it.
<nigel> .. Any views?
<nigel> Cyril: I vaguely remember we decided not to mark as at risk because it was implemented.
<nigel> Nigel: OK I didn't recall that.
<nigel> Cyril: Maybe Glenn mentioned it was implemented.
<nigel> Glenn: Yes, we have all the current values implemented.
<nigel> Cyril: Is there a risk to marking it as risk?
<nigel> Glenn: No
<nigel> Nigel: Two downsides:
<nigel> .. 1. Suggests non-implementation
<nigel> .. 2. Editorial work to add the feature designator
<nigel> Cyril: I don't think the argument for not inviting implementation is a practical problem
<nigel> .. given the current implementation status.
<nigel> Glenn: I think it's unnecessary work and we should not mark sideways as at risk.
<nigel> .. It's implemented.
<nigel> Nigel: You have one implementation for it?
<nigel> Glenn: I have a presentation implementation and another member has a validation implementation
<nigel> .. so it satisfies the criteria.
<nigel> Nigel: Ok then we don't need to mark it as at risk.
<nigel> Glenn: As a general comment I'm worried about proliferation of feature designators. We
<nigel> .. went from around 114 to about 250, so we've doubled the designators but we haven't
<nigel> .. doubled the number of features. Compared to TTML1.
<nigel> Nigel: Can we resolve to close this with no further change?
<nigel> Glenn: No objection
<nigel> Nigel: Anyone else?
<nigel> RESOLUTION: Close without marking sideways as at risk