- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Sun, 17 Jul 2022 09:37:08 +0900
- To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>, Yasuo Kida <kida@mac.com>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
MURATA Makoto 様 Yasuo Kida 様 みなさま 小林 敏 です. グループルビの分割を可能にするために熟語ルビにすれば解決するか? 細かく見れば解決しません.グループルビと熟語ルビは,その性格が基本的に異なります.しかし,複数の熟語にルビを配置するという点で,熟語ルビにグループルビ的方法で配置処理するのは,ある意味で便法ですが,便法は採用できるという道もあるいうことです. グループルビ:複数の親文字にルビを対応させる.この配置方法は複数ある.複数の親文字は一体としたいが,その語構成では分割も考えられるので,その場合は分割してよい. 熟語ルビ:原則として,親文字は複数であるが,親文字の1字ごとにルビを対応させる.これが原則で,この原則はできるだけ維持したい.したがって,親文字1字ごとに分割は可.しかし,1字の親文字に親文字サイズを超えるルビ文字列が付くケースがある.これをどうするかが問題で,方法は複数ある.もっとも簡単なのがグループルビに倣った処理またはモノルビの処理,もっとも複雑なのが,JLReqの附属書の“F 熟語ルビの配置方法”の方法.その中間的な処理もあり,処理法はかなり複雑である.この複雑な処理を様々に工夫していた. ですので,熟語ルビの複雑な処理ができないケースが多いので,ケースにより,または考え方により,熟語ルビをモノルビで処理する,またはグループルビで処理するという現実はある.ただし,ルビを配置だけではなく,読み上げなど別の目的に処理する場合は,モノルビでは問題がでる可能性もある. だからといって,熟語ルビをグループルビですべて処理するということは,現状では,問題が出るか,その主な問題は(簡便なルビ処理での範囲ではということ),1字の親文字に対応したルビ文字列の長さが,それぞれ親文字サイズ以下であり,その中に一部の親文字に対応したルビが1字の場合です.こうしたケースでもグループルビで処理したケースはありますが,多くはモノルビ的な処理です. 例:杞憂;きゆう 進化論;しんかろん ですので,これを無視すれば(つまり簡便なルビ処理をさらに簡便にすればということ),熟語ルビは,すべてグループルビでよくなり,熟語ルビとグループルビは合体し,グループルビに分割可能な方法を取り入れるという方法は考えられないわけではありませんが,…… ですので,熟語ルビの複雑な処理が困難であるということで先送りするか,その処理が難しいので,簡便化をいっそう進めて取り込みやすくするか,ということです. 熟語ルビの先送りまたは無視は,ある意味でやむをえないことであるが,熟語ルビという考え方は,なんらかの形で残しておく必要はあるように思います. MURATA Makoto さんwrote >この件については、これから始めるHTML WGでやる >ルビの対象にしますか?それとも諦めますか? > >今回諦めるとおそらく未来永劫にわたって実装はされ >ないでしょう。現状のルビから一ミリも変える必要は >ないという意見を持っている人も多いのです。彼らを >説得することは、とても大変そうです。今回の変更の >後でまた変更することはまあ不可能でしょう。 > >なお、グループルビと熟語ルビとは、国際の場ではほとんど >理解されていないようです。WHATWGのHTML仕様のエディタ >も分かっていないらしいです。私も、読んだときは理解した >ような気になっていますが、実はよく分かりません。 > >今回の話も、グループルビを使わずに熟語ルビを >使えば解決する話ですか? > >村田 真 > > > >2022年7月15日(金) 14:42 Yasuo Kida <kida@mac.com>: >> >> >> > 熟語ルビをすこし拡大すれば,つまり親文字1字とルビとを対応させるのではなく, >> > 複数の親文字とルビを対応させる組合せもできれば,それでいいのですが,… >> >> これ、今の仕組みで可能だとの理解ですが、マークアップに詳しい方、どうでしょ >> う。実装はまだですかね? >> <ruby>紫陽花<rb>寺<rt>あじさい<rt>でら</ruby> みたいな > > >> グループルビを折り返し可能にするとして、他の極端な、書籍だと校正の段階で除 >> 外されるので考慮する必要のなかったような例: >> ・モノルビで、ルビがとてもとても長いもの。ルビだけ折り返すのはあり? >> ・熟語ルビで、熟語の単位が長い。例えば上の「紫陽花」は三文字でまあまあ長い >> がもっと長くなりうる。熟語ルビが長ーい場合、熟語の途中で折り返すのはあり? >> >> > ルビの字数の少ない場合に問題が出る可能性がある.ちょっと悩ましい. >> >> 折り返す場合の文字数の分割の仕方の考え方を示してしておいたほうが良いかもし >> れませんね。特にルビの字数が少ない場合、折り返した親文字に対応するルビ文字 >> がゼロ、と言うケースが出てくる可能性がありそうです。<ruby>ソフトウェアの間 >> 違い<rt>バグ</ruby> みたいな極端なケースも考えておく必要がありますね。 >> >> 木田 >> >> > 2022/07/13 16:12、Kobayashi Toshi <binn@k.email.ne.jp>のメール: >> > >> > 木田泰夫 様 >> > >> > 小林 敏 です. >> > >> > 熟語ルビをすこし拡大すれば,つまり親文字1字とルビとを対応させるのではなく, >> > 複数の親文字とルビを対応させる組合せもできれば,それでいいのですが,…, >> > ルビの字数の少ない場合に問題が出る可能性がある.ちょっと悩ましい.この問 >> > 題は,熟語ルビは,分割しない場合,ルビの字数の少ないときでも,すべてグ >> > ループルビで処理すると考えれば解決する.まあ,それでも解決の一歩と考えれ >> > ば,それでもいいと思っています. >> > >> > 木田泰夫 さんwrote >> > >> >> 敏先生、 >> >> >> >> グループルビには熟語ルビと異なり分割の基準となるような位置の指定がありま >> >> せん。 >> >> 印刷の場合には人間が判断できますが、デジタルではそうもゆきません。ゆえ、 >> >> 分割 >> >> を許すと言うのは、通常に分割できる場所ならどこでも、という意味になります。 >> >> そ >> >> れが嫌なら熟語ルビを使えと。その意味で熟語ルビはまさにデジタルにふさわし >> >> いか >> >> もしれません。 >> >> >> >> 例えば:「基本計画(マスタープラン)」が「基(マス)」「本計画(タープラ >> >> ン)」となったり、「基本計(マスタープラ)(3文字に対して6文字のルビ)」 >> >> 「画 >> >> (ン)」。これを許容する。嫌なら熟語ルビを使うように。 >> >> >> >> ルビが親文字の2倍より多い場合:「顧客(クライアント)」→「顧(クラ >> >> イ)」「客 >> >> (アント)」。だいたい親文字分割の割合でルビを分割するのがいいでしょうか >> >> ね。 >> >> ルビが親文字の2倍よりも短い場合:「紫陽花(あじさい)」は「紫(あじ)」 >> >> or >> >> 「陽花(さい)」か「紫(あ)」「陽花(じさい)」。「紫陽(あじさ)」「花 >> >> (い)」。親文字とルビの分割の方法のバランスをどう取るかは工夫の余地があ >> >> りそ >> >> う。 >> >> >> >> こういうのを、違和感があるけれど、許容してしまう。これが最もシンプルバー >> >> ジョ >> >> ン。 >> >> >> >> もっとやれるアプリケーションは、形態素解析を使ったり、グループルビの分割 >> >> はど >> >> うしても困った時にしかやらないプライオリティにするとか。 >> >> >> >> コンテントを作る側は、手間をかけられるなら、田嶋さんが説明してくださった >> >> よう >> >> に、熟語ルビとして切り目を示す。 >> >> >> >> 木田 >> >> >> >>> 2022/07/13 13:51、田嶋淳 <junetaj@gmail.com>のメール: >> >>> >> >>> 敏先生 >> >>> 木田さま >> >>> >> >>> 現状電子書籍の制作では、長すぎるグループルビを意図的に分割して付与す >> >>>る >> >>> ケースはあります。紙の本と違って後からの組版調整ができないため、グルー >> >>> プル >> >>> ビによって前後の組版が大きく乱れることを阻止するための今現在のやむを得 >> >>> ない >> >>> 回避措置です。 >> >>> >> >>>> 2022/07/13 13:29、Kobayashi Toshi <binn@k.email.ne.jp>のメール: >> >>>> >> >>>> Yasuo Kida 様 >> >>>> >> >>>> 小林 敏 です. >> >>>> >> >>>> グループルビを分割可能にする処理は,熟語ルビの分割処理に似ていますが, >> >>>> すこ >> >>>> し違う点もあります.熟語ルビでは,親文字の分割は1字単位で可能ですが, >> >>>> グ >> >>>> ループルビでは1字単位でない場合がある.それは,親文字のどのようにくく >> >>>> るか >> >>>> で差はつけられる. >> >>>> >> >>>> 文そのものにルビを付ける場合,グループルビを分割可能しても解決しない. >> >>>> 文そ >> >>>> のものにルビを付ける場合,分割位置は,漢字や仮名の字間は,どこでも分割 >> >>>> 可能 >> >>>> になる可能性が高い.それに対し,グループルビでも熟語ルビでも,特にルビ >> >>>> 文字 >> >>>> 列では仮名の字間で分割不可になる例は多い. >> >>>> >> >>>> 熟語ルビの例 親文字:可能性 ルビ:かのうせい >> >>>> 親文字はどこでも分割化,ルビは“の”と“う”,“せ”と“い”の字間は >> >>>>分割 >> >>>> 不可 >> >>>> >> >>>> グループルビの例 >> >>>> 親文字:基本計画 ルビ:マスタープラン >> >>>> 分割するとすれば,基本+マスター 計画+プラン >> >>>> 親文字:都市国家 ルビ:シテは,まあ分割しない方がいいかもしれないが, >> >>>> 分割するとすれば,都市+シ 国家+テ >> >>>> としてもよい.これに近い分割をしている例は見かける. >> >>>> >> >>>> Yasuo Kida さんwrote >> >>>> >> >>>>> 敏先生、 >> >>>>> >> >>>>> jlreq-d ではグループルビを分割可能にしましょう。 >> >>>>> >> >>>>>> グループルビ以外に,文そのものにルビで別のテキストを付ける例があるが, >> >>>>>> こ >> >>>>>> れ >> >>>>>> は,そもそもルビで処理するには無理がある.行間注で処理した方がよいし, >> >>>>>> 行 >> >>>>>> 間 >> >>>>>> 注を考えるとしたら,それは分割禁止にはならないでしょう. >> >>>>> >> >>>>> この用法の「ルビで処理するには無理がある」のは、グループルビを分割可 >> >>>>> 能に >> >>>>> した >> >>>>> 場合、解決しますか? >> >>>>> >> >>>>> 木田 >> >>>>> >> >>>>>> 2022/07/13 12:15、Kobayashi Toshi <binn@k.email.ne.jp>のメール: >> >>>>>> >> >>>>>> Yasuo Kida 様 >> >>>>>> みなさま >> >>>>>> >> >>>>>> 小林 敏 です. >> >>>>>> >> >>>>>> Yasuo Kida さんwrote >> >>>>>> >> >>>>>>> (別の問題ですが:長いルビが折り返せないのは、行頭揃えにしてもかな >> >>>>>>> り目 >> >>>>>>> 立つ >> >>>>>>> 行 >> >>>>>>> を作ってしまいますので、それ自体で問題だと思っています) >> >>>>>> >> >>>>>> 長いルビは,多くがグループルビです.このグループルビが2行に分割禁止 >> >>>>>> なの >> >>>>>> は, >> >>>>>> 組版プログラムが簡単な処理法を選んだためです.活字組版時代は,その場 >> >>>>>> で工 >> >>>>>> 夫 >> >>>>>> できたので,必ずしも分割禁止ではなかった.実際にも編集者の立場でいえ >> >>>>>> ば, >> >>>>>> 分 >> >>>>>> 割してもよいのです(グループルビの分割位置には,いくつか望ましい事項 >> >>>>>> があ >> >>>>>> り >> >>>>>> ますが).現在でも,たぶん手作業なのでしょうが分割した例はあります. >> >>>>>> >> >>>>>> グループルビ以外に,文そのものにルビで別のテキストを付ける例があるが, >> >>>>>> こ >> >>>>>> れ >> >>>>>> は,そもそもルビで処理するには無理がある.行間注で処理した方がよいし, >> >>>>>> 行 >> >>>>>> 間 >> >>>>>> 注を考えるとしたら,それは分割禁止にはならないでしょう. >> >>>> >> >>> >> > >> > ―――――――――――――――――― >> > 小林 敏(toshi) 2022年07月13日 >> > e-mail: binn@k.email.ne.jp >> > ―――――――――――――――――― >> > > >-- >Regards, >Makoto
Received on Sunday, 17 July 2022 00:41:24 UTC