Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruby align 'withBase' semantics #248

Closed
r12a opened this issue Feb 16, 2017 · 19 comments

Comments

Projects
None yet
7 participants
@r12a
Copy link

commented Feb 16, 2017

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.

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Author

commented 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

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Author

commented Mar 6, 2017

A key recommendation would be to remove it from the expectation of what happens when you specify the auto value.

Are you saying 亜(あ)麻(ま)仁(に) is supposed to render differently than 亜麻仁(あまに)?
Can you attach some examples of this?

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

This comment has been minimized.

Copy link
Contributor

commented 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 dae-kim self-assigned this May 8, 2017

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Contributor

commented May 16, 2017

The only actionable item here is to suggest we add a note encouraging authors to use 亜(あ)麻(ま)仁(に)
instead of 亜麻仁(あまに)

@r12a thoughts?

@skynavga

This comment has been minimized.

Copy link
Collaborator

commented 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

This comment has been minimized.

Copy link
Author

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

@skynavga

This comment has been minimized.

Copy link
Collaborator

commented May 18, 2017

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2017

@nigelmegitt @skynavga
Agree with #248 (comment).
Suggest we close.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented 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?

@r12a

This comment has been minimized.

Copy link
Author

commented Jul 10, 2017

Let's add a note, and move on.

@r12a r12a referenced this issue Jul 10, 2017

Closed

rubyAlign withBase #39

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2017

Great, thank you @r12a . @dae-kim would you like to draft the note?

@r12a

This comment has been minimized.

Copy link
Author

commented Aug 17, 2017

Please let us know if/when you have added the note referred to above, and we will close the pointer to this issue in our review tracker. Thanks.

@skynavga skynavga added this to the Editor's CR Work List milestone Aug 21, 2017

@skynavga skynavga assigned skynavga and unassigned dae-kim Aug 21, 2017

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Aug 31, 2017

The Working Group just discussed ttml2#248 rubyAlign withBase.

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.

@skynavga skynavga changed the title rubyAlign withBase Ruby align 'withBase' semantics Sep 14, 2017

@tmichel07 tmichel07 added the WR-pending label Oct 2, 2017

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented 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 CR
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.

@skynavga skynavga assigned nigelmegitt and unassigned skynavga Jan 15, 2018

@skynavga

This comment has been minimized.

Copy link
Collaborator

commented Jan 15, 2018

Resolution #248 (comment) is addressed by #553.

@cconcolato cconcolato added the pr open label Jan 15, 2018

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2018

@r12a marked #553 as okay, so labelling as wr-commenter-agreed and closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.