dvipsのpsfonts.mapなどに書くPostscriptフォント名は、今まで「Ryumin-Light-H」や「ShinGo-Medium-V」といったものを使ってきました。このように、和文Postscriptフォントの名前は「-」記号で3つの部分に区切られています。
1つ目の部分は「Ryumin」や「ShinGo」などのフォント・ファミリー名を表します。字形が同じで太さだけ違うものをファミリーと呼び、それらに共通の名前がついているのです。
2つ目の部分は「Light」「Medium」「Bold」など、文字の太さを表します。フォントによっては「W3」「W5」など数字で太さを表す場合もあります (数字が大きいほど太い)。そして、3つ目の部分は「H」(横書き用) か「V」(縦書き用) で、組み方向を表しています。
しかし、今まで出てきませんでしたが、この2つ目と3つ目の間には文字コードを指定できるようになっているのです。
例えば「Ryumin-Light-EUC-H」だと日本語EUCが指定されます。このフォントを使う場合は、文字データもEUCになっている必要があります。
Shift JISなら「Ryumin-Light-RKSJ-H」のようにRKSJを付けます。このフォントを使う場合は、文字データもShift JISコードになっている必要があります。ちなみに、「RKSJ」は「Roman Kana Shift JIS」の頭文字です。なお、Shift JISには亜流があって、さらに以下のような指定もできます。
ちなみに「漢字Talk 6」とは、要は「日本語版MacOS 6」のことです。当時は「MacOS」という名前はなかったですけどね。
なお、文字コードを指定しない「Ryumin-Light-H」のような形は、JISコードを意味します。これを使う場合、文字データはJISコードになっている必要があります。ただし、Internetメールなどで使われているJISコード (ISO-2022-JP) とは違って、PostscriptのJISコードはエスケープ・シーケンスを含みません。そのため、1バイト欧文文字を混ぜることができません。
プリンタ内蔵のPostscriptフォントは、基本的にこれらすべての文字コード版がインストールされているので、どの文字コードのフォントでも指定できます。
先述のようにJISコードでは1バイト欧文文字を含めることができませんが、EUCかShift JISのフォントを指定すると、1バイト欧文文字を使えます。そして、それが従属欧文で出力されるのです。しかし、従属欧文はどの文字コードでも同じ出力になるわけではありません。以下の例を見て下さい。
上記はどちらも「ヒラギノ丸ゴW4」フォントですが、他のPostscriptフォントでも状況は同じです。つまり、83pvや90pvなどのMacintosh用の文字コードを指定した場合は、欧文部分がプロポーショナル (可変幅) フォントになるのですが、その他の文字コードを指定した場合は半角等幅になります。
欧文の等幅フォントは、通常、タイプライタやコンピュータ端末を意識した部分に使ったり、ソースコードを表示する場合などだけに使います。等幅フォントで通常の文章を組むと、むりやり半角幅に狭められた文字や、空きを入れて半角幅に延ばした文字などが混在することになり、不格好です。先ほどの画像でも下側の図 (Windowsなどの出力) は「i」の字の周りなどにすき間が空いてたりして不格好でしょう?
また、効果を狙って等幅フォントを使うような場合は、基本的にそういう用途に適した欧文フォントがありますので、わざわざ従属欧文を使う必要もないと思います。欧文主体の文書でも欧文フォントを使うのが正解でしょう。
従属欧文を使うのは、和文主体の文章の一部に欧文が出てくるような場合で、これはプロポーショナル (可変幅) であってほしい場面です。すると、従属欧文を使うときは、Macintoshの文字コードを指定する必要があるという話になります。
ちなみに、最新のPostscript3環境でのOpenTypeフォントでは、90msp-RKSJというWindows用のプロポーショナル従属欧文が用意されています。これを使えば、Windowsでも従属欧文のプロポーショナル出力ができるようです。
しかし問題があり、この90msp-RKSJは、少し古い出力装置では使えません。印刷所の出力機 (イメージセッタ) は、プリンタほど頻繁に買い替えるものではないので、印刷所に入稿する場合、現在ではまだ対応していないと考えた方がいいでしょう。確実なのは83pv-RKSJで、DTP業界では未だに83pv-RKSJが業界標準文字コードになっています。MacOS X がある時代になんでOS6のコードだよって感じですが。
dvipsはpsfonts.mapに書かれたPostscriptフォント名に従ってPostscriptファイルを出力します。つまりここで、1バイト文字に対して83pv-RKSJが付いたフォント名を指定しておけば従属欧文を使ったPostscriptファイルができるわけです。例えば、
\gt\bf 英語はEnglishです。
このTeXソースをそのまま処理してdvipsに掛けると、和文部分が「中ゴシックBBB」で欧文部分がcmbx10のPostscriptファイルができると思います。論文の強調部分などによく使われる組み合わせですね。
では試しに、psfonts.mapのcmbx10の行の前に % を入れてコメントにし (後で戻すので消してしまわないように)、以下の行を追加してみます。
cmbx10 GothicBBB-Medium-83pv-RKSJ-H
この状態で、dvipsを実行すると今度は欧文部分が「中ゴシックBBB」の従属欧文になります。dvipsはDVIファイルに書き込まれたフォント名を任意のPostscriptフォントに置き換えることができるので、このような芸当ができるわけです。あ、これは単にテストなので、終わったらpsfonts.mapは元に戻しておいて下さい(笑)。
しかし、1つ問題があります。この方法で作ったPostscriptファイルは確かに従属欧文のフォントになっていますが、文字位置が妙にずれるのです。
この例だと「English」の後ろがやけに空いていますね。これはcmbx10に比べて、「中ゴシックBBB」の従属欧文は幅が狭いデザインだからです。
TeXはTFMに従って、各文字を配置していきますが、TeXが処理したときはcmbx10のTFMを見ていたために、その幅に合わせて「English」という単語を置く領域を確保していました。しかし、組み終わった後 (DVIファイルになった後) に、勝手にフォントを幅の狭い従属欧文に変更したらすき間が空くのは当然です。要は、きちんと組むには、TeXがDVIファイルを作る (組版する) 時点で従属欧文の幅情報が必要なのです。つまり、従属欧文のTFMファイルが必要ということになります。
和文は基本的にすべての文字が正方形で、フォントを変えても文字幅は変わりませんが、欧文はフォントごとに文字幅が違います。つまり、和文ではTFMを共通にすることができましたが、欧文では一つ一つのフォント専用のTFMが必要になります。
各フォントの文字幅情報を求めるためには、Postscriptのstringwidthという命令が使えます。そこで、従属欧文の各文字の幅を求めるPostscriptプログラムを作ってみました。
→charwidth.ps (Postscriptファイル)
このファイルを直接モリサワフォント搭載Postscriptプリンタで印刷してみて下さい。「中ゴシックBBB」の従属欧文の各文字幅情報が印刷されます。
なお、「%!PS-Adobe」で始まるソース自体が印刷された場合は、ドライバーで変換されてしまっていますので、きちんと「直接」印刷されていません。テキストとして印刷するのではなく、このファイルを直接プリンタに送り込んで下さい。UNIXならlprコマンドでできると思いますが、TCP/IP対応プリンタの中にはftpで転送できるものもあります。
さて、印刷されたものを見て、例えば「33 - 278」という行があったとしたら、これは文字番号33番 (「!」の文字です) は全角の1000分の278の幅があるという意味です。つまり、10ptの「!」は2.78ptの幅があるというわけです。この値はフォントごとに異なりますので、このデータを使ってTFMを作ります。
このcharwidth.psファイルの最初の方に「(GothicBBB-Medium-83pv-RKSJ-H)」という行がありますが、テキスト・エディタでこの括弧内のPostscriptフォント名を書き換えます。
例えば「新ゴL」なら「(ShinGo-Light-83pv-RKSJ-H)」にします。括弧は必ず付けたままにして下さい。これを「新ゴL」が搭載されたPostscriptプリンタで印刷すると、「新ゴL」の文字幅情報が得られます。他のフォントでも同様です。
場合によっては、Postscriptプリンタにはフォントが搭載されていないがOSにPostscriptフォントがインストールされているという環境もあるでしょう。この場合、charwidth.psをAcrobat Distiller (製品版) で開いてPDFに変換して下さい。出来上がったPDFで文字幅情報が見られます。
例えば、OpenType版「ヒラギノ明朝Pro W6」がインストールされているなら、charwidth.psのフォント名部分を「(HiraMinPro-W6-83pv-RKSJ-H)」に変更してAcrobat Distillerで開けばいいのです。なお、ghostscript (gs) で開いた場合は、代替フォントの方の情報が得られてしまうと思いますので、たぶん使えません。
環境によっては、IllustratorやPhotoshopで開いてもうまくいく場合がありますが、「リュウミンL」と「中ゴシックBBB」だけは違うフォントの情報を取得してしまうおそれがあるので、この2つのフォント情報を知りたいときはモリサワフォント搭載Postscriptプリンタで印刷することをお勧めします。これは、この2つのフォントは日本語Postscript環境の標準フォントと位置付けられているため、代替フォントに変わってしまうことがあるためだと思われます。
TFMを作るには各文字の幅情報以外にも必要な情報があります。例えば、文字の高さや深さなどの縦方向の長さ情報も必要です。しかし、従属欧文は和文と一緒に使われるものですから、すべて和文と同じ高さや深さを設定しておけば問題ないと思います。つまり、すべての文字を高さ0.876深さ0.124に設定することにします。
また、欧文TFMにはイタリック補正値を設定できますが、和文フォントは基本的にイタリック体ではないので、なしでいいでしょう。あと必要なのは、合字 (リガチャ) とペア・カーニングの情報です。この説明は次回にしましょう。