Re: 両側ルビのときの行間

みなさま、
小林龍生です。

いい議論ですね。
というか、今まで、こういうedge caseをどう電子化するか、についてのきちんとした議論が欠けていたような。
というか、電子書籍が技術的にも市場的にも、ある程度成熟してきた今だからこそ、こういった議論の必要性が浮かび上がってきたのでしょうね。

その際、
リフローを前提として流し込み組版で処理るコンテンツと、固定レイアウトを前提として例外的処理を含む個別処理で処理するコンテンツの弁別、
原典資料の視覚表現をそのまま温存するコンテンツと、一旦視覚表現の背後にある意味的情報に基づいた構造化を経由したうえで、構造情報の最視覚化を目指すコンテンツの弁別、
といった判断が重要になってくると思います。この判断こそは、編集者／編者のお仕事ですね。ま、電子化仕様書の明文化というか。
JWTが発信すべきメッセージが、（ぼくなりに）明確になりました。

電子化の際には、どのような情報を温存したいかを明確に意識した上で、cost
efficiencyを念頭において、曖昧性のない電子化仕様書を作りましょうね、ということでしょうか。

2020年1月24日(金) 1:19 Nat McCully <nmccully@adobe.com>:

>
> 行間をとにかく保つという概念はWebにまだない浅いと思います。本文ではないカテゴリーのテキストを行間に入れること、ぶつからないように配置、本文のベースラインをグリッドらきしものに吸着、などは想像します。JLReqの次期バージョンではこの日本独特なhierarchyのことを説明したら本文の行間の重要性は明確になるかと思います。考えてみたいです。
>
> ナット
>
> On 1/23/20, 12:15 AM, "Kobayashi Toshi" <binn@k.email.ne.jp> wrote:
>
>     村田様
>     木田様
>     みなさま
>
>    小林敏です
>
>     行中に，その段落で規定したサイズより大きな文字等が入る（例え
>     ば水平線を用いた分数（やぐら組といいます））が入る，あるい
>     は，行間にいろんなものが付く，その際にどうするか．
>
>     1 原則として，1つの文章の中では，決まったテキスト（本文なら
>
> 本文，注なら注）では，同一のサイズで，同一の行間で統一する（行送りを統一する）．異なった行間になると，それは本文とは何か別の何かと思われる恐れがあり，決まったスタイルで配置しないと誤解を与える恐れがあるからです．この考えで，基本的にこれまでの多くの書籍は組版されてきました．
>
>     2 一般の本では，以下のような行間処理が問題となるようなケー
>     スはほとんどは発生しないので（両側ルビは使用されたとしても，ごくごく一部），問題になるケースは，ほとんどなかった．
>
>     3 しかし，一部の書籍では，村田さんが問題にするような例はあ
>     った．例えば，古典の注釈書などです（行間に複数のいろんな要素
>     が配置されています）．その時は，原稿で各種の実例を考慮し，問
>     題のないよいに配置方法を考えながら，問題のない行間を検討しま
>     す．（そうした苦労は武川武雄著“日本古典文学の出版に関する覚
>     書”（日本エディタースクール出版部，1993年）に説明がありま
>     す）．
>
>     4 また，横組で行中で，やぐら組の分数をどうしても使用したい
>     場合も問題になります．
>
>     5 その対応として，3つの方法が考えられます．そうした問題箇所
>     がどの程度発生するかで，対応は異なってくるかと思います．
>     a 問題は，多くの箇所で発生する．この場合，全体を考慮し，問
>     題のでない行間にする．
>     b 多くは，基本とする行間で問題ないが，一部に問題がでる．
>     b.1 行間に配置するもの，あるいは行からはみ出すものが重なら
>     ないように，問題の出る段落全体の行ではなく，該当する行の行間
>     だけを広げる．この場合は，はみ出したものが接するのは許容する
>     か，あるいは，その間を，例えば，本文使用文字の四分を最低空け
>     るかするか，つまり，重なるものの最低のアキ量を決めて処理す
>     る．（こうした実例は実際にもあります．）
>     b.2 考え方は，b.1と同じであるが，該当する行間だけを空けるの
>     ではなく，該当する段落全体の行間をあける．
>
>     ＊私の考えでは，誤解を与えないために行間を一定にするという考
>     え方からは，b.2よりb.1が好ましいと思っています．該当する行が
>     空いていても，読者はその理由は，比較的に簡単に理解できます．
>     段落全体とすると，なぜ行間が広いか，一瞬に判断できない場合も
>     ありえるからです．
>
>     ＊しかし，行間，あるいは行送りなどの属性が，段落単位でしか設
>     定できないDTPもありました．この場合はb.1は実現できません（In
>     Designでは，行送りなどの属性は文字単位なのでb.1は可能，その
>     行にある文字の最大の値を適用する）．
>
>     ＊以上のように考えられますが，もっと原則的なことをいえば，最
>     初から，そうした問題の出ない原稿や組版方法を考えることが必要
>     ではないかな．行間に配置するルビ，圏点や傍線（つまり強調），
>     注番号や注そのもの等は，強調の方法を含めて，いろんな方法があ
>     り，工夫すれば，行間を変えるケースはでないように思います
>
>     以上です．
>
>     木田さんの，“これはあり”について．
>
>     これに似たケースとして割注にルビを付けるケースがあります（印
>     刷した本で実例を見ました）．
>
>     活字組版では，ルビ文字は，4ポが最低の文字サイズでした（それ
>     以下は読みにくいので，使わない，必要ないという考え方です）．
>     ただし，本文7ポに二分のルビを付けたいということで，ほんの一
>     部の印刷所で3.5ポのルビ活字が作られました．この経緯は前述の
>     武川さんの本に説明があります．なお，7ポという活字も，どの印
>     刷所にも常備されていたわけではありませんでした．
>
>     つまり，小さい文字には，ルビは付けない，ルビでなく，別の方法
>     で対処するということが考えられていたのです．
>
>     ですから，技術的な可能だからといって何でもやっていいというこ
>     とにはならないように思いますが，どうでしょうか．
>
>     木田泰夫 さん wrote
>
>     > これは自動化を想定していない機能・規則の良い例の一つですね。
>     >
>     > 日本語組版の要件的にどうかは敏先生にお願いして、私はちょっと脱線：
>     >
>     > 送っていただいたリンクの例 <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.co.jp%2Fgp%2Ffeature.html%3Fie%3DUTF8%26docId%3D1000173306&amp;data=02%7C01%7Cnmccully%40adobe.com%7C9551f025da9f4170b27208d79fdc5e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637153641133781189&amp;sdata=ftmeonwgSCw6hMXYSlQSejDlziAPHY3hPCVI7emrPbg%3D&amp;reserved=0

> >はカオスですね。語の意味をルビの方法を使って通常のルビのように右側に示しているのですが、当然意味の説明は語よりもずっと長くなるので、対象となる語の範囲を示すために傍線が引いてあります。本来のルビも通常は右側につけてあります。
>     >
>     >
> しかし意味の説明が付けてある語に本来のルビを付けたい場合や、他の語の意味の説明がルビを付けたい語まで伸びてきてしまっている場合には、ルビを左側に逃しています①②。左側に逃げることができない場合、ルビを意味の説明と同じ右側に戻し、両者を続けて示しています③。つまり本来のルビは右に行ったり左に行ったり。左側は統一的な意味で使われているわけではなく、避難場所のようです。
>     >
>     > また、最後の③の例では、ルビの方法で表示されている意味の説明にさらにルビがついていますが、これはあり？
>     > 木田
>     >
>     > > 2020/01/22 20:14、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール:
>     > >
>     > > 皆さん、
>     > >
>     > > 両側ルビのときの行間について質問します。
>     > >
>     > > JLREQでは両側ルビのことはあまり書いてありませんが、
>     > > JISX4051:2004 日本語文書の組版方法には詳しい規定が
>     > > あります。しかし、 JIS X4051 でも行間のことは書かれてい
>     > > ません。
>     > >
>     > > 両側ルビを使うとなると、上（右）側ルビと下（左）側
>     > > ルビが一つの行に現れるという事態が考えられます。そういう
>     > > 最悪の事態を避けるよう、いままでは編集者や印刷会社
>     > > が手をかけていたのだと私は理解しています。以下の例
>     > > も、そう見えます。
>     > >
>     > >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.co.jp%2Fgp%2Ffeature.html%3Fie%3DUTF8%26docId%3D1000173306&amp;data=02%7C01%7Cnmccully%40adobe.com%7C9551f025da9f4170b27208d79fdc5e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637153641133781189&amp;sdata=ftmeonwgSCw6hMXYSlQSejDlziAPHY3hPCVI7emrPbg%3D&amp;reserved=0

> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.co.jp%2Fgp%2Ffeature.html%3Fie%3DUTF8%26docId%3D1000173306&amp;data=02%7C01%7Cnmccully%40adobe.com%7C9551f025da9f4170b27208d79fdc5e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637153641133781189&amp;sdata=ftmeonwgSCw6hMXYSlQSejDlziAPHY3hPCVI7emrPbg%3D&amp;reserved=0>
>
>     > >
>     > > しかし、リフロー環境ではこんなことは出来ません。両側ルビ
>     > > を使えば、行間に二つのルビを入れるという事態は当然の
>     > > ように起こります。
>     > >
>     > > Firefoxの実装では、両側ルビが入ると行間が思いっきり
>     > > 開きます。上 （右）側ルビの領域と下（左）側 ルビの領域
>     > > をあらかじめ確保しているようです。 そうすれば、
>     > > ふたつのルビが衝突することはありません。
>     > >
>     > > さて、これは日本語組版の要件から見てどうでしょう？
>     > >
>     > > <image.png>
>     > >
>     > > 慶應義塾大学
>     > > 村田 真
>
>     ―――――――――――――――――――――
>    小林 敏（toshi） 2020年 1月23日
>    e-mail: binn@k.email.ne.jp
>     ―――――――――――――――――――――
>
>
>

-- 
KOBAYASHI Tatsuo（小林龍生）
Scholex Co., Ltd. Yokohama
homepage) http://kobysh.com/ <http://www.kobysh.com/tlk/>