長いグループルビの改行 (was Re: 両側ルビをどうするか

長いルビの改行は難しいですね。

日本語ではあまり発生しませんが、改行位置によって長さが変わる場合があるので、現代の改行アルゴリズムは、予測⇛改行してみる⇛入らなければ再試行、というステップを繰り返すことになります。英語でも、空白文字を含んだ合字があったりすると、この手順が必要になります。サンプルは、
こちらのサイト <https://www.sansbullshitsans.com/>
で提示されている例文を入力してテキストボックスをリサイズすると再現できます。NG以前のBlinkではうまく処理できませんでしたが、今は正常に動作していると思います。

それを、2つの独立した行を同期して改行計算するように、となると...遅いアルゴリズムなら考えられそうですが、ブラウザで採用できるような速度で計算可能か、というと、疑問がつきます。最近私の周りでは、
バランス改行 <https://github.com/nytimes/text-balancer>
（各行の長さを揃える）が話題になっていますが、これもかなり厳しいです。

それに加え、長いルビの改行は、必要な場面が限られ、回避策を許容できるという人もいる、という、ニーズ側からの課題もありますね。

紙書籍のトラディションを残すJLREQでは難しいでしょうが、JLREQ-Dではデジタルでの表現を考え、期待値そのものを変えてしまう、例えばBlink/WebKitの現状を許容する、というのはありですか？
最初は驚かれるでしょうが、見てみると、親文字の終わりがわからない、という難点はあるにしても、実はこっちのほうが読みやすくないか、とも思えます。


On Wed, Sep 28, 2022 at 7:44 AM Yasuo Kida <kida@mac.com> wrote:

> 石井さん、
>
> ありがとうございます。W3CとWHATWG
> ではポリシーが180度違うのですね。長短ありそうですね。またインラインの件はそのようなバックグラウンドがあるのですね。難しく絡まっていますね…
>
>
> ただ、実務上から考えると、別スレッドで議論中の「長いグループルビ」の問題が少し絡んでいます。Natが指摘しているように、長いグループルビを適切に改行するのは、アルゴリズムの複雑さからも実行速度の面からも問題が大きい。
>
>
> 気になっているのはこれです。Nat
> さんにも解説してもらいましたが、問題のありかをまだちゃんと理解できていないんですよ。このままではルビを折り返し可能にしても絵に描いた餅になってしまいます。石井さんから見た、長いグループルビを適切に改行することの問題点を教えていただけるならとても助かります。そして、組版規則の方を変更することでそれを改善できるでしょうか？
>
> 木田
>
> 2022/09/23 17:31、Koji Ishii <kojii@chromium.org>のメール:
>
> 木田さん
>
>>
>> まず、ルビにかかわらずすべての仕様の一般論として、要望があって仕様化可能なものは全て仕様に入れてあるので、各機能の重要性は実装者が判断してほしい、と仕様編者から聞いています。
>>
>>
>> それって、複数のブラウザが実装しないと規格にならないという規則との折り合いはどうなるんでしょう？
>> 実装されたものだけを抽出して正式な規格にするんでしょうかね？
>>
>
> 私の理解では、W3CとWHATWGではポリシーが異なるようです。WHATWGは実装者の合意や予定、意思がないと仕様に入れませんが、W3Cが複数の実装を求めるのはPR/RECのみです。ED/WD/CRでは、実装の存在、予定、意思がなくても入れられるようです。Writing
> Modesでは、PR/RECに移行する際に実装者の合意がないものを削る、という作業をしました。とはいえ、CSSでも、Chrome以外に実装者がいないという理由でEDに入られないケースもあったので、W3C側の運用は柔軟なんだろうと理解しています。
>
>
>> Chrome/Safariは、WebKit実装当時のW3Cでの議論に基づき、ブロック扱い（DIVやPと同様）になっていますが、Firefoxはインライン扱い（SPANと同様）になっているようです。
>>
>>
>> 本来から言えばインライン要素であるべきですよね、きっと。
>>
>
>
> ルビ本来の用途を感覚的に理解すると、おっしゃる通りインラインだと思います。ただ、実務上から考えると、別スレッドで議論中の「長いグループルビ」の問題が少し絡んでいます。Natが指摘しているように、長いグループルビを適切に改行するのは、アルゴリズムの複雑さからも実行速度の面からも問題が大きい。とはいえ、改行できずにオーバーフローしてしまうと、電子書籍などでは画面外になってしまい、見切れてしまいます。これはコンテンツが見切れて読めないため、出版社から「致命的」「不可」レベルの問題であるとして指摘されています。このため、出版社と相談の上で、Blink/WebKitでは、ルビ内の改行をサポートしています。
> サンプルはこちら
> <https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22width%3A%2010em%3B%20border%3A%201px%20solid%20blue%22%3E%0A%20%20%3Cruby%3E%0A%20%20%20%20%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E9%95%B7%E3%81%84%E6%96%87%0A%20%20%20%20%3Crt%3E%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E9%95%B7%E3%81%84%E3%83%AB%E3%83%93%3C%2Frt%3E%0A%20%20%3C%2Fruby%3E%0A%3Cdiv%3E>
> 。紙の印刷の既成概念からすればあり得ない組版だとは思うんですが、出版社からは、これなら「可」であると聞きました。これを実現するには、ブロックでないと技術的に難しい。実装当初はどちらでも大差ないと思われていましたが、現在では、ブロックの方がこういった柔軟性が高いと思っています。
>
>
> また、HTML/CSSでは、インラインの要素は、すべて本文の流れ（フロー）に含まれると解釈されています。絶対座標指定やフロートなどの別のフローを作り出す要素はすべてブロック要素です。検索や読み上げなどで、本文の流れ（フロー）に含みたくないことを考えると、ブロックの方が相性が良いのでは、と思うこともあります。
>
>
> もちろん、インラインであることによるメリットもあるのかもしれません。個人的にどちらであるべきかの強い意見を持っているわけではありませんが、こういった議論やメリット・デメリットの検証がないまま、歴史的経緯によって実装が分かれてしまったのが残念ですね。
>
>
>