JIS X 4051からJLREQへ

小林 敏 氏

私はJIS X 4051のエディターを務めていた。また、2012年４月3日にJLREQ「日本語組版処理の要件」ということで、W3Cの技術ノートに当たるものが公開された。東京電機大学出版局から単行本でも出ている。

JIS X 4051とJLREQ

JIS X 4051というのは、基本的には書籍の組版について、処理しなければいけない内容についてまとめたものである。日本語文書の組版について、行の組版方法、版面、ページの組版方法について、どういったことが問題となり、その問題についてどのように処理するのがいいのかを規定したJIS規格である。

このJIS規格は、主として日本語ワープロやDTPソフトに参照されている。例えば、MS-Wordなどでもずいぶん参照されていて、アラビア数字と和文の間の空きなども特別な処理をしている。

Edicolorの話でも、標準が25％で、12.5％が詰まって、空けて50％という話があったが、実際の現場ではそういう値を取っていることはほとんどない。基本的には四分固定というのが我々の常識である。なぜそんなことが行われているかというと、実はJIS X 4051に書いてあるからである。

ワープロのMS-WordもJIS X 4051を参照しているので、こういうふうに空いてしまう。それを私は非常に嫌いなので、特別に四分スペースをここにほうり込んで、強制的に全部四分になるようにしている。それがEdicolorだと、数値をちょっと操作するだけで簡単に設定できるということになっている。

そういった意味では、JIS X 4051というのはいろいろなアプリケーションから参照されていると考えていただければいいだろう。

4051については、いろいろなところから関心を持たれており、最近では電子書籍でも問題になっているが、電子書籍の1つの規格であるEPUBは、W3CのCSSを参照して組版処理するという関係になっている。

CSSの組版処理を考えるときに、日本語組版処理について十分に対応していないという問題があった。日本語組版処理を反映させなければいけないと、ずいぶん前から問題になっていた。そのためにはどうすればいいか。単純に言うと、JIS X 4051を英文にしてしまえばいいが、なかなかそれは大変である。しかも、JIS X 4051を単純に英訳しただけでは、おそらく読んでも理解できないだろう。

実は、私は第3次規格のエディターで、かなりの部分を書いたが、書いた本人が後で読み返して、何を言っているのか分らないこともある。単純に英訳しただけでは理解できないだろうということで、新たに日本語を私が全部執筆し直し、それを英訳してもらったものがJLREQである。したがって、X 4051がベースにはなっているが、いくつか4051と違う点もある。

一番大きな違いは、図解を多くして、日本語が分らない人にも分ってもらおうと努力したことである。初心者にも分りやすいドキュメントになったのではないかと思う。特に新しく組版を勉強しようという人は、Webで見てもらってもいいし、この本を購入していただければありがたい。

いずれにしても、その2つに関わってきた関係から、特に日本語組版の問題について話したい。
今日はあまり時間がないので、DTPあるいはCSSその他、これから多分問題になるであろうことについて4点、字詰め方向の文字配置と文字クラス、それからルビ、特に熟語ルビについて、それから行送り方向の行アキの調整、図と表の配置という4点についてお話ししたい。

字詰め方向の文字配置と文字クラス

JIS X 4051では文字クラスごとに文字を配置するルールを規定している。現在のDTPソフトでは字詰め方向のルールについては、ほぼ問題は解決している。

字詰め方向と行送り方向を説明すると、字詰め方向とは文字が並んでいく方向であり、行送り方向というのは行が並んでいく方向である。

字詰め方向えは、まず字間をどうするかということがある。Aという文字とBという文字が並んだときの字間をどうするか。それからAという文字とBという文字が並んだとき、つまり1つの段落の中で2行に分割していいかどうかという問題。それから3番目に難しいのは、日本語というのは、全部全角が並んでいけばいいが、いくつか二分のものとか、あるいはアラビア数字の前後は四分空けるといった形で、必ず全角ではないものが入ってくる。

日本語の文書というのは、段落の最終行を除いて1行目から最終行の直前の行までは行長を揃える。英文の場合はラグ組といって両端をがたがたにするということがあるが、日本語の場合は単語で分割するわけではないので、行末をラグ組にすると、本当に入ったり出たりという微妙な差しかない。

英文の場合には明らかに出たり入ったりがはっきりするのでラグ組の意味があるが、日本語の場合には基本的にはジャスティファイ、つまり全部行長を揃えるということになるので、行の調整処理、行を揃えるという処理が必要になってくる。

行の調整処理というのは、特に初心者にとっては非常にわかりにくい事項である。JLREQでも、「行の調整処理」という形で、初心者にわかりやすい説明がある。JLREQは、日本語が分らない人および初心者
のためのドキュメントである。

字詰め方向の配置は、要するに文字や記号をその振る舞いで文字クラスとして分けている。当然、漢字と平仮名とは振る舞いが違う。例えばルビがはみ出したときに漢字にはかかってはいけないが、平仮名にはかかっていいというように、振る舞いが違う。そうすると漢字と平仮名は別の文字クラス、別のグループとして扱ったほうがいいだろうとなる。

そのように、文字の振る舞い、つまり組版処理上の違いを分類して1つのまとまりを作る、それを文字クラスと呼んでいる。組版処理上の文字クラスというのは、配置するときの違いというものに従って分類しようということである。

JIS X 4051の文字クラスは23に分かれているが、Edicolorは21になっており、若干違いがある。
例えば「始め括弧類」というのは1つのグループ。「句点類」とは少し扱いを変えている。「平仮名」も扱いを変えている。和字というのは、簡単に言うと漢字とカタカナのことである。

規格書の中ではどうなるかというと、要するに前にどんな文字クラスが来るか、後ろにどんな文字クラスが来るか、それと、その2つが並んだ時どうするか。例えば「始め括弧類」と「後ろ括弧類」。それと、もう1つその後ろに「始め括弧類」が来たときにどうするか。ここは「カギ括弧」が来る。そうするとそこはベタである。白はベタである。その次に「終わり括弧類」が来るとどうするか。「始め括弧類」と「終わり括弧類」が並ぶということは普通はないが、この場合はベタである。

それから、「中点類」。例えば中点が来て、それから「始め括弧類」が来たときどうするか。この場合にはここの「中点類」を二分というふうに考えるから、ここは四分である。四分で、またここに「終わり括弧類」が来るから、ちょうどカギとカギの間に中黒が来るとちょうど中黒が全角どりになるという形で、要するに文字クラスで分けて並んだときどうするかという形の、こういう二次元の表を作ることによって、すべての文字の間隔が定義できるということである。

その定義したことを、先ほどのEdicolorの数値にいろいろ当てはめていくと、要するにDTPが自動処理できるという関係になってくる。いずれにしても、そういう形で調整ができる。

文字クラスについては、ここに書いたようにJIS X 4051の文字クラスがある。それから、JLREQではJIS X 4051の文字クラスを基本的には踏襲しているが、一部改良している。それは、例えばカタカナを漢字のグループから分離したとか、少し改良している。

これで文字間のアキ量が決まる。同じように分割についても、分割していいかどうかを二次元の表で表現している。それから、行の調整処理についても同じように、AとBの文字が並んだときにその字間をどこまで空けていい、どこまで詰めていいか。Edicolorの話で言うと最小値と最大値という値に当たる。
この行の調整処理というのが、実は組版の品質を決める決定的なことである。その行の調整処理のいかんによって組版の品質が変わってくる。JIS X 4051の調整処理はちょっと気に食わない点があったので、JLREQでは、詰める箇所については表を3つ作っている。X 4051の場合と、X 4051を少し改良した場合、それから私の理想とするパターンの3パターンを、JLREQの表では表現している。

いずれにしても、そういう形で字間の調整については規格で定義できるし、組版ソフトでもいろいろ対応している。ほとんど、90%近くは、ほぼできている。もちろん設定によるが。Edicolorの初期値はJIS X 4051に準じているので、私はそれを徹底的に改良して私流に直すだろう。直せばかなり自分流の組版、自分の納得のいく組版ができるようになるのではないかと思う。

ルビ

ルビについては、モノルビとグループルビという話がある。書籍をやっていると、モノルビ、グループルビでは処理できないと感じる。
モノルビというのは親文字1文字に対してルビを対応させることで、グループルビというのは複数の親文字に、もちろん1字の場合も含めて、ルビを対応させる。とにかく親文字が複数の状態にルビを対応させる。それを均等に付けるのがグループルビである。
均等にどう付けるかについてはいろいろルールがあって、何種類かがJIS X 4051で規定されている。

グループルビについては基本的に分割禁止である。これは、私に言わせると処理系の処理が難しいから分割禁止にしているのであって、編集側の人間からすると、分割禁止にしてほしくない。要するにグループルビも分割してもいいと思うが、なかなか分割してくれる処理系は多分ないと思う。要するに手動でやらなければならない。自動でやってほしいと思ってはいるが、現時点ではまだ解決していない。

熟語ルビというのは、基本的にはモノルビと同じように個々の漢字に読みを付けるが、同時に熟語としてのまとまりを付けて組んでほしいというものである。
読者が本を読むとき、熟語は熟語としてすっと読む。1字1字の漢字にきちんと対応していなくても読んでいくということで、熟語として読んでほしいということである。例えばここに例を出した「菩薩」のように、ちゃんと漢字が対応できれば対応してもらうという形である。4字の場合で言うと、1つの単位としてまとめてしまおうということである。

それをモノルビで処理するとこうなる。もちろん、モノルビにはいろいろな処理方法があって、どれが正しいとか間違いということはない。ルビの組み方というのは、私が編集に携わった「校正必携」の第7版では約物の組み方原則と言った。それに対してルビの組み方と言った。
要するにルビの組み方というのは、ルールがあってなきがごとしというところがあり、いろいろなやり方がある。どれが間違いでどれが正しいということはなかなか言えないが、「こうしたほうがいい」とか、「こうしたほうが読者にとって望ましい」「このほうがいい」ということは言えるだろう。

いずれにしても、熟語としてのまとまりをとった配置をしてほしい。これはDTPで、要するに入力の方法を変えればいいということになるが、実は熟語ルビの場合、熟語を分割しても構わないので、2行になったとき、もう1回入力し直さなければいけない。そんなことはやっていられない、自動的にちゃんと処理してもらいたいというのが、熟語ルビの考え方である。

残念ながら、JIS X 4051では熟語ルビについて新しく2004年版からは規定したが、実は時間切れで、ちょっと手抜きをした。簡単に言うと、熟語ルビの親文字とルビとの対応が2字以下の場合には、すべての親文字とルビを対応させなさい、それから親文字の中に対応させるルビ文字が3字以上含んでいる場合、グループルビと同じ処理にしなさいという、手抜きをした。それは時間切れで、私が考える望ましい方式をやって審議すると刊行が遅れるということでできなかったためである。

肩ツキ、中ツキということについては2つ定義がある。肩ツキ、中ツキというのはあくまで親文字1字に対してルビ1字の場合だけの配置方法であり、それ以外は関係ないという考え方が1つである。

それから、親文字1字に対してルビ1字までと限定するのではなく、親文字の先頭とルビの先頭を揃えるというのが肩ツキで、中心を揃えるのが中ツキであるという発想がある。多分、ほとんどのDTPソフトはそういう考え方だが、私に言わせると、それはとんでもない。

中ツキの場合にはまだ論理は通じるが、例えば親文字にルビが4文字付いたとき、ここが親文字とすると、肩ツキにしてこういうふうにルビを付けるということは普通やらない。

要するに肩ツキというのはルビの字数が多くなると貫徹できない。そう言った意味では中ツキ、肩ツキという問題について、どっちなのかということをはっきりさせなければいけないだろう。

問題は、肩ツキの場合で、ルビの字数が多くなったときどうするのか、ここに1から3の方法が書いてある。簡単に言うと、親文字のルビにはみ出しがあったときには後ろ側を優先し、前後に配置する文字クラスによって前または後ろ両側にする、あるいは後ろだけにするというふうに、臨機応変にやる。
基本的には後ろに流すということで、ある意味では肩ツキを尊重するが、必ずしも肩ツキにはならない。ケースバイケースで、前に出す場合もあるというふうにするのが1つ。

それから、はみ出す場合もできるだけ前と後ろを均等に付けよう。均等に付けるけれども必ずしも均等にならなくてもいいというのが2番目の考え方。

3番目の考え方は、基本的に全部中央に揃えようというもの。

このように、ルビの字数が多い場合には3つのパターンがあり得る。そうなると、中ツキの場合には（3）のセットだろう。肩ツキの場合は多分（2）か（1）だろう。実は、活字組版時代の伝統的なやり方は、（1）であった。

その（1）の熟語ルビの処理について、X 4051では規定していなかったが、JLREQでは新たにこれを書いた。
簡単に言うと、親文字と1字のルビはそのまま組んでくれればいい。問題は、長くなった場合、下にはみ出すことを優先するということである。下にはみ出せなければ、上にはみ出す。基本的に熟語ルビの間では1文字まで他の漢字にかかってもいいというルールをここでは一応決めている。

それから、例えば「峻別」というときも、やはり下にはみ出しを優先する。これは活字組版の従来からの伝統である。本によっては、例えばこういうふうに、ルビの構成を考えてこういう処理を、赤字入れた形にする組み方がある。これは間違いとは言わないが、従来の活版のやり方は、下にはみ出すのを優先したという形である。

いずれにしても、細かい話をすると時間がないので、読んでいただきたい。しかも、非常に例を多くしているので、これを読んでいただければわかると思う。
問題は、中ツキの場合どうなるかということについては、実はJLREQの時間切れで、公開はあきらめた。
ただし、その後EPUBのメーリングリストに、中ツキ方式による熟語ルビの処理方法ということで、縦組と横組の2つのパターンについて、縦組の場合には親文字の前にルビ1字までかかっていい、横組の場合は前後の親文字に1.5字までかかっていい。
なぜ1.5字までかかっていいかというと、できるだけ横組の場合には全体で左右中央にしたい。そうなると字数によっては1.5倍までかかっていいとしたほうが左右中央になりやすい。少なくとも熟語の構成は考えたいから、少しだけでもかかってもらう。そうすると、1.5倍までするとちゃんと左右中央になってくる。
こういうドキュメントも一応作っているが、これはEPUBに公開しただけで、一般にはまだ公開していない。いずれにしても、熟語ルビについては、自動的に熟語の構成を字数に応じて考えて処理してほしい。そういうことも自動的にやってくれることを、編集者側としては非常に期待している。

行送り方向の配置

行送り方向の配置については、実は行間の問題が非常に大きい。要するに、日本語組版というのは字間をベタにすればとりあえず格好つく。ツメ組とかアキ組にしたいといっても、やると失敗するからやらないほうがいい。とにかくベタ組にすればいい。
ところが行間というのは何らかの値を取らなければいけない。実は、素人が設計する印刷物で一番下手なのは行間である。行間が下手だから、「なんだ、素人が作った」というふうになる。デザイナーに頼むと何となく印刷物が格好付くのは、行間がちゃんとしているからである。

一応ここに目安を書いておいた。ただ、一般的に言うと行間というのは最近の印刷物を見ると詰めすぎていると思う。だんだん歳を取ってきて本を読むのに苦労する人間にとってみると、ちょっと勘弁してもらいたいというものがある。

この間、白水社のノーベル賞をもらった人の分厚い本を読んだが、B6で22行で行間二分で、無理して読んだが、とても大変で内容もよく覚えていないという感じである。「ノーベル賞をもらった立派な作品なのだから、ちゃんと組んでほしい」と思うが、要するに行間というのは重要である。

行送り方向の問題では、一番問題なのは注である。いろいろな注があって、これは後注である。段落の間に入れる。節とか章の末尾に入れるのも後注と言うが、この場合、基本的にここは本文行間、ここは本分行間+ハンパ。そして版面の領域は左右は揃えるというのが原則である。そういう、領域の調整という問題が、実は行送り方向ではある。

先ほど、字詰め方向の行の調整という話をしたが、同じように行送り方向の行の調整があって、実はこの自動処理がDTPは下手である。例えばここでページが変わった場合は、ここに+ハンパをするので、ページが変わるとフリースペースを入れ直さなければいけない。それもある意味では、フリースペースを入れるという1つの便宜的な解決方法だが、やはり自動処理がきちんとできないとうまく組めない。

注

これは脚注である。それから最近増えてきたと思うのは、昔筑摩書房でよくやっていた、こういう注である。これは見開きページの左側に注を入れるもので、傍注と言う。これを90°回転させると脚注と同じである。つまり、横組版の脚注ということである。

簡単に言うと、注というのは、本文中にあるときには、できるだけ注と注がすぐ近くにあったほうが読みやすい。しかし、近くにあると、例えば段落の間にあると、こんなの読みたくないというとき目障りである。
ある意味では、注というのは余分なものだが余分ではない、読みたいが読みたくないという、非常に中間的なものである。そういった意味では、脚注というのは非常に優れた注である。横組の注は脚注が多いが、それと同じように縦組の注は、傍注が使い勝手が良いと思う。

これはサイドノートという。サイドノートの場合には、両側に置く場合と右側に置く場合がある。JIS X 4051では、実はこういう注については規定していない。しかしJLREQでは記述がある。こういう注については並列注という言い方をする。
並列注というのはJLREQ独自に決めた用語なので、まだ市民権がない。本文と同じ版面の中に置いていくという注のグループ、例えば縦組の傍注とか横組の脚注、後注に対して、流れが違うというのを並列注と呼んでいる。今後市民権を得るように広がってほしいと思っているが、こういう注もある。

これも先ほどの注の、読みたいような読みたくないようなという点で言うと非常に便利である。読みたくなければ無視すればいいし、読みたければすぐ近くにあるので便利だが、スペースを取る、余分な空白が空いてしまうという欠点がある。そういう空白が空かないという意味では縦組の傍注が便利である。

行送り方向のハンパの調整という問題が、今後の組版処理では非常に重要である。こういうことが自動処理されないと、なかなか自動化は進まない。今後、特に電子書籍などではこういうことが一切自動的に処理されなければいけないので、こういう機能が今後要求される。今の段階ではこういうのは無理だと思うが、将来的には、JLREQにこういう機能を書いておいたので、多分挑戦してくれる人が出てくるだろうと期待している。

数式のことが書いてある。数式の代わりに図版が入っても同じことである。こういう形で、全部の行間を均等にするというやり方があるが、均等にした瞬間にここの行が行位置に揃わなくなる。基本版面に設定した、つまり大もとで設定した行位置に揃っていない。
それに対して、もう1つのやり方は、行取り。先ほどEdicolorで見出しの行取りというのがあったが、そういう形でやると、ここのところにちゃんと基本版面を設定している行位置に揃う。ところが、アキが不均一になってしまう。
基本的には、日本の数式の組版というのは右側を原則にしている。図版でこういう例を作ると非常に図が大きくなってしまい、数式にしたほうがわかりやすいので数式にしたが、図版が入る場合でも全く同じである。図版が1ページに1つなら問題ないが、2つ入った場合には必ずこういう問題が出てくる。
このように、行送り方向の調整という問題が、実は自動処理の今後の課題としてあるということを考えて、ぜひ皆さんも組版ソフトを作る会社に要求してほしいし、今日お見えになっているエディターはぜひ挑戦していただきたい。

図と表の配置

最後は図版の配置についてである。つい先日私が委員長で、私が住む町の子ども読書推進活動というのをボランティアでただで作ったが、こういうふうに雑誌風に4ページのものがあって、ちゃんと左右がまとまって図版がどこにあってというのをちゃんと設計してやって、図版を置いて、あとは文字を流し込むというのが、まず1のパターン。この場合にはDTPの手動でやっていくという世界だと思う。

それに対して、書籍の場合には本文と対応して、大体1冊の本に5点とか10点とか、大した点数は入らない。それがどこに入るかは組んでみないとわからない。そういう場合に、あらかじめこの辺に置いてほしいというふうな形で設計するのが、書籍の場合の一般的なパターンである。

もう1つ言えることは、書籍の場合、縦組の場合には天・小口に置くのが一般的なパターンである。もちろん下に持っていってもいいし、真ん中に置いてもいい。いずれにしても、一番一般的な、天側の小口、外側に置くのに対して、横組の場合には段落の間に置くか、あるいは一番下に置くか、一番上に置く。
横組の場合には字詰めが少ないので左右の文字を入れるということはあまりない。ずっと流れていって、この図の説明が出た直後に置くとはみ出してしまう。はみ出したとき、何とかしてほしいということである。
こういうふうな横組の流れていって置くような配置について、JIS X 4051では相対位置指定という言い方をしている。それから縦組みの天・小口というものについては絶対値指定という形で、JIS X 4051で図版の配置方法について規定している。

この2つの配置方法についてはJLREQでもJIS X 4051よりは多分わかりやすい図版に変えて書き直している。JISの場合は規格なので非常に厳密に書かなければいけないが、JLREQは易しく、要するに簡単に書きやすいので、JLREQのほうがはるかに書きやすいということである。

本文の関連文書と図版と対応させなければいけないので、リンク箇所を指定する。リンク箇所の近くに置ければ問題ないが、はみ出したときにどうするかということである。そのとき、少しくらいのはみだしなら、そのページを追い込んで、この部分は次のページに持っていけばいい。このようにはみだしが大きい場合は、この図版は次のページに持っていって、後ろにあったページのこの部分はここに持ってくる。

人間が頭で考えることをルール化するとこうなる。この程度のことは、コンピュータなのだから自動でやってほしい。そうすれば大体、図版のたくさん入るものでない限りは結構うまくいく。
この図版の自動配置について、日本語組版処理の、こんなにたくさん図版がある本も、このルールで置いていった。これは相当早い。たくさん図版があるが、結構うまく置いている。

例えばモリサワの処理系も多分こういうものだろう。モリサワの場合は並列注についてもできる機能を入れたのではないか。熟語ルビについてもずいぶん前から挑戦しているという話を聞いたので、多分対応していると思う。組版処理系がこういうJISに書かれたことに従って徐々に取り込まれていく。

絶対配置についてはどうかというと、絶対配置も考え方は基本的に同じである。本当は見開きページの右側だという意味で、線があったほうがいい。
リンクが出てきた。リンクが出てきたので、図版を置いた。置いたら、リンクがそのページにある限りは何も問題ない。同じページにリンク先がある分にはいい。リンク先が次に行ってしまったとき、ここの量とリンクがはみだした量を比較して、こういうふうにリンク先がかなり先に行ったら、図版はこのページではなくこっちのページに持ってくる。この比率については、JISでは1：2ルールと言っているが、別に1：4でも1：5でも、はみだしの程度がどの程度まで許容するかによるが、持っていける。
このようにリンク先が少しだけ次のページに行く場合は、最初に置いたページ、つまり、多少説明、リンク先が行っても、説明はずっと綿々とやっているのだから、多少先に行っても大丈夫だということで、ちょっと程度のはみだしの場合には同じページに置こうというのが、このルールである。

それを数値でやると、aとbを計算してどうやれということだが、そんな面倒なことを考えなくても、たくさんはみだしたら次のページに図版を置くし、ちょっとのはみだしは認めようという形で図版の自動配置をやっていただけるといいと思う。

図版の配置で、印刷物を見ていてどうも気になるのはこれである。この行を見てもらいたい。この行が、ベタになっていない。字間が空いてしまっている。なぜ空いているかというと、ここに線を引いてみるとわかる。これは9ポで組んでいる。9ポの25となって、整数倍になっていない。

図版を組み込むときに、字詰め方向のこの部分は整数倍にしないと、こういうふうに行の調整を全部やってしまう。行の調整というのは出てくるが、例えば13ではちゃんと行の調整がされていない。2ヵ所しか調整していない。それに対してここのところで全部の行が調整されている。こんなばかなことをしてはいけないと言うが、こういう印刷物を結構目にする。
こういうことがないように、これについても実はCSSなどでも今後問題になって、どうやって書こうかと、CSSの日本のエディターの石井氏に今考えてもらっている。

いずれにしても、書籍にしても、文字を組んでいく場合にしても、基本的に組版処理をする側の発想ではなく、編集者というか本を作るほうの側で「こうしてほしい、ああしてほしい」という希望をきちんと言っていく必要があるが、残念ながら、編集者側でこういう発言をする人が非常に日本では少ない。

私の本職は出版教育であって組版が本職ではないが、いつの間にかこういうふうになってやらざるを得ない。先輩たちからいろいろ教わったことをできるだけ後に伝えていくために、私もできる限り頑張ろうと思ってやっているが、ぜひ皆さんもこういう問題について関心を持っていただきたい。

実は関心を持っていただくために必要なことは、要するに文字を並べていく、あるいは本を作る、雑誌を作るときにどういうことが問題になるかという、問題の要素を、「こういうケースがある、こういうケースがある」ということを、いろいろな本を見ながら自分の頭の中に蓄積していくということがまず第一である。

2番目に必要なことは、組版を見る目である。少なくともベタ組から字間が空いているくらいは、見た瞬間に判断できる。あるいは、このページで言うと、2行目のこの部分を拡大すると、点の後ろが詰まっているのがわかる。こちらは全角で、ここは四分だけ詰まる。そういうふうに、約物なんかが見た瞬間に目で判断できるように目を鍛えていくということが非常に重要だと思っている。

いずれにしても、そういう目を日ごろから鍛えていくことによって、組版を評価する、そういう力を付けていただいて、今現在いろいろな規格、いろいろな標準化について発言する場がたくさんあるので、ぜひそういうところで皆さんもどんどん発言していただいて、日本語組版がより読みやすいものになっていけば大変いいのではないかと思っている。

2012年6月26日TG研究会「JIS X 4051からJLREQへ」より（文責編集）