RE: 行長は全角の整数倍であらねばならないか

木田さん

こんにちは。コメントいただきありがとうございます。

  *   印刷を再現できるかどうかは jlreq-d において完全に考慮外です。それを前提として考えると、画面上で読むときに全角の1/39の均等なアキの有無は私は無視できる問題のように思えます。短い行になるとこれが全角の1/9になったりします。実際に読むときに気になったり障害になったりするかどうかはわかりませんが、このくらい大きくなると気がつくと思います。もしアキが大きな問題なら、禁則、ルビ、英数字などのプロポーショナル要素によって行の調整が頻繁に入るような場合はどうなんでしょう? アキを統一したければ、両端揃えよりも行頭揃えの方が良いわけで、まさにこの理由でアクセシビリティ対応の欧文は行頭揃えを選択できる必要があります。
行長を整数倍にする根拠は、視覚的に時間調整のアキが気になるかならないか、ということにあるのでも、印刷用に組んだものを正確に再現することにあるのでもないと考えます。ご指摘のように、欧文が挿入されると字間調整は不可避ですし、禁則処理が行われた場合も、字間調整が発生する可能性は、行長を文字サイズの整数倍にしたとしても常に存在しています。しかし、それは当然のこととして理解しつつ、それでも行長を整数倍にすることには根拠があります。

欧文の場合は、プロポーショナルでワードスペースがあります。そのため、十分な行長が与えられて、無理なく破綻なく組まれた場合には、ジャスティファイした場合でも、ワードスペースは当然、行ごとにバラつきが生じますが、字間には通常ほとんど影響がありません。ワードスペースを調整しただけでは、可能な改行位置で改行できない場合、つまりジャスティフィケーションが破綻した場合に、やむを得ず、字間を広げることになるだけです。つまり、欧文では、例外的な場合を除けば、ジャスティファイした場合でも、書体デザイナーが設定した字幅とサイドベアリングは正確に再現されるのです。このことは、その組版結果が紙の上に印刷されるか、画面上に表示されるかどうかとは、無関係に、あてはまる事実です。もちろん、グラフィックデザイナーがレタースペース(字間スペース)やワードスペースを、個別の組版の事例を最適化する目的で調整する場合はあります。パラグラフ全体を少し緩く組むとか、タイトに組むとか、個別の文字の間をマニュアルで詰めるとか。しかしこれらの追加の調整は、すべて、もともとのその書体デザインがもつ字幅とサイドベアリングが、どのようなものであるかを、認識した上で、さらなる視覚的改善策として行われます。もし、使用している書体デザインが本来、どの程度の字間スペースで(つまり、どれくらいの詰まり/空き加減で)で組まれるのか、見えるのか、ということが認識できなければ、改善することも不可能となります。改善すべきかどうかを判断することすらできなくなります。

それだけではありません。書体デザインが、外部から追加で字間の調整を何もしない状態で、本来どのような詰まり/空き具合で見え、その書体で組んだ場合に版面がどのような濃度に見えるのかということが、認識できる手段がなければ、そもそも複数の書体デザインを比較して、ある最適と考えられる書体デザインを選択することも難しくなるでしょう。

日本語書体の大多数は全角ボディの中でデザインされています。そしてそれは、日本語組版における全角ボディを基準とした行の位置決めと、全角の整数倍を行長に設定してジャスティファイするという基本的な組み方と原理的に連関しているのです。どちらか一方を破綻させると(あるいはそれから逸脱すると)、他方も破綻(逸脱)してしまいます。実際、数は少ないですがプロポーショナルでデザインされた日本語フォントを使う場合には、全角ベースの組み方や指定の仕方は無意味になります。それを反対方向から見れば、全角ボディとその整数倍の行長指定という原則を無視した組み方をすると、日本語の書体デザインも破綻してしまうことになるのです。

  *   もちろん、整数倍かどうかは全域にわたるアキのデフォルト状態を決め、行の調整はそこからばらけるという問題なので、同じには扱えませんが、全域にわたって同じように空く方が、ばらけるよりはまだ問題は小さいのではと想像します。ばらけるのは両端揃えを選択したら不可避です。つまり整数倍かどうかは、その不可避の問題よりは小さな問題である、と。どうでしょう?
ジャスティファイしても一切ばらけないのが常態であって、禁則処理であれ欧文の挿入であれ、それは必ずしもすべての行で常に発生するわけではない例外処理だと思います。

  *   整数倍にする意味がないと言いたいわけではないんですよ。整数倍がどのように有用なのかを理解するために、整数倍じゃなくてもいいんじゃない? という思考実験に皆様を誘っているんです。
私は常に整数倍で行長を指定すべきだ、と主張しているのではありません。全角ボディを基本にしたフォントを組む場合には、行長は整数倍で指定するのが基本だ、と言っているだけで、整数倍で指定しないオプションがあっても当然良いと考えています。ジャスティフィケーションについても同じです。Webの場合にはジャスティファイしない方が効率的な場合があるのは理解できます。ラギッドでも組めるようにするべきだと思います。しかし、日本語はジャスティファイするのが基本だという原則は変わりません。

  *   jlreq-d が言うべき一番重要なことは、整数倍にすべき or しなくても良い、ということではなくて、コストをかけて整数倍にするための機能を実装する利点はコレコレですよ、という情報を提供する事です。そのときに、印刷ではそうされてきた/その方が好ましいと思う、と書くのは悪いわけではありませんが画面で読むためのテキスト表示をどうするかの判断のために良い情報になりません。
上で述べましたが、印刷か画面かは、ここでの議論とは無関係です。もっと原理的な課題なのです。なぜ、原理的なことを考える以前に、「コストをかけて整数倍にするための機能を実装する利点」ということを議論しなければならないのかが、私には理解できません。日本語組版の基本的な必須の要件をはじめからスキップすることはできません。他方で、「コストがかからないようにするために、整数倍にするための機能を常に実装しなくても良い」かどうかを議論することの必要性を否定しているのではありません。それはそれで重要なことだと思います。ただ、物事の順序を飛ばすことはできないと考えるのです。

このことは、欧文に話を置き換えると分かりやすいと思います。もし欧文でジャスティファイする場合に、十分な行長とワードスペースの数が与えられている場合でも、ワードスペースだけでなく字間スペースも調整の対象として「全域にわたって同じように空く」ようにしてしまった場合を想像すると、それが書体デザインの本来の姿を分からなくしてしまうことが理解できるのではないでしょうか。例えば、全角の1/39ほど字間スペースに割り振られると下のURLの画像の二番目(下の)印字見本のように欧文の本来の字送りが分からなくなってしまいます。

https://flic.kr/p/2oZ5AW3


下のURLは和文で同じ程度に字間が空くとどうなるかを示す印字見本です。
https://flic.kr/p/2oZ4ARj


  *   また、実装者に対してガイダンスを提供したいので、そこに我々の判断が入って、整数倍にできることのプライオリティはこのくらい、と書くでしょう。今までに私が得られた知識によると、プライオリティの高い機能でないように思えます。しかし、各自の判断ができるよう情報を提供するのが一番重要なところだと思います。
もちろん、ジャスティファイしない場合には、つまり行頭揃え、行末成り行きで組む場合には、プライオリティは低くなります。しかし、ジャスティファイする場合にはプライオリティは高いと思います。だからといって、繰り返しますが、常に行長を文字サイズの整数倍で組まなければ絶対にならない、とは考えていません。

同じことがジャスティファイするかどうかについても言えます。ジャスティファイしない方が良い場合はあるでしょう。ただし、ジャスティファイしない場合には、ほとんどの日本語フォントが普通はプロポーショナルではないこと、ほとんどどこでも行分割可能なこと、などの理由で、行末がほとんどの場合揃ってしまうか、微妙にしかギザギザ(ragged)にならない、そのために、その行末の微妙な不揃いが不具合と誤認されたり、美観を損ねるリスクがあることは認識しておく必要があるでしょう。

日本語の本文をデザイン上の効果から、ジャスティファイせずにラギッドで組む場合は、通常はデザイナーと編集者又は原作者又はコピーライターが共同であるいは協議して、デザイン上の効果と恣意的に改行した場合に文章の意味が誤解されるリスクとを評価した上で、文章のどの位置で改行すべきかについてあらかじめ合意した上で、あるいは原作者や編集者がデザイナーが作成した校正刷りを確認してOKを出してから行うのが、トラブルを避ける方法だと考えられています。もちろんデザイナー自身にすべての裁量権がある場合には(デザイナー自身が書いた原稿だったりした場合などは)、デザイナーだけで決定できますが。

  *   ところで、本文ではなくてタイトルの場合はずっと短いので影響は大きくなりますが、この場合には両端揃えにはならないですかね?
見出しもいろいろな場合があるでしょうが、普通は複数行にわたる場合でも本文の行末までは届かせないので、ジャスティファイしないと思います。

山本太郎

Received on Thursday, 31 August 2023 06:48:15 UTC