Ruby align 'withBase' semantics #248
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.
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 亜麻仁(あまに).
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.
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.)
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 亜麻仁(あまに)?
A key recommendation would be to remove it from the expectation of what happens when you specify the
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.
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 亜(あ)麻(ま)仁(に)
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.
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
The default behaviour for
The actionable change i'm looking for is to remove
If people want to produce this unusual behaviour, let them set
On Thu, May 18, 2017 at 10:25 AM, r12a ***@***.***> wrote: 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 rubyAlign is set to auto, the withBase value 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 when withBase is applied explicitly). I can't discern a reason for producing such a change in alignment for those few cases. The default behaviour for ruby-align in 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 withBase from the expected behaviour of auto. If people want to produce this unusual behaviour, let them set withBase explicitly.
One of the key drivers for ruby functionality in TTML2 has been support for the Lambda CAP format, which specifies exactly the behavior presently defined for 'auto'. There are a number of early implementations of these new TTML2 features already deployed in the Japanese market. During a number of reviews of this feature and its operational use, there was no suggestion that this behavior should change or even that it was rare. Your argument at present is essentially that the definition of a default semantic for 'auto' does not represent your expectations about what is common in content, but you don't cite any studies or data to back up this expectation. I presume (without evidence) that the designers of Lambda CAP (in Japan) had good cause to choose this behavior, and that it did not give rise to unreasonable surprises on the part of content authors. As has been pointed out, an author does have a mechanism to specify a different default value. Perhaps a note could be added to call out this case so that authors could be forewarned, but that is about the extent I would agree with making a spec change.…
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#248 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCbybn_dJCXxuHlLGccvasqY-ZMSASks5r7HD3gaJpZM4MDTrr> .
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?
The Working Group just discussed
The full IRC log of that discussion<nigel> Topic: ttml2#248 rubyAlign withBase
<nigel> github: https://github.com//issues/248
<nigel> Glenn: On this one, no real discussion, but I realised I need to add a note to that i18n can
<nigel> .. sign off on it, so I should be able to take care of that without any further input. I'll do this
<nigel> .. unles Dae steps in and does so.
The Working Group just discussed
The 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.