Re: ルビの折り返しの挙動

Google 田村です。
みなさま、フィードバックありがとうございます。

みなさまの意見と社内での議論から、以下のような方針にする予定です。

* できるだけルビの折り返しは行わないよう、親文字が短いルビ内では折り返ししないという経験則をブラウザに組み込む。
  * 熟語ルビの分割が好ましくない。
  * ウェブブラウザというソフトウェアの特性上、できるだけ現在と挙動を変えない方が好ましい。
  * 青空文庫のテキストを調査したところ、親文字4文字以内で全ルビの 99.4%
を占めました。最初は4文字以内は折り返しできないようにして、それが厳しすぎるようなら2文字に緩和するかもしれません。
* ルビの入れ子には対応しない


補足:
* 折り返しの処理においては「ruby-base と ruby-text
のペア」を単位として考えます。「<ruby>師<rt>し</rt>匠<rt>しょう</ruby> 」は「
<ruby>師<rt>し</ruby><ruby>匠<rt>しょう</ruby>」と同じ扱いになります。
*
ルビの分割で親文字がなくルビテキストのみになるケースや、ルビテキストがなく親文字だけになるケースはできるだけ避けるようにします。しかし、どうしても避けられないケースはあります。例えば
[1] は親文字が154文字、ルビテキストが3文字の<ruby>があります。これが4行以上に分割されるとどうしてもルビテキストがない親文字が出てきます。

[1] https://www.aozora.gr.jp/cards/001930/files/58400_69157.html




On Fri, Mar 15, 2024 at 11:55 AM TAMURA, Kent <tkent@google.com> wrote:

> みなさま、
>
> Google 田村です。
> Google Chrome でルビ内の折り返しができるプロトタイプを作成し、基本的な動作が問題ないことを確認しました。
> 現状の css-ruby / HTML
> スペックから逸脱せずにルビの折り返しを出荷しようと考えていますが、以下の点についてフィードバックをいただきたいと思います。
>
> * 短いルビの中では折り返したくないという要求
>   A) ブラウザ側でルビが短いかどうか判断して折り返し可否を決める
>   B) ブラウザ側で判断せず、ページ著者が折り返したくないルビに  white-space:nowrap を付ける
>   C) ブラウザ側で判断せず、ページ著者が折り返したいルビに  white-space:normal を付ける
>
> Bでも許容できるでしょうか。
> どうしてもAが必要という場合、「親文字とルビテキストの均等割付け前の幅がともに行全体の幅の 1/10
> 以下なら折り返し不可」という基準はいかがでしょうか。
>
> * <ruby> の入れ子
>   <ruby>が入れ子になっている状態で内側の <ruby>
> 内での折り返しをサポートするのは難しく、費用対効果が低いと考えています。入れ子の場合、内側の <ruby>
> はすべて折り返し不可としても実用上問題ないでしょうか。
> Google Chrome と Safari は <rtc> をサポートしてないため、一つの親文字に複数のルビテキストを付けるには <ruby>
> を入れ子にする必要があります。複数ルビと折り返しの同時サポートが必要かどうか知りたいと思います。
>
>
> 挙動やアルゴリズムの詳細は以下のドキュメントに記述してあります。
>
> https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?usp=sharing

>
>
>
> On Sun, Sep 17, 2023 at 12:54 PM 木田泰夫 <kida@mac.com> wrote:
>
>> JLReq TF の皆様 + Google 田村さん、
>>
>> ルビの折り返しに必要な計算をどのように減らすことができるのか、6月の Nat さんとのミーティングに引き続いて、9/15に Google
>> 石井さん、田村さん（ルビのコードを書いたその人）とミーティングを行いました。
>>
>> *結論*
>> ・ありがたいことに、2024年の計画において来年早々ルビの折り返しの実験をしてくださるとのこと。JLReq TF
>> はその評価などで最大限の協力を行う。二種類のフィードバックが欲しいとのこと。一つは組版仕様の問題（e.g, 敏先生）、もう一つは Computer
>> Science 的な考慮（e.g. Nat）
>> ・田村さん、Kent Tamura <tkent@google.com> さんが JLReq TF に加わってくださる🎉
>>
>> *議論のかい摘み*
>> ・オーバーハングが難しいと言うより、ルビが長い場合に難しくなるのではないか？
>> ・オーバーハングは周りの文字の条件を決めずに1/3というやり方もある。と敏先生に教えてもらった
>> ・折り返す場合はいろいろな妥協、サボりをしてかまわない
>> ・分割後のルビや親文字の禁則やリガチャの影響がややこしく影響しそう。ルビの方が長いと考えて処理を始めたら、これらの影響で親文字の方が長くなったり。
>> ・rt が一つなら比較的単純？ → rt があったらそれぞれ独立の ruby として考えれば？
>> ・折り返す場合の多くは行間注的なもの、すなわち範囲の後ろがいい加減になって良いものではないか？（そうでもない）
>> ・絵文字のように、ルビを世界中で流行せられないかな
>> ・結局アルゴリズムの設計をしてみないとわからないことが多い。フローチャートか、コードで示す。
>>
>> *参考：Nat さんとのミーティングの結果の recap*
>>
>> ルビのオーバーハングを無効にすることで計算が簡略化できる。無効にすることの悪影響を軽減するため、ルビが折りたたまれる場合にのみオーバーハングを無効にする、オーバーハングを行うことの価値が大きいく、折り返すメリットが少ない短いルビは折り返しを行わない、などが考えられる。jlreq-d
>> には簡略化する方法と同時に、より洗練された方法についても記述してほしい。
>>
>> 木田
>>
>>
>
> --
> TAMURA, Kent
> Software Engineer, Google
>
>
>

-- 
TAMURA, Kent
Software Engineer, Google