How would someone display ruby inline?

[r12a]

10.2.39 tts:rubyPosition
https://www.w3.org/TR/2016/WD-ttml2-20161117/#style-attribute-rubyPosition

Is there a way to make the ruby display inline when desired?

Note that there are two possibilities here. Given a word such as 東京, the user may want to produce

a. 東(とう)京(きよ), or
b. 東京(とうきよ)

from the same markup. The second approach tends to be used for compoun nouns in Japanese.

[dae-kim]

If by "the user" we mean the subtitle author, they should type the parenthesis and inline ruby as a normal sequence of text.

If we're talking about a processor's lack of ruby support, I'm open to defining some fallback mechanism in place of "ignore and move on".

[dae-kim]

@r12a can you clarify which "user" you were referring to? The author or the processor?

[dae-kim]

@nigelmegitt
Original comment seems to suggest an author intends ruby to be displayed inline as a sequence of parenthesized text. This can be done and does not need the use of ruby attributes.

Given that Japanese subtitle authors and consumers do not expect this type of functionality, I suggest we close as non-issue.

[nigelmegitt]

@dae-kim I'd be happy to have clarification on this from @r12a but I think there may be a misunderstanding:

... I wonder if @r12a may have misunderstood the options currently available for the equivalents of CSS styling of Ruby markup in TTML2. Whereas in CSS parenthesis can be generated using CSS (see CSS Ruby Level 1 Appendix A.3 for example) when Ruby support is not otherwise present, this cannot be done in TTML2; there's no fallback presentation styling in TTML2 when the tts:ruby[***] attributes are not supported.

So in that sense, if @r12a was making the distinction between HTML style semantic "markup" and CSS style "styling" that simply does not seem to be applicable in TTML2 as far as I can see. It's an interesting idea that we could specify fallback presentation styles, perhaps using parenthesis, as an inline styling, but I think there's a simple answer to the question in the issue:

Is there a way to make the ruby display inline when desired?

which is: No. At least not at the moment. If the document is intended for presentation with Ruby then it needs to be processed by a processor that supports Ruby. Otherwise as @dae-kim pointed out above, if it is intended for presentation as inline "not really" Ruby then the Ruby annotation can be omitted and parenthesis inserted instead. We do not currently handle the same document being presented by both processors that do, and that do not, process Ruby correctly. Perhaps this is the key to this issue.

@r12a does that make sense to you? Is this something we should be able to live with as is?

[r12a]

Ok, so i guess it's not possible to choose to display ruby over the base or alongside in parentheses by choosing a particular style, rather than changing the markup.

The use cases where this may apply, in the CSS world, include:

1. the text is too small for ruby annotations to be read easily in a particular context
2. a study has shown that dyslexic readers of japanese find the complexity of ruby annotated kanji difficult to handle, and so if you were looking to make life easier for such people you could style the ruby so that it appears inline after the base (or even replace the base).

I didn't really have in mind the use case where ruby isn't supported by the application rendering the text.

If you were to say to me that such use cases as i listed above, where the author selects whether to display inline or not (while using the same markup), are not relevant for timed text, that would probably render my initial question moot.

[nigelmegitt]

Hmm let's take those one by one.

1. text is too small for ruby annotations to be read easily.

Generally it is the responsibility of the author to make sure that the text size is big enough; however it is the case that for subtitle and caption use, in general, the size is proportional to the size of the video, so if the conditions are right, it could be that the text is too small. This would possibly be a case for using media queries and conditional display, and in that case we don't allow for conditional styling of Ruby to switch between parenthesis and alignment, but we do allow for conditional content, i.e. it is possible to insert markup like <span condition="some_param='small'">(</span> which would be extremely verbose. To do this with a ruby-specific style attribute could be done but would be an additional syntax and semantic not currently present.

2. let's generalise to "reader preference" for convenience. This is presumably a user-specified style preference. TTML doesn't allow for this in general, but the same kind of solution as above could be done if there is a user setting that can be passed into a conditionally applied "ruby presentation style" parameter.

So technically there are ways to solve this, and I for one cannot exclude use case 1 from being relevant for timed text; others may be able to.

[cconcolato]

Should we add notes in the spec to reflect @nigelmegitt ways to solve the problems?

[skynavga]

I would suggest adding a worked out example with sample rendering.

[nigelmegitt]

I would suggest adding a worked out example with sample rendering.

Sounds good to me.

[cconcolato]

After reading the spec again, I found the following paragraph:

When performing normal presentation processing of ruby text annotations, delimiter content must not generate any inline areas. When performing fallback presentation of ruby, both delimiter and non-delimiter ruby (base and text) content must generate normal inline areas.

and then:

For the purpose of presentation processing, the violation of any of these constraints should result in fallback (inline) presentation of ruby text annotations.

This means that Richard's use case can be solved by using 'invalid' document. Shouldn't we simply permit rendering using the fallback mechanism?

Alternatively, we could define a new feature designator #ruby-fallback and let profiles select which of #ruby or #ruby-fallback, potentially both.

[nigelmegitt]

Shouldn't we simply permit rendering using the fallback mechanism?

Yes, makes sense to me, depending on the document processing context, i.e. a user setting.

[r12a]

Ok, so if the syntax is problematic or "a presentation processor does not support ruby presentation, then it must perform fallback ruby presentaton" (typo there btw), which means inline display of the annotation; but there's no way for an author to request inline display if they decide they want it.(?)

[cconcolato]

Typo fixed in d70f967

Indeed, there is currently no way for an author to request inline display (besides creating a document that has an invalid syntax, e.g. placing a empty delimiter in a wrong location). Nobody has expressed the need to specify it so far. This could be added in a future version IMO.

Can you approve the PR?

[r12a]

The i18n WG has closed its tracker for this issue.