Mojikumi rules in body text vs. ruby

[stantonma]

CSS has the following definition for ruby-align:space-around:

The ruby content expands as defined for normal text justification (as defined by text-justify), except that if there are no justification opportunities the content is centered.

https://www.w3.org/TR/css-ruby-1/#ruby-align-property

The interesting part here is that it implies ruby text and body text should share the same mojikumi table. We're looking for feedback if that's truly correct, or if there could be exceptions.

At least one scenario that might need an exception is adding 1/2 em before opening brackets at the start of a paragraph, which seems like it shouldn't apply for ruby text.

[macnmm]

This is a bit of an edge case -- you are saying that in the case of ruby text containing punctuation and having different edge spacing rules than the body text paragraph... I would be fine saying there is not a need for ruby to have a different mojikumi set from the body text paragraph, especially if the editor can set custom mojikumi spacing on runs of text or runs of ruby.

[stantonma]

Maybe a better example is latin text in a ruby. In the main line, no space is added between consecutive latin characters (at least in browser's implementation). In ruby it may be desired to add this space, though seems like something the author would ideally want to control. Unfortunately in the ePub/CSS world authors don't have this control currently.

Here's one example of this in print, though there are also many showing the browser behavior.

[stantonma]

Maybe this is just a no-op, in that we recognize there are different situations which require different mojikumi rules - and as such should figure out a way to make sure authors have control where needed.

[macnmm]

Since ruby spacing rules are kind of specific (the above crazy example of a group ruby with JIS-style justification (each letter spaced out, not only the spaces)), It would seem that you could declare it needs to be possible to have an entire paragraph style level of control for just that ruby. Or, figure out what spacing rules are missing from the ruby spec and make new ones just for ruby spacing control (e.g. space each glyph in Roman ruby vs only use spaces, etc).

[stantonma]

Given the example above (even if it may be rare), what are your thoughts on loosening some of the wording here and indicate that in some cases (long ruby bases?) it may be better to add the inter-character spacing?

On the other hand, when the base text or ruby text is Latin word, the word is set with western solid setting, and no inter-character space will be added to any ruby or base text in Latin characters no matter how different the ruby and base text look in length (see Fig. 3.56). Details will be explained later.

https://www.w3.org/TR/jlreq/#fig2_3_7-en

[macnmm]

I am not sure the example above is considered best practice -- I would imagine that the editors of JLReq are saying in their opinion no inter-letter space should be set, as it adversely affects legibility (and I think I agree). However, this statement could be worded such that if an implementation wishes not to overly restrict the user there are several ways to set ruby so that it a) correctly identifies the base text by being over it and b) is not overly loose so as to be still legible. I would have used space(s) between words in the example case, rather than averaging space between letters.
The above example looks like it was done in InDesign, using the default 1-2-1 proportional spacing of all ruby glyphs regardless of script, which ignores conflicting spacing settings from the mojikumi and the Latin justification dialogs for the paragraph (ruby is its own world, iow). The JLReq style can be achieved by choosing "centered" in the InDesign ruby settings. I could see a use case for "add spacing to spaces in ruby" as an option when the ruby is Roman...

[murata2makoto]

I'm forwarding Toshi-san's reply in Japanese.

　　　小林敏です

この問題は，単純にいえば，ルビの組版を行う場合，一般の本文の文字クラスと同じでよいか，別なのかということです．行中の文字を配置する場合に，配置する文字の文字クラスが決まっていれば，配置位置（それぞれの配置文字の字間と行の調整処理の際の振る舞い），および2行にする分割位置は決定できます．

これについては，以下のように考えることができます．まず，ルビについて，3つの場合が考えられます．

a）日本語で通常に使用している漢字の読み方，および外来語の言語を片仮名で示す場合
b）ルビにラテン文字を使用する場合
c）注釈的に説明のルビの機能を使用する場合

通常のルビルビは，aかbです．

1　aの場合に問題になる事項

aの場合は，文字又は語単位で分割禁止です．ですので，行の調整処理の際の振る舞い，および2行にする分割位置は問題になりません．この限りでは，文字クラスを考える必要はありません．ただし，aの場合は，約物をルビ文字として使用する場合があります．主に中点です．括弧はほとんど使用されませんが，可能性はあるでしょう．

この場合，字間の処理が問題となります．本文の約物の振る舞いと同じでよいかどうか，という問題です．中点については，平仮名と同じ振る舞いを期待しますので，本文とはやや異なります．括弧は，あまり考えたことはないが，たぶん，本文と同じでよいかなとも思いますが，まあ，適当でいいかな，といってもよいかもしれません（ほとんど使用例がないので考えてこなかった，必要ならその都度考えたでしょう）．

ただし，片仮名のルビでは，中点を使用する場合があり，この場合に字間を均等に空ける必要がでてきます．この場合，中点については，平仮名と同じ振る舞いを期待してよいか，括弧はどうするか，という問題は残ります．（この問題は，文字クラスで何も規定していないので，別個に考える必要ある．中点は片仮名と同じでよいが，括弧の字間を空ける問題は残る．JLReqでは例示のみ示している．）

2　bの場合

bの場合は，原則として，1字の文字又は単語全体のラテン文字の単語又はフレイズであり，これは，原則としてラテン文字の配置方法にしたがいます．

3　cの場合

最近はcのような使い方を見掛けます．この場合は，ルビというよりは注釈と考えた方がよいと思いますが，名前を別にして，その配置方法を考える必要があります．（cではないが，仮名のルビにアラビア数字や欧文混じりということも考えられますが，これらはルビの機能から予定していないことです．こうした例もcと考えてよいかと思います．）

JLReqでは，注も本文も，それにより文字クラスを変えることは考えていません．その意味では，cを注と考えれば，その場合の文字クラスは特別に考える必要はなく，JLReqで解説している文字クラスに従えばよいということになります．つまり，本文と同じということです．

ですので，上記に例示されている配置方法はJLReqの考え方とは異なります．単語の字間はベタ組，語間は，通常の語間となります．bの考え方からも上記に例示されている配置方法とはなりません．（もちろん，いろんな配置方法はありえますから，上記の図にある配置方法は，私はよいとは思いませんが，否定はできません．）

なお，他に何か，ご質問がありましたら，私でお答えできる範囲で
説明はさせていただきます．

[kidayasuo]

Does it need to be translated? It is long… :)

In short, Bin-sensei explained that the example shown in the image is not the style JLReq is recommending, and that however he does not think it is a good layout he would not dismiss it.