- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Sat, 16 Mar 2024 16:08:15 +0900
- To: "TAMURA, Kent" <tkent@google.com>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Cc: 木田泰夫 <kida@mac.com>
"TAMURA, Kent" 様 小林 敏 です. 内容を十分に理解したとは,とてもいえませんが,ルビ分割の周辺の事情を含め,気づいた事項をコメントいたします. 1 ルビの分割は,行頭・行末そろえ(ジャスティファイ)の場合に主に問題になる.この場合,分割できないルビ文字列を一体として次行に送るので,行長をそろえるために,字間が極端に空いてしまう場合があり,これは望ましくない. 2 したがって,ルビの分割ができなくても,行頭そろえの場合は,問題は,1よりは少ない. 3 ところで,Webでは多くが行頭そろえが現状であるが,なかには行頭・行末そろえにしたものも見掛ける.さすがに,そうすると整った印象を与えるので,今後はWebでも,行頭・行末そろえは選択される可能性は増えると思われる.その意味では,ルビの分割を行う意味は,大いにあると,私は考えている. 4 また,最近は,漢字の読みを示すルビよりは,ある言葉を別の言語で示す(主に片仮名を使用する)例が多くなっているように思います.このようなルビでは,親文字列の字数がけっこう多くなる例が,よく見掛ける.いくつか例を示す. 同業組合 ルビ:ギルド 針葉樹林帯 ルビ:タイガ 読み書き能力 ルビ:リテラシー 集会のための広場 ルビ:アゴラ 私は何を知っているのか ルビ:クセジユ 5 この場合は,つまり行頭・行末そろえで,次行に送られて字間があいて,見た目の印象を悪くするが,どこまでが許容範囲かが,まず問題になる.以下は,私が紙の本で見ていて感じることですが,1行が40字前後として,2字分を分割すると,少し空いているなと感じる(一般の人では,許容できる範囲とも思われる).これが3字となると,たぶん,一般の人でも,何か字間が普通でないと感じるかもしれない.20字くらいになると,2字分を字間で調整すると普通でないと感じるかもしれない. 6 次に,分割の可否は,自動か,指定させるか,分割不可(または分割可)を指定させるか,という問題です. 7 分割の可否が指定できることは一般に望ましいといえよう.ただ,これまでの活版時代からの経過を見ると,4に例があるものは,活版時代は多くは分割していた例が多い.コンピュータ組版になり処理上の問題から分割禁止となり,それはやむを得ないことだとして受け入れてきた.私の見るところ,4の例は,意味上から分割してはならないと考えたのではなく,処理上からできないということで受け入れられてきたように思われる.ですので,コンピュータ組版では,無理をして(印刷所に対し無理をいって)分割した例は,現在でも,けっこう見掛ける.いってみれば出版社が主張するかどうかという差なんでしょう.ですので,現状からいえば,すべて分割してよいともいえないので,そういう意味で分割の可否が指定できることは望ましいということです.つまり,分割で語句が割れることと,字間の乱れることと,どちらを優先するかは考え方如何ということですので,指定できた方がよいということです. 8 次に分割位置の指定ですが,これが難しい.以下のような例を見ると, 例 基本計画 ルビ:マスタープラン “基本”ルビ:マスター と “計画” ルビ:プラン のように分けたいと思うのは当然のことですし,こうした複合語の例も,それなりにある.しかし,紙のように決まってしまう場合と異なり,Webでは行長も変わる場合もありえるので,どのようになるか分からないし,変わる可能性もある.となると,指定位置での分割は,必ずしもよい結果にならないかもしれない.ですので,この方法は望ましいように思うが,私は少し懐疑的である.現状の紙の本の例でも,この望ましい分割位置で分割しない例もよく見掛ける.(データを作成する人がそこまで指定の作業をするのかな,という疑いもある.) 6 最後に自動の場合,どのような状況で分割させるかという問題です.Aの行長の1/10というのは,微妙で,もうすこし厳しくしてもよいようにも思います.もっと簡単にいえば,調整量が親文字サイズの2字分を超えたら,親文字列を分割すると単純化することも考えられる.先ほどの“同業組合”でいえば,行末に“同業”が入るときは,分割しないで送り出しても,字間の調整量は2字分なので分割しないが,行末に“同業組”となる場合(この場合の調整量は3字分)は,分割すると考えてもよい. 7 そして,親文字の分割と連動させる,ルビ文字列をどう分割するかという問題ですが,一般的にいえば,親文字の分割したそれぞれの文字列の比率に応じて,ルビ文字列を分解させればいいのですが,それではうまくいかない場合があることを考えておく必要もあります. 例:ユダヤ教の宗教的指導者 ルビ:ラビ この場合,比例計算をどうするかによりますが,四捨五入の計算を行うと,当該の行と,次の行のいずれかに,ルビが1字も残らないということが起こる可能性がある.かならずというか,最低は,当該の行と,次の行にはルビ文字は1字は残すという条件を付ける必要がある. 8 さらに,例は少ないのですが,ルビは1字という例もある.これは,すべて分割禁止という扱いにしてもよい.少々,見た目には悪いが,誤解を与えないという点では,やむをえないと思われる.親文字が2字の例は,それなりにあるが,親文字が3字以上は少ないでしょうが,以下のようにないわけではない. 例 あなた ルビ:ヴ 9 補足ですが,4に掲げたルビは,JLReqではグループルビとよび,親文字列とルビ文字列は,短い方の字間を1:2:1の比率で字間を空ける処理をすることになっているが,親文字列を分割した場合は,この比率計算は再計算する必要があります.(この字間の空け方は他にも方法はあるが,私は,原則として1:2:1の比率だけの配置方法でいいと思っている.) 10 最近は,行間注(行間に配置する注記)をルビ処理で行う例があります.私は,この行間注的なルビは,いわゆるルビ処理とは別なもので,行間注的なルビは,親文字もルビ文字列も,本文同様に(分割可能位置であれば)どこでも2行にわたる分割は行ってよいものと考えた方がよい(比例計算も不要で,その行に入るだけ配置すればよい)し,該当しない親文字に行間注的なルビは,どれだけでも掛かってよい,と思っています. 以上,ご参考まで "TAMURA, Kent" さん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_CaU40zV5bXbMQjY2SHQHj3Np4s >Do/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 >> には簡略化する方法と同時に、より洗練された方法についても記述してほしい。 >> >> 木田
Received on Saturday, 16 March 2024 07:12:47 UTC