- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Wed, 27 Jul 2022 21:54:09 +0900
- To: 木田泰夫 <kida@mac.com>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>, 下農 <atsushi@w3.org>
- Message-ID: <CALvn5ECk0ddvUqLkjCO3rP5tBf=7qf0v2c3TL=XNN+qZdBqZ4w@mail.gmail.com>
2022年7月27日(水) 21:37 木田泰夫 <kida@mac.com>: > とすると、rb > の復活は、親文字がはっきりしないという理由に対しては、論拠が弱いように思えます。下の文章を読みましたが、説得力のある論拠は見つけられませんでした。どれもスクリーンリーダーのバグのように思えますが… > 一般論だと、木田さんのご意見の通りだと思います。 DAISY租界(DAISY教科書とDAISYリーダだけ考え、ルビには必ずrbが ある)で考えると別なんですけどね。 > ただ、rb は熟語ルビや、私のグループルビの提案には必要との理解をしています。 > これだけでrbの復活には十分ですね。 村田 > > 木田 > > 2022/07/27 21:21、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール: > > 2022年7月27日(水) 20:55 木田泰夫 <kida@mac.com>: > > > > rb の復活、今の文法では親文字列がはっきりしませんか? 熟語ルビを達成するためには必要ですが、それは別としてもこの必要性は成り立つ? > > スクリーンリーダなどで、親文字の判定はちゃんと出来てい > ないように聞いています。 > > 以下の文書は、JDCで議論して途中で放置してあるものです。 > 私も納得していない部分がいろいろありますが、参考に > なる部分もあるでしょう。 > > > https://github.com/Japan-Daisy-Consortium/documents/wiki/%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B7%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3%E3%81%AE%E8%A6%B3%E7%82%B9%E3%81%A7%E3%81%AErb%E3%82%BF%E3%82%B0%E3%81%AE%E5%BF%85%E8%A6%81%E6%80%A7%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 > > rbを信じて動作するのが支援技術としてはもっとも簡単です。 > 残念なことに、rbがないルビが普及してしまっているので、 > それらへの対処が必要なことは事実です。 > > 村田 真 > > > > 木田 > > > > > 2022/07/27 12:47、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール: > > > > > > 木田さん、 > > > > > > お返事が遅くなって申し訳ありません。 > > >> > > >> > > >> 追伸1: 現在 HTML で実装されていなくて、かつ村田さんたちが重要だと考えておられる機能、言い換えると W3C HTML WG > の重要な仕事はなんでしたっけ? > > > > > > まず、日本DAISYコンソーシアムで両側ルビが必要だという > > > 人はいません。教科書に両側ルビがないわけではないですが、 > > > 片方が読みで、もう片方は行間注などです。読みのほうだけ > > > ルビにして、もう片方はパーレンで処理しているようです。 > > > > > > HTMLの構造として、私が必要と思うものは二つです。 > > > > > > 1) rbの復活 > > > > > > ルビベースが何かをはっきりさせるためです。とくに、ルビベースの中に別のタグが > > > 入る場合です。スクリーンリーダなどの支援技術には、ベースが何かを知ることが > > > 大事なんですが、これを簡単にするためです。 > > > > > > 2) Multi-pair Word Ruby > > > > > > Fantasaiのいうところのmulti-pair word rubyです。次のようなものです。 > > > <ruby><rb>A</rb><rb>B</rb><rt>a</rt><rt>b</rt></ruby> > > > > > > HTMLのほうの構造を変えずに、スタイルの変更だけでグループルビと > > > 熟語ルビを使い分けるために必要だったと記憶しています。 > > > > > > https://fantasai.inkedblade.net/weblog/2011/ruby/ > > > > > > > > > 村田 真 > > >> > > >> > > >> 追伸2: > 構造というと、「両側ルビは別とすると」と逃げた問題にちゃんと正面から向き合う必要があります。私のラフな理解は:両側ルビは注釈。注釈とルビの根本的な違いは、ルビはどの位置にルビのどの文字がかかるかが重要で、そのための工夫がたくさんある。注釈は、単に単語だと読み手が認識するものに大体ついていれば > OK。なので、注釈は脚注にしても大丈夫。その理解で、両側ルビは脚注にしちゃえば?と思っています。ちょっとまだ議論が乱暴で調整が必要でしょうが。 > > >> > > >> > > >> 2022/07/20 14:18、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール: > > >> > > >> shimonoです > > >> > > >> On 2022/07/16 16:15, Yasuo Kida wrote: > > >> > > >> 村田さん、 > > >> ぜひ対象にしましょう。そのためにもうちょっとここで話をまとめる必要がありますね。 > > >> > > >> > > >> ちょっと違和感を感じているところなのですが、いまここで議論している大半のことはプレゼンテー > > >> ションの話であって、HTML WGでのRuby関係の話の本論であるはずのセマンティクス(というか機能付 > > >> けマークアップ?一緒か)のレイヤーではないという印象を持っています。 > > >> 木田さんがマークアップのサンプルを上げてらっしゃいました(rbでの順序対応関係が実装されてな > > >> い現状では動くようにするためには<rt></rt>で囲って最後でなくてそれぞれで入れるしかないですけ > > >> れど)が、あのようなグループルビなどの構造をどうやってマークアップに落とすか以上の話はほぼす > > >> べてCSSなんではないでしょうか、、、 > > >> > > >> > > >> # どのみち似たようなグループでの議論になるんだからとりあえずまとめちまえ、というのはちょっと > > >> 本件については乱暴すぎる気がします・・・ > > >> > > >> > > >> > 今のしているのは「グループルビが分割禁止になっているのは、行の大きな調整要素になるし、破綻の原因になるので、折り返しを許してはどうか」という話題です。 > > >> 折り返しを許す場合: > > >> ・違和感のある折り返しが起こる可能性がある。コントロールするためには、熟語ルビを使えば良いのでは > > >> ・折り返しのヒューリスティックについて説明する必要があるだろう。例えば折り返した先にルビが一文字もないのは困る > > >> そんな議論です。 > > >> > > >> > > >> ということで、ここら辺(↑)でなく、 > > >> > > >> > > >> > グループルビは、必ずしもグループルビという用語を理解してもらう必要はないのかなと思っています。ルビの単位が一文字より大きければそれはグループルビなんですから。用語を増やすとそれだけ複雑に見えますので、両方まとめて「ルビ」で良いと私は思います。 > > >> 熟語ルビは、熟語ルビと説明するよりも、ルビをグルーピングする機能が欲しい。と言った方が分かりやすいかも。 > > >> > > >> > > >> こういう議論なのかな、と。。 > > >> もちろん、ルビ文字をどうやって配置していくか(親文字との配置上の対応)と、改行どうするんだ > > >> 話の決着次第で、必要とされる構造やマークアップも多少変わるのかもしれませんけれど。。 > > >> > > >> > > >> > 例えば、京都(きょうと):「京」の読みが「きょう」で、「都」の読みが「と」。独立の二個のルビにすると「京」に対して三文字のルビが対応するので親文字の字間を開ける処理が必要になってしまう。ので「京都」ひとまとまりに対して「きょうと」のルビを振りたい。が、これを折り返す場合は、「京(きょう)都(と)」となってほしい。「京(きょ)都(うと)」になってしまうのは漢字の読みから言って正しくないので避けたい。 > > >> ルビの折り返しを許すと、いわゆる熟語ルビ(既に利用方法は異なりますが)の重要性が高くなるように思います。 > > >> > > >> > > > > > > > > > -- > > > Regards, > > > Makoto > > > > -- > Regards, > Makoto > >
Received on Wednesday, 27 July 2022 12:55:01 UTC