Repository navigation
Ruby align 'withBase' semantics #248
Description
10.2.34 tts:rubyAlign
https://www.w3.org/TR/2016/WD-ttml2-20161117/#style-attribute-rubyAlign
If the value of this attribute is withBase, then, if NR and NB are equal, the ith glyph area descendant of IR is center aligned (horizontally or vertically) with the ith glyph area descendant of IB; otherwise (the number of ruby and base glyph areas are not equal), the semantics of center apply.
For a discussion of what constitutes a glyph area descendant see #236
I can't really understand the use case for this value. I'm assuming that the mapping of ruby text to base text should normally be achieved using markup, since that's where the semantics happen. I'm finding it hard to imagine a situation where NR and NB are likely to be equal other than the cases where you have one of each eg. 亜(あ)麻(ま)仁(に), much less when you'd want the ruby text and base text to be aligned with the each other.
I think this could encourage authors to use poor markup, such as 亜麻仁(あまに) rather than 亜(あ)麻(ま)仁(に) , which would cause problems for line breaking. It could also produce some false positives.
And if NR and NB are equal in some text, given that this is the default for auto, i think it might produce surprises, since it would produce a different alignment on those cases, whether you intend that or not.
Activity
dae-kim commentedon Mar 3, 2017
It might be helpful to add a note discouraging 亜麻仁(あまに) ... but this is necessary IMO for interop with older Japanese formats like Lambda CAP.
The vast majority of Lambda CAP files employ the "withBase" method to markup ruby 亜麻仁(あまに).
Whether this is ideal or not -- we should attempt to preserve the authored data best we can.
And I can see a situation where an author/implementer wants to use this method to preserve as many bits as they can at the expense of rendering risks.
r12a commentedon Mar 4, 2017
What puzzles me though is that it seems to me that the likelihood that this will be useful is extremely rare. If i understand correctly, the way it is specced in TTML2 is that you'd need a sequence of base characters with a single character annotation each for this to be applied. Even to find one base character annotated with a single annotation character is rather rare for pinyin associated with Chinese, and a sequence of those pairs is, i suspect, vanishingly rare. Same goes for Japanese, actually. It took me a while searching through my kanji dictionary to find the 亜(あ)麻(ま)仁(に) example, because a large percentage of ruby annotations in Japanese use two or more hiragana characters (eg. ending in ん) per base character, and for withBase to apply you'd need a sequence of base characters each of which had a single hiragana character annotation for this to be a useable feature.
(That's why i was concerned about the surprise factor when using this as a default – it seems that only in rare cases would it be applied, and then it would change the rendering perhaps in a way the author hadn't expected.)
dae-kim commentedon Mar 6, 2017
I'm not sure what the recommendation is here. Are you asking we remove withBase altogether? I'd rather not sift through a number of Lambda CAP files to find examples of this ... but since withBase only applies when this extremely rare situation occurs, what is the harm in wording it the way it is now?
Re: "And if NR and NB are equal in some text, given that this is the default for auto, i think it might produce surprises, since it would produce a different alignment on those cases, whether you intend that or not."
Are you saying 亜(あ)麻(ま)仁(に) is supposed to render differently than 亜麻仁(あまに)?
Can you attach some examples of this?
r12a commentedon Mar 6, 2017
A key recommendation would be to remove it from the expectation of what happens when you specify the
autovalue.No, not that. I was saying that the vast majority of ruby will not have an identical number of base and annotation characters, and will be rendered as spaceAround or spaceBetween, but on the odd occasion that the number of character is the same, or actually sometimes just by coincidence if group ruby is used, a different positioning will occur, ie. centre-positioning of each ruby character above each base. It seems odd to me, and may seem unexpected to content authors, when that change in alignment crops up.
Another recommendation would be to add a note to say that this is included for legacy content, but that really base characters ought to be mapped to their specific annotations (unless this is real group ruby), and so there shouldn't be a need for it.
Having said that, i'd be curious to see examples from Lambda CAP of this in use, in order to better understand how it is used there. It could be that it looks ok for some percentage (but not all) of jukugo ruby, such as 凝視(ぎょうし), where the mapping is of rt to rb is actually 3:1, 1:1, but the markup presents this as group ruby which looks about right, but then the ruby won't behave like jukugo should, eg. for wrapping. Or it could be just that it's based on an overly simplistic idea as to how ruby postioning works.
dae-kim commentedon Mar 7, 2017
Actually, I just realized Lambda CAP expects withBase if number of base = number of ruby.
But in terms of Lambda CAP files, it is more common to see this:
＠ルビ上［BASE｜RUBY］＠
Than this:
＠ルビ上［B｜R］＠＠ルビ上［A｜U］＠＠ルビ上［S｜B］＠＠ルビ上［E｜Y］＠
dae-kim commentedon May 9, 2017
I don't anticipate TTML2 authors be surprised by the semantics of "auto" since it's reasonable to assume they read the prose before authoring.
The only actionable item here is to suggest we add a note encouraging authors to use 亜(あ)麻(ま)仁(に)
instead of 亜麻仁(あまに)
dae-kim commentedon May 16, 2017
The only actionable item here is to suggest we add a note encouraging authors to use 亜(あ)麻(ま)仁(に)
instead of 亜麻仁(あまに)
@r12a thoughts?
skynavga commentedon May 16, 2017
I would oppose adding the note you suggest in the previous comment. My position on this matter can be basically summarized as follows: RTFM applies; author expectations are too diverse to generalize, so it is inadvisable to assume a particular mis-reading (of the spec). If authors want a particular behavior, then they should not use auto, they should use the value needed to obtain the value they require.
In conclusion, I see no actionable change proposed here, and suggest this issue be closed and marked WORKS FOR ME.
r12a commentedon May 18, 2017
The main point of this issue resolves around my expectation that the chance of the number of characters in the annotation and the base being the same is somewhere between rarely to very rarely. If
rubyAlignis set toauto, thewithBasevalue kicks in only in those circumstances, and it will produce a different alignment for the annotation to that which is more commonly used (ie.spaceAround/spaceBetween– which btw is also different from the fallback whenwithBaseis applied explicitly). I can't discern a reason for producing such a change in alignment for those few cases.The default behaviour for
ruby-alignin CSS is space-around (and i believe that's what the browsers do also by default).The actionable change i'm looking for is to remove
withBasefrom the expected behaviour ofauto.If people want to produce this unusual behaviour, let them set
withBaseexplicitly.skynavga commentedon May 18, 2017
dae-kim commentedon Jul 7, 2017
@nigelmegitt @skynavga
Agree with #248 (comment).
Suggest we close.
nigelmegitt commentedon Jul 10, 2017
Reading back through this thread it seems that there are existing practices for "auto" in Lambda CAP and CSS that differ from each other. TTML2 currently adopts the Lambda CAP default but provides a mechanism to specify a different behaviour.
There's some willingness to add a note calling out this case. I would favour adding such a note as a resolution hopefully that will satisfy @r12a , if it indeed would do so?
8 remaining items
css-meeting-bot commentedon Nov 9, 2017
The Working Group just discussed
Ruby align 'withBase' semantics #248, and agreed to the following resolutions:RESOLUTION: Mark rubyAlign="withBase" as at risk for CRThe full IRC log of that discussion
<nigel> Topic: Ruby align 'withBase' semantics #248<nigel> github: https://github.com//issues/248
<nigel> cyril: Netflix doesn't use "withBase" so possibly a solution would be to defer this functionality.
<nigel> r12a: We were quite surprised about withBase. My understanding is that this withBase is a
<nigel> .. thing that lambdaCap does so it is in the spec.
<nigel> glenn: It came out of my analysis of what would be needed to support lambdaCap.
<nigel> pal: If there are no lambdaCap files including it, then it would be safer to put it at risk or remove it.
<nigel> nigel: We are working towards CR now so we could mark it at risk now.
<nigel> flick: That would be a signal to people who are interested.
<nigel> RESOLUTION: Mark rubyAlign="withBase" as at risk for CR
<nigel> glenn: If it is an optional feature and our exit criteria require one implementation of each
<nigel> .. optional feature then this is already satisfied.
<nigel> r12a: I checked my dictionary for any examples where this would apply, and could not find any.
<nigel> .. Either in Japanese or with Pinyin. So it was all a bit weird to me.
<nigel> glenn: I'm pretty sure there's language on this in the lambdaCap spec also.
<nigel> .. I think withBase may be being used under the covers in the Netflix implementation without it being obvious.
<nigel> glenn: The currently defined auto semantics for rubyAlign is based on withBase when Nr = Nb.
<nigel> .. That encodes the lambdaCap semantics in the semantics for auto.
<nigel> cyril: But we are requesting that auto be changed to center.
<nigel> nigel: And that doesn't use withBase?
<nigel> glenn: No, when center is used it doesn't use withBase semantics, it doesn't distribute any space between the ruby glyphs.
<nigel> cyril: We'll take it offline and come back with an issue.
skynavga commentedon Jan 15, 2018
Resolution #248 (comment) is addressed by #553.
nigelmegitt commentedon Jan 29, 2018
@r12a marked #553 as okay, so labelling as wr-commenter-agreed and closing.