Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko'

[akiseino]

Can you support both of "within an EM " and "not within an EM "
at text-combine-upright and tts:textCombine ?

I believe that 縦中横 'tate-chu-yoko' within an EM is supported by w3c / ttml2.
It can use up to 2 digits like 22.
But it's hard to read if it's 3 or 4 digits like 222 or 2222 within an EM. Because it's getting small.

Please support "not within an EM" for 3 and 4 digits to keep same size letter.
It means 2 digits letter within an EM and 3 (and 4) digits letter not within an EM should be same size.
To keep same size, it's necessary 0.25EM at both side in 3 digits and 0.5EM at both side in 4 digits like below.

At MS Word, we can select both by
Check box for "Fit in Line" at Horizontal in Vertical in Home Tab.

It would be very help if we can select both for the intent like above MS Word.
And it should be careful for 2nd line to avoid interference at the subtitling process.

Thank you.

[skynavga]

Thanks for your question Aki. The intention of the current specification of tts:textCombine is to permit an implementation to use a variety of techniques, which include both techniques that fit the combination into an EM square, "within an EM", as well as techniques that go outside of the EM square, "not within an EM".

In section §10.2.42 appears the following language, where I have highlighted the last sentence that supports "not within an EM" techniques.

Combination processing may make use of one or more techniques to obtain the goal of visual combination into an EM square of the surrounding vertical text. For example, half-width variant forms may be selected, a ligature may be selected, a smaller font size may be applied, etc. At a minimum, an implementation that supports this style property must be able to select half-width variant forms if available. If none of these techniques are able to achieve the target dimension along the block progression dimension of the containing line area, then this dimension of the containing line area may be increased if permitted by the line stacking strategy in effect.

Since TTML2 does not prescribe which rendering techniques are used (or favored) by an implementation, it is up to each implementation to decide whether a given combination should use an "in an EM" or a "not within an EM" rendering technique.

If you have any further questions or would suggest we modify the current text, please say so. Otherwise, if you are satisfied by this response, feel free to close this issue as you wish.

[palemieux]

it is up to each implementation to decide whether a given combination should use an "in an EM" or a "not within an EM" rendering technique.

It looks like @akiseino is asking that the author be able to specify a preference for not fitting characters at all within an EM.

As it stands, TTML2 and CSS clearly express a preference for typeset[ing] all consecutive characters within the box horizontally.

As an important data point, digital cinema subtitles behave the other way, and do not require/encourage/suggest that implementations typeset all consecutive characters within the box horizontally.

[akiseino]

Thank you for your answer, Glenn-san.

As @palemieux mentioned that, we typically use 4 digit like "2019" as tate-cyu-yoko to show year in vertical Japanese subtitle in digital cinema. And it contains some intents from director and translator for "looking good".

In that case, we prefer to use that as 4 digit sample which attached image in my previous for keeping the original intent.

To archive that, it's necessary 2 EM width instead of using smaller letter.
I'd like to ask to have option for that if it's impossible.
Thank you.

[skynavga]

@akiseino just to be clear, are you asking for an enhancement in TTML that allows an author to specify a preference for using an "inside EM" versus "outside EM" technique in the case that an implementation supports multiple techniques? or are you satisfied with the current specification text which makes this choice implementation dependent?

[akiseino]

@skynavga I'd like to ask enhancement in TTML that allows an author to specify a preference for using an "inside EM" versus "outside EM" technique in the case that an implementation supports multiple techniques. It would be very help for Japanese content. Thank you.

[skynavga]

@akiseino thanks for that clarification; I suspect this will be handled via a ruby extensions module being prepared, which will appear under [1]; I will bring to attention of WG for further processing

[1] https://github.com/w3c/tt-module-ruby-ext-1

[css-meeting-bot]

The Timed Text Working Group just discussed Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko' ttml2#1127, and agreed to the following:

• SUMMARY: TTWG will look at this in the context of a future Japanese enhancement module for TTML, in consultation with the CSS WG

The full IRC log of that discussion

<nigel> Topic: Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko' ttml2#1127
<nigel> github: https://github.com/w3c/ttml2/issues/1127
<plh> q?
<plh> Glenn: this started as a question which I answered with the current state. we allow both.
<plh> ... impls can choose any techniques they want
<plh> ... we don't give a preference
<plh> ... the commenter asked for an enhancement
<plh> ... so it's a request for a new feature
<plh> ... should be added to TTML3
<plh> ... comes under our ruby extension module
<plh> ... but we would be ahead of CSS
<plh> ... so, couldn't translate into CSS if we do this
<plh> Nigel: requirement is for enhancement for japanese subtitles
<nigel> -> https://github.com/w3c/tt-reqs/issues/12 Enhancements for Japanese subtitles
<plh> ... we agreed to work with the CSS Working Group on this requirement
<plh> Pierre: sounds good.
<plh> ... I think it's a use case. does anybody think it's not a valid use case?
<plh> Glenn: I worked in the print industry in the past, with explicit author control for this type of behaviors
<plh> ... it's out there in the industry
<plh> ... content creators would think they should be be able to do the same.
<plh> ... at the same time, TTMl2 is reasonable
<plh> ... some impls will go outside the em
<plh> ... so I'm ok to keep as-is but also ok with enhancing if CSS are ok with it
<plh> Pierre: would be good to share your experience
<plh> ... citing those use cases will be important to help the CSS WG make a decision
<plh> Glenn: sure
<plh> Glenn: Steve Zilles did research on this in the past and wrote documents about this
<plh> Pierre: let's add the data points before communicating with the CSS WG
<plh> Glenn: ok
<nigel> SUMMARY: TTWG will look at this in the context of a future Japanese enhancement module for TTML, in consultation with the CSS WG

[skynavga]

If there is no objection, I would like to move this issue to https://github.com/w3c/tt-module-cjk-ext-1, after which I will add a comment with a link to this new location in w3c/tt-reqs#12.

[palemieux]

• any reason not to use https://help.github.com/en/articles/transferring-an-issue-to-another-repository ?
• can the repos for the TTWG-managed modules be listed at https://github.com/w3c/ttml2/blob/master/README.md?

[skynavga]

@palemieux that is how I would move (transfer) this issue, a process I have used previously, e.g., to move TTML2 issues into the TTML3 repo; I will add pointers to the README once we have merged #1096 (for which I requested your re-review yesterday);

[palemieux]

@skynavga By the way, how would a module add a permitted value to a core style property? A modules can easily add foreign attributes/elements since they are pruned/ignored by implementations that do not understand the module. The same is not true about values of style properties.

[skynavga]

@palemieux it could not; it would have to be added by modifying the original specification of that property, which would have to be done in a new major version (since this would be a substantive functional addition), or, if it could be argued that the modification were a bug fix (e.g., a value should have been specified but was inadvertently omitted), then it could be done in a new edition (i.e., new minor version);

[palemieux]

Makes sense. So perhaps it is too soon to move this issue to another repo since a solution might be to introduce additional values for tts:textCombine.

[skynavga]

In this case, it would have to be moved to TTML3, since this is definitely not in the bug fix category. I was planning to draft this as a new property, e.g., tts:textCombineStrategy, which would be at home in the cjk-ext-1 module and not require modifications to any version of the TTML core modules.

[palemieux]

tts:textCombineStrategy

This could work, but will ultimately depend on CSS WG's feedback, right? They may introduce additional values to text-combine.

I suggest just leaving the issue here for now. Just a suggestion...

[skynavga]

Even if CSSWG were to introduce new values to text-combine, that does not mean we would have to do so. A TTML renderer that uses CSS could merely map a combination of tts:textCombine and tts:textCombineStrategy to future defined CSS text-combine values. If we were going to add one more new values to tts:textCombine itself, we would have to do so in TTML3, so, in any case, this issue needs to move somewhere that is not TTML2. I'm going to go ahead and move it to https://github.com/w3c/tt-module-cjk-ext-1 where I can draft a preliminary proposal to add a tts:textCombineStrategy property to handle this enhancement request. Then we will have something concrete to point at in order to discuss the technical details and interface with the CSSWG.

[nigelmegitt]

A TTML renderer that uses CSS could merely map a combination of tts:textCombine and tts:textCombineStrategy to future defined CSS text-combine values.

This is indeed possible, but would be somewhat messy. Our agreed general approach is to try to converge with CSS where possible.

[skynavga]

(1) there is nothing in CSS to which we might converge; (2) there are other reasons we should not add a new keyword value, as opposed to defining a new style property: (i) it means changing the core specification, which in this case means TTML3 (and thus it would not be available for use in TTML2) and (ii) we already have ample precedent of using tts:*strategy properties to parameterize another property, cf. tts:fontSelectionStrategy and XSL-FO's line-stacking-strategy which we refer to but do not (yet) use directly; on the other hand, this is an entirely hypothetical discussion at this point since neither CSS nor we have defined anything yet, so it will be best to have something on the table to talk about, and I plan to draft that as tts:textCombineStrategy at this point; that will give us and CSS something to refer to;

[nigelmegitt]

there is nothing in CSS to which we might converge

Agreed, this is rather hypothetical at the moment.

[nigelmegitt]

Discussed in joint meeting with CSS WG today. minutes to be added by reference when available. Log: https://www.w3.org/2019/09/15-css-irc#T00-57-05

Workaround might be inline-block, but if emphasis, underline, ruby etc need to be included, then need to know how! Need to raise issue on CSS writing-modes level 4

[palemieux]

Opened w3c/csswg-drafts#4319

[palemieux]

@akiseino Your input would be much appreciated on the questions raised at w3c/csswg-drafts#4319 (comment)