simple-ruby wide reviewへの対応

　shimonoです

　おもに敏先生へのご相談です。

　JL-TFのMLにも去年に流れていましたが、simple-rubyのFP-NOTEを出してコメントが
https://github.com/w3c/simple-ruby/issues/46 (discussion)
https://github.com/w3c/simple-ruby/issues/44 (editorial; RichardがPR #45でほぼ修正)
と来ております、というので、いまさらになってしまいましたが対応しようとしています。

　issue #44については残り項目として次の9項目（以下で参照用に番号を振っています）
----
1.
> modified in the light of any characters preceding and following
Light?

2.
> line edge
> line head or the line end
Be consistent with terminology

3.
> In some cases, this document suggests optional methods to be allowed as implementation defined, such as that a ruby annotation wider than its base text should not overhang any preceding or following kana characters.
Awkward wording

4.
> NOTE: Wrap opportunities
Seems like we need a whole section about how ruby interacts with justification. I don’t know why this is just a note.

5.
> points 1, 2, and 3 belong to the first step
The points are “considerations.” It’s not clear what “belong to” means here.

6.
> then the end of the ruby annotation is aligned with the line’s end edge
… assuming the text is justified

7.
> The spatial ratio of 1 unit before/after and 2 units between
This note doesn’t say anything distinct from content that comes right after it. No reason for the note to exist

8.
> base character string
Should use consistent terminology

9.
> points 1, 2, and 3 belong to the first step, and points 4 and 5 belong to the second.
This is true for all 3 forms, so there’s no need to call it out 3 different times. Also, better to use consistent formatting
----
 また、issue #46についてはissueに番号が振られている通り、10項目があります。

 これらについて、
A. 英語表現・翻訳の問題なので修正のPRを早急に出します : #44の上の1,2,8
B. 英語にしたときの表現の問題なので要検討ですが別途検討します : #44の上の5,9、#46の3
C. 文章構造について要検討 : #44の上の3,4,6,7と、#46の1,5,6,8,9,10
D. 図を追加していただければ助かる : #46の2,4
の4種類に大別されると思っています。
　以下、項目のIDとして、このA-Dの4つへの分類に入れたリストをA-cのようにインデックス付け、かつ
対応する指摘項目をA-#44-1のように(A-D)-(issue ID)-(項目ID)でつないで表現しています。少しやや
こしいですが、ご了承ください。



　というところで、CとDについて敏先生にご相談させていただければと思っております。（日本語版を
更新するかどうかは別として）なお、#44/#46で指摘があるinterlinear annotationとの分別について
は、simple-rubyでのissue
https://github.com/w3c/simple-ruby/issues/42

や、昨年ここで行われた議論のスレッドなどもありますが、ひとまず結論は出ていない、という認識で
（必要であれば）継続審議を行って文章を更新するという認識でおります。

　A/Bの項目については近いうちにPRを立てて修正案を出そうと思っていますが、一応A/Bについてもさ
らっとPRを出すときの方針をリストすると：
A-#44-1: 英語化の間違いなので英語を修正する
A-#44-2: "line head or the line end"の部分は"line edge"に統一する。line startとかも。ただし単独で出てくる部分はそのまま（Fig.22とか）
A-#44-8: "base character string"から"base text"にする
B-#44-5: stepは通常の仕様書では処理の流れを表現するのに利用されるので何か「英語での」表現を考える
   e.g. https://www.w3.org/TR/webxr/#select-an-immersive-xr-device

        https://html.spec.whatwg.org/multipage/webappapis.html#event-firing

B-#44-9: 平仄を合わせる方向で変更する
B-#46-3: 3.2にmono-rubyの親文字が1文字であるという文がないのですが、2.3には定義があるとはいえ、3.2にほぼ前文がないので少し短いmono-rubyのサマリーをいれる

　なお、A-#44-8については、ruby text、ruby annotation、base text、ruby baseなど、英語の文章
のなかで平仄が取れてないですので、そちらは別途issueを立てて議論しようと思っています。



 で、Cの分類についてのご相談ですが、、以下のように考えるところなのですが、いかがでしょうか？

C-a) C-#44-3
 "NOTE: Ruby annotations that are wider than the base text"にあるjlreqでの仮名に掛けたりする
処理のサンプル、つまり、JIS X 4051やJLReqでオプションとして提示されているさまざまな処理方法の
例を見ての指摘だと思うので、こんなのもあるんだという方向に行かないように、この際このブロック
全体削除はいかがでしょう？（3.2の4.で約物にかかる場合の例外処理は別途記載がありますが。。。）


C-b) C-#44-4
　"Note: Wrap opportunities in group-ruby"のgroup-rubyでの両端合わせや内側での改行の処理の件
で、もし分割することが可能であるならばjukugo-rubyのように分割して配置してもよいというような指
摘ですが、、グループルビは基本的にwrap opportunityはないと最初にあるので微妙なところです。。
　例外的な状況として、jukugo-rubyのような対応関係データがある場合であればgroup-rubyも改行可能
と入れるか？というのもあり得るかもしれませんが、論理構造上はさっくりと消した方が楽なのかもし
れないかな、とは思っています。
　あと、両端合わせの時にrubyがついたブロックの中をどうするか（親文字だけ考えて文字間あけてル
ビはそれに合わせる、か？）は追加必要かもですね。。


C-c) C-#44-6
　3.2の5.の最後の文についての指摘です。確かに行末に親文字からはみ出るルビが掛った文字が来る場
合、割付が発生しますよね（親文字の両端にルビの1/2の幅or親文字の1/4の幅のspacingが入るので、全
体として本文の流れに1/2文字分のspacingが入る）、というより、一般的に行中に来ていたとしても両側
のspacingが合わせて親文字の半分な場合、最終的に行末をどうにかする処理が必要と思われますが、言
及抜けてますでしょうか？
　もしくは、行長合わせでのjustifyについてはこのsimple-rubyでの規定によらず、一般的な日本語組版
や採用している組版規則に従う、というような一文を最初のどこかに前提として入れる？


C-d) C-#44-7
　3.3の一つ目の"Note: Inter-character spacing in group-ruby"の真ん中あたりの文についてです。
　いわゆる両サイド：文字間=1:2でspacingを入れるという話ですが、指摘の通りこのnoteを削除しても
処理内容としては後ろにある文章で説明されているので蛇足感はあります。日本語の文章では昔から良い
といわれて採用されていた方式であるというようなコメントである感が出ている（本文中でなく傍注だか
ら？？）ので蛇足感はそこまでないのですが。。
　英語版の構成を考えると、わたしは消してもいいとは思いますが、いかがでしょうか？


C-e) C-#46-1
　simple-rubyを作成するにあたった背景情報が明確でないという指摘だと思っています。
https://github.com/w3c/simple-ruby/issues/46#issuecomment-674031300

のコメントにもありますが、、手作業で微調整していた複雑なルールを自動処理するために例外を極力な
くして、とかいうのをもう少し追記できれば入れておいてもいいのかなと思うのですが、、いかがでしょ
うか？(この点については2.1の記述がそうだ、感はありつつも)


C-f) C-#46-5
 "Note: Ruby and interlinear notes"で行間注はこの文書の対象外という文章を入れてますが、ここを
「Japanese charactersやWestern characters以外の、約物を含むようなものも存在する行間注は」みたい
な感じでもう少し強く・明示的に表現するような文章は何か可能性はありませんでしょうか？
# Japanese/Western charactersはsimple-rubyでは3.3でcl-15,16,19やcl-24,25,26,27として定義しています。
# この文字の参照の部分、Digital-JLReqが出たら合わせて更新しないとではありますけれども。。

C-g) C-#46-6
 mono-rubyはgroup-rubyの特別な場合ではないのか？という指摘です。
　が、mono-とgroup-は似たようなもん（文字間spacingを除けば）だというのでそのままでいいと思って
います。前半の何が簡略化されたんだ？という点について、章立てに関するところですが、いまの2.のとこ
ろから2.2だけ抜いて、2.1/2.3で背景情報の章、2.2でsimple-rubyでの前提要件の章、にするのはいいのか
も、と少し思いました。2.2だけ取り出して章を立てた場合、中の3と5は処理方針、1,2,4は前提要件、と2つ
の節に分けてもいいかもです？が、ここら辺の再編、いかがでしょうか？


C-h) C-#46-8
 jukugo-rubyについて、長いブロックができたときにtwo stepといっているが、親文字を含む本文部分の
配置状況によっては、一旦戻って親文字を分割して、それぞれに対してtwo stepを再度やらないといけない
ことになるのでは？という指摘だと思います、、が、戻ったとしてもtwo stepをやることには変わりないの
で、2.2-3あたりにでも改行の制約で親文字が分割されるときには手戻りが入ることもある、とでも注釈（か
NOTE）を入れるとかはいかがでしょうか？


C-i) C-#46-9
 4.2のところで、mono-/group-/jukugo-の両側の組み合わせで分類して、4.3でgroup-については他で読み
替えできるという記述をしています。
https://github.com/w3c/simple-ruby/issues/46#issuecomment-674035714

にもコメントがありますが、、これ、いっそのこと4.2と4.3を一つの節にした方がはっきりします？かね？


C-j) C-#46-10
　4.1にあるNOTEですが、確かにこれはNOTE（日本語で傍注）でなくして（本文に突っ込んで）いいような
気はします、がいかがでしょうか？



　最後に、Dの項目についてのご相談ですが、、

D-a) D-#46-2
　ディッセンダーを持つような文字がルビに来た時にどうやって配置しているのか、というのがよくわ
かるサンプル（"p"が載ってる例が一つあるとは思うのですが、明確ではないので）を入れられればいい
かな、と思うのですが、何か出せますでしょうか。
　日本語フォントに入っている欧文文字の構成なのでルビ文字が欧文でも仮想ボディーの一番下が揃うの
だ、でもいいとは思うのですが、、多分次は欧文文字でなくarabicとかindicは？とかが来そうなので、
重ならないのだ！！みたいな一番ありがたいかもです。。


D-b) D-#46-4
　ルビに非常に長いものが来た時はどうなるんだ、という点です。
 fig.14で親文字が非常に長い場合の例はありますが、fig.15に同じようにルビが非常に長い場合の図
を追加いただけませんでしょうか？例えば、fig.15の二つ目を入れ替える形で。




　よろしくお願いいたします