SUBMENU

詰め組

このページでは、和文詰め組の実現について説明しています。パッケージは以下からダウンロードできます。

パッケージのダウンロード
サンプル文書（「我輩は猫である」より）標準組・詰め組

はじめに

「和文詰め組」とはいったい何のことでしょうか。実際このページもツメ組で表示されている人も多いのではないかと思います。詰め組とは、和文は全角基準で組むべきという伝統と美しさを無視した、醜く読みにくい組み方の一つです。

和文組の考え方

基本的に和文は全角基準で組みます。これの意味は、和文を構成する総ての文字が全角幅によって配置されるべきだということです。全角幅とは、文字の持つ高さと同じ幅であることをいいます。欧文の場合、一般的には文字の幅と文字の高さとは異なる概念です。典型的な例でいえば「M」と「i」では文字の幅は異なります。Mはしばしば全角幅を持つことがあります。欧文では文字の大きさは高さで指定します。幅という概念はほとんど何の意味も持っていないからです。もちろん、高さの定義も曖昧です。「M」と「x」では文字の高さが異なります。高さとは字形のデザイナが想定した大きさのことであり、字形をいくら解析してもその文字セットの大きさは不明です。この事情は和文組でも同じであり、全角と呼ばれる長さの辺で構成される正方形の中のどの位置にどの大きさで実際の字形を配置するかは総てデザイナの裁量次第であり、デザイナがこれを決定します。このように書くと、フォントの「大きさ」はデザイナにのみ依存し、他のいかなる絶対基準にも従わないように感じられます。絶対基準の不存在は人によっては奇異に感じられます。しかしながら、これは全く以て自然なことです。フォントとはフォントデザイナによる一つの芸術作品であり、文字組とは一種の芸術表現です。

では、いかにしてデザイナは文字の大きさを決定するのでしょうか。それは、そのデザイナが考えた字形をもっとも美しく出力できるとデザイナが考えたサイズです。文字組においてはこのデザイナの感性を最大限に尊重します。一般に、優秀なデザイナによって作成されたフォントは、そのデザイナが想定したもっともよい組み方からはずれると、醜い仕上がりを生みます。

しかしながら、一般に和文組においては、文字は全角基準で組むという伝統がありますから、ほとんど総てのフォントは全角基準で組まれるという仮定の下にデザインされています。

詰め組の必要な局面

以上に述べたように、和文フォントは伝統的に全角基準で組まれ、したがってデザイナは全角基準で組まれることを想定してフォントを作成し、そしてそれがもっとも美しい組を実現できます。すなわち、全角基準以外の組が存在する余地はないように感じられます。

しかしながら、以上の記述は総て暗黙の仮定の下に述べられています。それは、想定しているのが本文組だということです。本文組以外に文字が使用される印刷物は意外と多くあります。たとえばポスターなど。ポスターにおいては文章を組むことはむしろ少ないといわざるを得ません。これらポップの作成については、TeXが対象とする組ではありません。（作り出そうとする作品や作業に応じて適切な道具を選択することは重要なことです。人間にとって異なる種類に感じられるならば、おそらくそれは本質的に違う作業であり、従ってその目的および手段も異なります。）

TeXが得意とする作業はおそらく同意が得られると思いますが、書籍組に代表されるような文章の作成です。少ない図版、体系だてた説明を記述するのに適しています。このような組においては内容のほとんど総てが本文です。しかしながら全く総てというわけではありません。たとえば章や節の題は本文ではありません。それらの文字は通常大きめの文字が用いられます。

大きい文字で組むとき、全角基準は一般には美しい出力を与えません。たとえば文字自体が全角幅を持たないもの、すなわち括弧類や句読点類など約物と呼ばれる（全角でない謂）ものが必然的に伴うアキは、見出しなどではみっともない空白を与え、文字が散らばっている印象を与えます。読者の注意を引くために文字を大きくするのは視線をそこに集中させるためですが、それが散らばった印象を与えては元も子もありません。最悪です。

約物だけではありません。小学校で習ったように、文字を書くときには仮名文字は小さめに書きます。よくデザインされたフォントでは当然ながら仮名文字は小さめにデザインされています。とはいってももちろん組は全角基準で行なわれるのですから、必然的に仮名文字はその周囲にやや大きめのアキを与えます。これは約物同様に見栄えをわるくすることがあります。
以上のようにアキを削る必要のある箇所が存在することは確かなことで、しかしながらそれはきわめて限定的な局面でした。言い換えれば、活字で書籍を組むときに活字の縁を削って組んでしまっても労力的にも、また植字作業的にも問題となるものでなく、そして実際に行なわれていました。

最後に本文組に関してもツメが必要な局面を述べます。基本的に和文組は全角基準で組まれ、デザイナもそれを想定すると述べましたが、現在においても出版される印刷物の大多数は縦組みです。これを反映して、和文フォントに含まれる英数字は、縦組みで使われるためのものが入っています。縦組みではそれでよいのですが、横組みでは和文フォント由来のものであろうと英数字は詰めて組まなければかえって見栄えがわるくなります。これは例外というわけではなくて、英数字部分に関しては和欧混植の規則が適用されるべきだという考えです。

TeXでの対処

考え方

TeXの組版作業という点において、活字の縁を削ることに対応する命令は\kernです。たとえば、有名なTeXのロゴはそのようにして作成されています。実際、現在まででもきわめて技術の高い印刷会社においては、TeXの処理をする前に自動的に（前述したように詰め組が必要な局面はきわめて限定的であり、よくかけた原稿に対してはツメが必要な箇所を機械的に発見することはさして困難ではありません）ツメを行なうべき箇所を発見し、プロの目で適切に決められた\kernを挿入してからTeX処理を行なっています。ところがこれには重大な欠点があります。それは、

自動で詰め組の必要な位置を検出するプログラムは（筆者の知る限り）一般的に公開されておらず、されていたとしても完全に汎用的なものには仕上がるべくもない（たとえば、\sectionや\LARGEなどの指定を文脈無視で総て扱ってよいものか？）。また別途プログラムを走らせるなどの手間も必要となってしまう。Omegaシステムではこの種の処理は比較的楽だと思われるが、現時点でOmegaシステムはあまり普及していない。
適切なツメ量はいかにして判断するか。もちろんツメ量はそれぞれのフォントによって異なる。総てのフォントに適合するツメ量などありえない。標準的なフォントに関してという限定であっても、WindowsではMS 明朝は標準であるが、PostScriptではリュウミンかもしれない。ともにライト・ウェイト（細字）の明朝体であるが、当然ながらツメ量は異なる。プロが時間をかけて検討するか、最初からデザイナ側が考えた（もし存在すれば）ツメ量を知らなければ、文字デザインの専門家や組版の最高級の熟練者でなければ適切なアキ量などわからない。

以上のような点が主な困難であって、TeXでは今まで一般ユーザの使える環境としては、詰め組は手に入りませんでした。しかしながら文頭で指摘したように、この文書を見ている多くの人が、詰め組の表示を見ていると思われます。少なくとも、筆者が使っているHTML作成ソフトでは詰め組で表示されています。これは、言い換えれば、少なくともWindowsのソフトは、自然に詰め組を実現できるということであり、その理由はもちろん、TrueTypeフォントにそのための情報が含まれているからにほかなりません。もちろん、総てのTrueTypeフォントに用意されているわけではなく、一部に限られます。それらのフォントは、たとえば、ＭＳ明朝の場合は、「ＭＳＰ明朝」のようにＰを冠した名前が付けられています。これはプロポーショナルの頭文字だと想像していますが、すでに述べたように、欧文のいわゆるプロポーショナルとは性質のことなるものですから注意してください。このたとえば「ＭＳＰ明朝」は、フォントのデザイナが決めたツメの情報を持っているわけですから、それを利用すれば、「ＭＳＰ明朝」による自然な詰め組が可能となるのは明らかです。なお、ＭＳＰ明朝は字形はＭＳ明朝と全く同一で、実際ディスク上のファイルとしても同一のものです。ただWindowsへの登録の際に別名で2つ登録され、ＭＳＰ明朝の名前で使用されると、配置情報として詰め組のものが用いられるということです。また、繰り返しになりますが、ＭＳＰ明朝のツメ情報は、あくまでＭＳ明朝の字体に対してのみ適用可能なものであって、同じ明朝でも他のフォントには適用できません。そのため、当たり前のことですが、もしプリンタが明朝体を内蔵していた場合、通常はドライバ側の標準設定としてＭＳ明朝はプリンタフォントに置き換えられますが、ＭＳＰ明朝はたとえそのようなプリンタであっても字形データがダウンロードされます。そうでなければ正しい出力ができず、文字の配置バランスがわるいものになってしまったり、最悪の場合文字同士が重なる可能性すらあります。（そのため、ＭＳ明朝とＭＳＰ明朝の字形出力は画面では全く同一であるにも関わらず、印刷結果では異なる字形が使われることがあります。）なお、フォントの中には「S」を冠した名前を持つものがありますが、これは「半角文字」に関してだけプロポーショナル情報を持つようになるものであり、いわゆる和文部分はツメは行なわれません。TeXでは英数字部分は欧文用フォントを用い、それらを同一のフォントからは提供しないメカニズムになっているので（実際にはdvioutのトリックなどで不可能ではないのですが）ここでは対象から外すこととします。

何を詰めるか

筆者は昔、とあるコンピュータ雑誌で、プロポーショナル和文フォントが初めて搭載されたときの記事として、「たとえば『日』と『興』では明らかに幅が違うので文字幅にあわせて組むのが自然である」という記事を見たことがあります。愕然としました。もちろんこれは完全な誤りです。TrueType詰め組は、非漢字に対してのみ定義されます。（漢字に対してツメの情報が含まれているものは今まで見たことがありません）記号類、（いわゆる全角）英数字、そして仮名が対象です。通常は「カナツメ」と呼ばれるもので、これは伝統をふまえ、また現実的に妥当なものです。いくら幅が違うとはいえ、漢字を詰めると読みづらくて仕方がありません。何の御利益もありません。漢字は詰めません。漢字を詰めたいと感じたら、フォントデザイナや組版技術者、そして我々は何の手助けもしません。自分で\kernを入れてください。そして、冷ややかな目、変なものを見る目で見られる事を覚悟し、決意の上でやってください。また、しつこく強調しますが、本文は詰めないように。誰かに読んで欲しいのなら、本文は全角基準です。（欧文レイアウトで組まれた和文など読める代物ではないものを作る人が増えていますが、本当に読んで欲しいのなら、内容は当たり前ですが、見た目も同じくらい重要だということを再度確認してください。）ところで、ツメのために提供しているマクロ集では、そう簡単にツメ組に移行できないようになっています。読者がこの問題に深く立ち入りたくないなら、マクロパッケージを読み込むだけで必要な箇所が自動的にツメられますので、それをあてにしてください。

JFM作成における問題点

さて、TrueTypeフォント（に限らない）がツメの情報を持っているとするなら、その情報を抽出し、それにあったJFMファイルを作成すればTeXで組めるようになるというのは当然のことです。しかしながら話はそれから伝わってくる感じほど簡単ではありません。それは次のような点にあります。

ツメの文字は多数に上る。pTeXでは和文フォントをいくつかのクラスと呼ばれる同じ組規則適用が可能な種類に分けているのだが、許容されるクラスの数はあまり多くない。（当然ながら、もっとも単純なモデルは「全角べた」と呼ばれる総ての文字種を同一としたもの、また開き括弧、閉じ括弧などに分けた本文組用のものも数個の文字クラスで事が足りている。）
文字クラスの数が増えると、それと同時に考え得るクラス間の組み合わせも莫大な量となりうる。問題なく定義するのは困難である。
さらに、いかに詰め組といっても行分割は決して破ることのできない最優先すべき組版規則である。すなわち、簡単にいえば行末をそろえるために適切な空白を文字間に埋めなければならない（もちろん、それは美しく見える範囲の中でも最小にとどめられるべきだが、その計算はpTeXが担う）。そのバランスを考慮に入れる必要がある。（ツメが存在すると、行長が全角べたで完全にきっちり収まるサイズであっても、決してそれにちょうどとはならなくなってしまうことに注意）

和文のJFMに関しては、実は深い研究は今まであまり行なわれてこなかったのですが、東大数理の大島利雄教授によって体系的な分析（今まで東京書籍印刷の小林肇さんによるJIS規格の実装などの研究があったが、それを受けた研究）が行なわれました。本ページで述べる内容も、あるいはその成果もこの研究の結果の（ささいな）成果の1つです。

ここでは詳細は省きますが、ツメ用のJFMはこれらの制限を十分に考慮し、JFMの規格の中で最大の精度でツメの情報を詰め込むことができるようにして作成されています（この方法もまた大島教授によるものです）。TrueTypeフォントデザイナがデザイン時に想定したツメを完全に再現できているとは限りません（もちろん再現できているものもあります）。しかしながら、完全ではなくても、少なくとも人間の目には（たとえプロ級であっても）わからない程度には最大限の微調整を行なっていますのでご安心ください。この制限は、Omegaが完全なものとなったときに取り除けるかもしれませんが、断言はできません。完全主義を目指す読者はOmegaを待ちましょう。

出力時の注意

出力には、真に正しいフォントを用いる必要があります。一般にpTeXにおいて、和文は全角基準であるために（min10はすこし凝りすぎだが）どんなフォントを用いても出力できるとされています。たとえば、min10フォントにMS 明朝を当てたり、リュウミンを当てたり、その他プリンタフォントを当てたりも問題なくできるというわけです。もちろん、原理的にはVirtual Fontを用いるのが理想的かもしれませんが、Virtual Fontなしであっても代用ができます。ところが、詰め組用のJFMは、ある特定のフォントに激しく結びついています。決して代用はできません。従って、もちろんパッケージに含まれるファイルをどのような用途に用いるかは総てユーザの自由ではありますが、

（たとえば）mspmin.vf を作成してrml, ryumin-lにアクセスしてはいけません。
DVIドライバ組み込みの機能を利用して、想定している以外のフォントに割り振ってはいけません。

上記は禁止ではなく、正しい出力を得るために必要なことです。素人目には問題なく見えるかもしれませんが、それは「問題ない出力」とはここでは呼びません。

現在、詰め組フォントのJFMを使うには、その対応したフォントを出力できる環境が必要です。すなわち、フォントの実体は常に必要となります。Windowsの場合、その正しくフォントをインストールする必要があります。Macintoshでもそうでしょう。また、この方法がもっとも確実・高速・そして美しい出力を得られ、さらに汎用性も高いものになります。それに対して、いわゆるUnix互換環境（MS-DOS含む）においては、このような利便性を得ることができません。やはりいったんPostScriptファイルに変換する必要があるでしょう。PostScriptファイルに変換するには、そのフォントのPostScriptファイル名を知る必要があります。実際にはその名前は適当に決めてしまっても、個人の範囲であれば問題は生じないのですが、ファイルをそのコンピュータから持ち出すと深刻な問題を引き起こすことがあります。そのような問題を避けるためには、正しいPostScriptフォント名を使用しなければなりません。

正しいPostScriptファイル名を取得することは、それほど簡単といえる作業ではないので、配布されるパッケージにはPostScriptファイル名の対応表がついています。これを利用すれば、正しく変換できるようになります。個別のソフトウェアの個別の設定項目はそれぞれのマニュアル等を読み、行なってください。配布パッケージに含まれているのは、dviout用の設定です。

pTeX2.1.10以前について

pTeX2.1.10（含む）以前のpTeXでは、詰め組のJFMフォントを用いて組版を行なったとき、まれに正しく行分割できない現象の発生するJFMが少数あります。この問題はpTeX側の問題であることが確認されており、角藤さんが配布されている最新の実行ファイルではすでにアスキーの対処法が適用されています。ただし、今までの記述内容により、たとえこの問題が発生するpTeXを使用しても、特に問題は生じません。ただし、現時点ではアスキーより正式に対処法が公開されたわけではなく、上記のものは暫定のものです。