- From: 木田泰夫 <kida@mac.com>
- Date: Fri, 17 Apr 2020 15:19:51 +0900
- To: Kobayashi Toshi <binn@k.email.ne.jp>
- Cc: "public-i18n-japanese@w3.org" <public-i18n-japanese@w3.org>
- Message-Id: <9016347F-F599-4D73-A504-F0C123A5D589@mac.com>
敏先生、 とっても分かりやすくなりました。ありがとうございます! > ルビ処理の矛盾例 これ、とても良い情報だと思います。「1 簡便な配置ルールで考慮した事項」かそのほかの適切な場所に入れるのはいかがでしょうか? 両側ルビは19:35のメールにご返答します。 > 著者名の表示 了解です。 Florian さん、関連して、この日本語オリジナルの扱いはどうなりますか? github でも議論がありましたね。 木田 > 2020/04/16 16:51、Kobayashi Toshi <binn@k.email.ne.jp>のメール: > > 木田泰夫 様 > > 小林敏です > > 丁寧に読んでいただき,ありがとうございます. > > 冒頭の文章を以下のように修正したらどうでしょうか. > > 0 この文書の目的 > > この文書では,CSS,SVG及びXSL-FOなどの技術で実現が求めら > れる日本語組版のルビ処理について,実装する際の参考となる簡便 > な処理方法を示した.簡便なルビ処理方法を実現するために,ここ > では,JLReqとは異なり,何を選べばよいか,何が重要であるかを > 考慮し,配置方法を一つに絞ることにした(どのような事項を考慮 > したかは次項で解説する).あわせて,JLReqで解説していない両 > 側ルビの配置方法を追記した. > JLReqでは,過去に行われていた処理例を紹介する意味もあり,一 > つのことに複数の処理方法や,かなり複雑な処理方法を示してい > る.なかでも,ルビ処理では,さまざまなケースが出現し,また, > ある要求事項を組版で実現しようとすると矛盾が出てしまう例もあ > る.こうした事項まで考慮して自動処理を行うためには,かなり複 > 雑な方法となる. > そこで,理想ではないが,誤読されないということを考慮し,例外 > のあまりでない,また,機械的に処理できる簡便な配置処理方針を > 考える必要があるように思われる.以下は,こうした簡便な配置処 > 理方法の一案である. > > 注 > > ルビ処理の矛盾例 例えば,できるだけ字間を空けないということ > から,親文字からはみ出したルビを漢字には掛けないが,仮名には > 掛ける,とした場合,親文字の前が漢字で,後ろが仮名といったと > きに,ルビ文字の字数によっては見た目のバランスを壊す場合も出 > てくる.こうした場合,活字組版では個別箇所のケースに応じて配 > 置位置を工夫していた. > > 両側ルビの行間は,以下の注記をつけるということで,どうでしょ > うか. > > 両側ルビと行間 慮側にルビを付けた行が重なると,行間の設定に > よっては,隣り同士の行のルビが重なるケースが出る.これは避け > ないといけない.以下のような方法が考えられる. > (1)あらかじめ隣り同士のルビ文字が重ならないように,文書全体の行間を設定しておく. > (2)重なりが発生した該当する行間だけを広げて,ルビが重ならないようにする.この場合,重なった前の行のルビと,後ろのルビが重ならないだけでなく,例えば,その間は本文文字サイズの四分は空けるとする方法も行われていた. > (3)重なりが発生した行間だけではなく,該当する段落全体の行間を広げて,ルビが重ならないようにする. > なお,活字組版では,ルビが多く付く,あるいはルビと共に注の合 > 印などが多く入る場合は(1)の方法,ルビが少ない場合は(2)の > 方法がとられていた. > > 著者名の表示 > > 著者名は,フローリアンさんの翻訳したW3Cの形式にならった文書 > では,以下の記載があります. > > Editor: > Florian Rivoal (Invited Expert) > Author: > Toshi Kobayashi > > この扱いは,私は特に希望はありませんので,適当に処理していただければ結構です. > > 以上です. > > 木田泰夫 さん wrote > >> 敏先生、ありがとうございます。 >> >> この文章の目的が先頭に来ることで、意図が明確になったと思います。 >> >> 何点か質問です: >> >> a) 「0 この文書の目的」部分 >> >>> この文書では,CSS,SVG及びXSL-FOなどの技術で実現が求められる日本語組版の簡便なルビ処理方法について,実装する際の参考となる処理方法を示した.あわせて,JLReqで解説していない両側ルビの配置方法を追記した. >>> ここでは,JLReqとは異なり,次項で説明する事項を考慮し,配置方法を一つに絞ることにより,何を選べばよいか,何が重要であるかについても示している. >> >> ここの「も」ですが、「簡便なルビ処理方法」に加え、「配置方法を一つに絞ることにより,何を選べばよいか,何が重要であるか」も、示しているという意味になりますか? この二つは並立というより、片方が片方の手段、つまり一つに絞ることが簡便さを実現するための手段の一部だとの理解をしていたので、そうすると「も」の意味はどうなるのだろう、と。 > > 表現していることの内容として,簡便だというだけでなく,それは > “何を選べばよいか,何が重要であるか”を考慮した方法が選ばれて > いるわけだから,何が重要かということの表現でもあるよ,という > 意味で,“も”にしたものです. > > しかし,疑問がでることはよくありませんので,最初に示したよう > に,はっきり書くようにいたします. > >>> JLReqでは,過去に行われていた処理例を紹介する意味もあり,一つのことに複数の処理方法や,かなり複雑な処理方法を示している.なかでも,ルビ処理は,さまざまなケースが出現し(活字組版では個別箇所のケースに応じて配置位置を工夫していたので,実現できた),これを自動処理で行うためには,かなり複雑な方法となる. >>> しかし,ある程度理想的な配置処理を考えたとしても,ルビ処理では,どうしても例外事項が発生する,あるいは,それぞれの要求事項を組版で実現しようとすると矛盾が出てしまう事項もある. >> >> ここの「理想的な」は、理想的に素晴らしいルビの配置を達成しようとすると例外事項が発生する、という意味ではなくて、理想的なケース、理想的な対象文章だとしても例外的事項が発生する、という意味ですか? >> >> この下に出てくる「理想」は「理想的に素晴らしいルビの配置」だと思いますが、それと同じ解釈をするとどうも通じないので、この二つの理想は違う意味で使われているのかな、と。 >> >>> こうした事情を考慮すると,理想ではないが,誤読されないということを考慮し,例外のあまりでない,また,機械的に処理できる簡便な配置処理方針を考える必要があるように思われる.以下は,こうした簡便な配置処理方法の一案である. >>> なお,ここでの用語は,JLReq(日本語組版処理の要件,Requirements for Japanese TextLayout)による. > > 上記のように直したらどうでしょうか > >> b) 特に両側ルビの配置方法に関連して、行間について触れておく必要性はあるでしょうか? 両側ルビの難しさの一つは行間をどうするか、かと理解しています。両側ルビがぶつかったところだけを広げるのか、両側ルビが出現するなら全体を広げておくのか、など。 > > 注を追加 > >> c) 著者名は書かない? >> >> 木田 > > ————————————————————— > 小林 敏(toshi) 2020年 4月16日 > e-mail: binn@k.email.ne.jp > ————————————————————— >
Received on Friday, 17 April 2020 06:20:09 UTC