- From: TAMURA, Kent <tkent@google.com>
- Date: Fri, 15 Mar 2024 11:55:36 +0900
- To: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Cc: 木田泰夫 <kida@mac.com>
- Message-ID: <CAGH7WqEZkVEHSZ-SMoBC49X2YigVdq0+vR0gRNM6ou6Vs+hD9w@mail.gmail.com>
みなさま、 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
Received on Friday, 15 March 2024 02:55:55 UTC