- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Wed, 19 Apr 2023 15:57:02 +0900
- To: Kobayashi Toshi <binn@k.email.ne.jp>
- Cc: atsuda@fontworks.co.jp, tyamamot@adobe.com, kida@mac.com, public-i18n-japanese@w3.org
- Message-ID: <CALvn5EBSCNJnqEACUyCgwrxPjXLKaF9Jfv9g5J9PxUAyq26a3A@mail.gmail.com>
> > これに対し,日本語組版では,単語(または文節)単位で読んでいくとしても,基本は個々の漢字・仮名を1字1字読んでいきます. これは疑問です。 読むことはフィックセーションとサッカードの 連続であることはよく知られており、読みが上達 するとまとまり読みをします。つまり、フィク セーションのなかで視線を動かさずにまとめて読みます。 視線を動かさずに一字一字読んでいくということは まったくないとは言えませんが、フィクセーションの 両端では解像度も落ちているはずです。両端でも中央 でも同じように一字一字読むことは物理的に不可能 でしょう。 村田 真 > > ですので,ラテン文字組版ほど,字間の均一さを問題としないように思います.例えば,“口”という漢字は,リュウミンに比べ,イワタ明朝や精興社明朝は,かなり小さい字面です(“中公新書”は,よくイワタ明朝を使用しています).つまり,“口”という漢字の前後は,かなり空いていますが,それほど気になりません.ある意味,字間が空いているので,“口”という漢字だということがよく認識されるということかもしれません.(もちろん,字間が乱れることは,あまり好ましいことではないでしょう.) > > > *ただし,デザイナーの中には,紙面や画面で,あるテキストのまとまり(つまりグレースペース)の濃度を気にする方もおられます.この場合は,字間をかなり気にするでしょう.(私は,紙面全体の印象では差はあるが,読みやすさにはそれほど関係しないのではと考えています.) > > > 次に,日本語組版での望ましい字間ということですが,これについては読書の習慣によって,変わってくるのでと思っています.つまり,現実に行われている,多くの組版で採用されている組版に読者は慣れており,それが,一般的にいえば望ましいものと考えられます. > > > ずっと以前ですが,五号四分アキという組版が多く行われていた時代があります.これが読みやすいといわれて,多くの書籍で採用されていたのです.ですけれでも,講談社の“現代新書”では,最近でも字間を空けた(アキ組)の本を見かけます.五号四分アキが読みやすいのなら,これも読みやすいと考えられますが,私にとっては,あまり読みやすいようには感じられません.これは,読書の慣れによるものと考えられます. > > > ところで,詰め処理では,1箇所で四分とか二分のアキ量を詰める処理を行うのですが,これに対し,アキ処理では,25字程度でも,全部の字間を処理しますので,各字間を空ける量は,わずかなので,日本語組版のある種の字間のルーズさを考えれば,あまり気にならないと思うのです.40字程度であれば,2倍の調整量でも,なんとか許容範囲かなと思います.組版を見慣れた目からいえば,40字で2倍の調整量の場合,ちょっと気になりますが,一般の方は,指摘しないとわからないのではないかな. > > > いずれにしても,読みやすさを考える場合,実際に読みやすさを考えながら,それを意識して,実際に読んでみる,そこでの経験というもの,それを積み重ねていくということも大切かなと思っています.(そして,その際に,現在読んでいる本の組版の情報(詳細はわからないことも多いが)も参照しながら評価していくという作業も必要かなと思っています.) > > 以上,ご参考まで. > > atsuda@fontworks.co.jp さんwrote > > >横からすみません。 > >話がずれているようでしたら、申し訳ございません。 > >ソフトウェアを書く立場からの話になります。 > >小林様のお考えのAの場合、改行位置を仮決めした段階で行末あるいは次の行頭に禁 > >則文字が来る場合は、追い込むか、追い出すかの選択をしないといけないのですが、 > >この規則は必要ないのでしょうか。 > >また、追い込む場合には、句読点、括弧類の詰めを最初に考えるのですが、こちらの > >ルールも決める必要があったりしますでしょうか。 > -- Regards, Makoto
Received on Wednesday, 19 April 2023 06:57:47 UTC