通常、従属欧文は、セットになっている和文と合うようにデザインされた専用のフォントなのですが、「リュウミンL」などはそうはなっていません。「リュウミンL」は欧文フォントのTimes、「中ゴシックBBB」はHelveticaがそれぞれセットになっています。つまり、DTPソフトで1バイト英数字部分のフォントを「リュウミンL」に指定すると、そこはTimesフォントになるということです。
同じ「リュウミン」でもR/M/B/H/Uなど他の太さのフォントは専用の従属欧文がセットになっているのですが、なぜLだけはTimesフォントがセットになっているのでしょうか?
「リュウミンL」と「中ゴシックBBB」は最初の日本語Postscriptプリンタに搭載されたフォントです。これらは元々は写植用の書体だったものをPostscriptに移植したもので、写植書体としての古さはわかりませんが、和文Postscriptフォントとしては最も古いものと言えるでしょう。
その当時は従属欧文を和文に合わせてデザインするという習慣がなかったので、既存の欧文フォントとセットにしたという話を聞いたことがあります。欧文Postscriptフォントの基本フォントはTimes (セリフ) とHelvetica (サンセリフ) とCourier (等幅) なので、おそらく、この中からセリフ書体どうし、サンセリフ書体どうしということで、「リュウミンL」にはTimes、「中ゴシックBBB」にはHelveticaという組み合わせができたのではないかと思われます。
同じ「リュウミン」でもR/M/B/H/Uなどの他の太さは後からPostscriptフォントに登場したもので、その頃にはもう従属欧文を和文に合わせてデザインする習慣ができていたのでしょう。
まあ、経緯はともかく、「中ゴシックBBB」とHelveticaは悪くはない組み合わせだと思います。問題は「リュウミンL」とTimesの組み合わせです。合うか合わないかというのは感覚的なものなので、人によって感じ方は違うと思いますが、私はどう考えても「リュウミンL」とTimesが合うとは思えません。
まず第一に太さの違いです。「リュウミンM」とTimes-Romanとか、「リュウミンH」とTimes-Boldぐらいなら合うかもしれませんが、「リュウミンL」はかなり細いフォントです。Timesと組み合わせると、和文に比べて欧文部分がかなり太くなります。これが違和感の一つ目です。
以下は、リュウミンL/R/M/Bをそれぞれの従属欧文と組み合わせた例です。
この例では「3年E組」という部分は2バイト全角文字を、「English」や「53」の部分は1バイト文字 (いわゆる半角文字) を使って組んでみました。「リュウミンL」だけが他と従属欧文が違っていることがわかると思います。特に数字の字形の違い (「53」の部分) が顕著です。
また、「リュウミン」のLとRを比較すると、和文はRの方が太いのに従属欧文はLの方が太いです。要は「リュウミンL」の従属欧文が太過ぎるんですね。この特徴は技術文書などを組む場合はそれほど問題にならないかもしれません。技術文書では欧文はいわばキーワードです。キーワードが太くなるのは別におかしくありません。
しかし、通常の (文系的な) 和文を組む場合は、決して欧文部分が目立ってはいけないのです。和文の中に埋没してしまう欧文こそが理想的な欧文フォントです。その意味では、通常の文章では「リュウミンL」とその従属欧文 (Times) は合わない組み合わせだと思います。欧文が目立ち過ぎるのです。
なお、TeXの標準フォントのcmr10は、欧文フォントにしてはかなり細い書体で、太さの点ではTimesよりCMフォントの方が「リュウミンL」に合うと思います。
次の問題点は特に縦書きの時に発生します。横書きなら英数字はすべて1バイト欧文で揃えるという手が使えますが、縦書きでは全角文字を縦向きで使ったり、欧文を横向けて組んだりといった、全角文字と半角文字を混ぜて使う場合がよく出てきます。以下は「リュウミンL」とその従属欧文で組んだ例です。
この「NHK」という2バイト文字と「New York」という1バイト文字の字形の違いが気になります (例えば、Nどうしを比べてみて下さい)。また縦書きでは「1桁数字は全角文字で2桁数字は半角文字を並べて」という組み方がしばしば行なわれるやりかたですが、上図のように「リュウミンL」では、「2月」の「2」と「25日」の「2」など、1バイト文字と2バイト文字の字形がかなり違うために違和感を感じます。
実際は、一般の雑誌でも「リュウミンL」とその従属欧文 (Times) を組み合わせた、この組み方はよく見かけるのですが、やはり合っていないと思います。組版した人は合うと思って組んでいるのでしょうか?
ところで、モリサワフォントに「教科書ICA」という教科書体のフォントがあります。このフォントの英数字のデザインは実は「リュウミン」の全角英数字とまったく同じです。記号部分は微妙に違いがありますが、英数字部分は区別が付きません。
これは、「リュウミンR」と「教科書ICA R」の英数字が同じというように太さも対応しています。そして「教科書ICA L」の従属欧文は、きちんと全角文字に合うようにデザインされています。
ということはつまり、「教科書ICA L」の従属欧文こそが「リュウミンL」の本来の従属欧文だ……と言えそうです。実際、DTPソフトで「リュウミンL」の全角文字と「教科書ICA L」の従属欧文を同比率で合成フォントにしてしまえば、この合わないという問題はすべて解決し、きれいに組めると思います。TeXでもこの2つを組み合わせれば万事解決です。
なお、モリサワフォントでは「学参フォント」や「学参常用」とかいう、学習指導要領の字形に合わせたフォントも発売されていますが、こちらの教科書体は従属欧文が丸ゴシック系の字体になっているので、この用途には使えません。
2002年に発売されたOpenTypeの「リュウミンPro L」は、全角文字のデザインは「リュウミンL」と同じで、従属欧文は全角文字に合うようにデザインし直されています。これが使える環境ならこれを使うというのも一つの手です。
もちろん、「リュウミンL」にこだわらないのなら、代わりに「リュウミンR」を使う手もあります。「従属欧文が合わない」という問題があるのは「リュウミンL」だけですから、ヒラギノや平成明朝等にもこの問題はありません。
でも、「リュウミンPro L」(OpenType版) は使えない環境だとか、「教科書ICA L」が印刷所にないとか、Rじゃ太過ぎるといった場合はやっぱり「リュウミンL」だけで解決しないとならないですよね。「リュウミンL」は基本フォントなので、これだけで解決できるならそれに越したことはありません。
先述のように「リュウミンL」の従属欧文は合っていませんが、全角英数は合っていると思います。だったら、すべて全角英数を使って組むという方法が考えられます。もちろん、そのまま全角文字として組んでいては英数字間が間延びしてしまいます。そこで、全角英数に詰め処理をして仮想的にプロポーショナルフォントにしてしまうのです。以下がその例です。
どうでしょうか? この最後に示したパターンなら欧文が太くなり過ぎないし、他の「リュウミンR」などとも似た組みが実現できます。
さて、この全角詰めをマクロで組もうと考えると大変です。そこで、TFMと仮想フォント(VF)を使って実現しましょう。以下の図は「リュウミンL」フォントの全角の「i」の字です。
この外側の枠が全角幅ですが、内側の破線枠が「i」の字の仮想的な活字幅です。この仮想活字幅は、その幅でベタ組みしていくときちんと欧文として組めるというような幅である必要があります。この幅情報をTFMで提供することにします。
そして、詰め処理をするには、矢印で示したように、全角幅と仮想活字幅の差を半分ずつ前後で詰める必要があります。これをVFで行ないます。手順としては、
問題は仮想活字幅をどうやって求めるかですが、もちろん、全角英数はTimesとはデザインが違うので、従属欧文の幅を使うわけにはいきません。また、バウンディング・ボックス (その字形をギリギリ取り囲む枠) の幅とも違います。ここで注目するのは「教科書ICA L」の従属欧文です。これはデザインが同じですから、この従属欧文の幅を仮想活字幅として使えます。
まず前々回のcharwidth.psを「(KyokaICA-Light-83pv-RKSJ-H)」として使い「教科書ICA L」の幅情報を求めます。これを前回のmakeroman.plでPLにしTFMを作成します。これで「教科書ICA L」の従属欧文TFMができたわけですが、これを「リュウミンL」の従属欧文TFMとして使うので、名前はR-ryumin-l.tfmにします。
通常は、従属欧文にはVFは必要ないのですが、今回は詰めた全角文字に変換しないとならないので、R-ryumin-l.vfが必要です。変換後のフォントは横書きの全角英数になりますので、以前に作ったH-ryumin-l (VF変換後横書き和文) と共通にすることができます。
つまり、R-ryumin-l.vfは、詰め処理をすると同時にR-ryumin-l (欧文) フォントをH-ryumin-l (横書き和文) フォントに変換するわけです。そして、変換されたH-ryumin-lをさらにPostscriptフォント名に変換する部分は既にpsfonts.mapで設定済みですね。
こうして全角文字を詰め処理して作成した欧文は、英字部分はいいのですが、数字が2桁以上並ぶと少しキチキチに詰まっている感じがするという問題があります (先ほどの画像を見て下さい)。ここで、数字の仮想活字幅を少し広げるというのも一つの手でしょうが、実はリュウミンの従属欧文の数字はすべてぴったり半角幅をしているので、これはできれば崩したくありません。
そこで注目するのは「リュウミンL」の全角数字は、なぜか他のR/M/B/H/Uに比べて少し幅がある点です。これを微妙に横方向に縮小することで解決することにしましょう。
上の図は先ほどの全角詰めの状態から、数字だけを、位置を変えずにその中心線を対称に横方向にだけ95% 縮小したものです。微妙な違いですが、先ほどの画像と見比べると、数字周りがすっきりしたと思います。
他にも、全角の下線「＿」はほぼ全角幅近くありますが、欧文では半角幅ぐらいが適当なので、横方向に50% 縮小した方がいいとか、記号部分は少し微調整が必要です。
dvipsのpsfonts.mapには、ExtendFontという命令を書くことで文字を横長にする機能がありますので、これに1.0より小さい倍率を指定することで横方向だけ縮小することができます。変換後の名前は、H- の部分に倍率を表す数字を千分率 (パーセント値の10倍) で付けるとすると、psfonts.mapは、
H-ryumin-l Ryumin-Light-H
H950-ryumin-l Ryumin-Light-H "0.95 ExtendFont "
H900-ryumin-l Ryumin-Light-H "0.9 ExtendFont "
H850-ryumin-l Ryumin-Light-H "0.85 ExtendFont "
H800-ryumin-l Ryumin-Light-H "0.8 ExtendFont "
H750-ryumin-l Ryumin-Light-H "0.75 ExtendFont "
H600-ryumin-l Ryumin-Light-H "0.6 ExtendFont "
H500-ryumin-l Ryumin-Light-H "0.5 ExtendFont "
こんな感じになります。もちろん、dvipsを -SJISで起動する場合はRKSJ系のフォント名を指定して下さい。
VFの動作としては、英字部分は全角に変換してH-ryumin-lフォントを指定、数字部分は全角に変換してH950-ryumin-lフォントを指定、下線は全角に変換してH500-ryumin-lフォントを指定……以下同様といった感じになるでしょう。もちろん、詰め処理のための移動コマンドも必要です。
というわけで、以上のことを実現するVF作成スクリプトです。
→ makezenvf.pl (perlスクリプト、EUC)
「リュウミンL」仮想活字幅PLファイル (「教科書ICA L」従属欧文PLファイルと同じ) を読み込みますので、コマンドラインから、
./makezenvf.pl R-ryumin-l.pl
などとPLファイルを引数として起動すると、R-ryumin-l.vfが作られます。PLファイルは、必ず前回のmakeroman.plスクリプトの出力か、tftoplコマンドが出力したものを使って下さい。自分でエディタで作ったPLファイルなど、特殊な書き方をしているものはうまくいかないことがあります。この場合は、pltotfで一旦TFMにした後、tftoplで再びPLに戻して、それを読み込ませた方が無難です。
できたR-ryumin-l.vfは、フォント名をH-ryumin-lやH950-ryumin-lなどに変換するようになっていますので、上述のようにpsfonts.mapにこれらのフォントの設定を書いておいて下さい。
また、H-ryumin-l.tfmやH950-ryumin-l.tfmなども必要ですが、これらはH-*.tfmとすべて同じファイルでいいので、他からコピーしておいて下さい。後は普通にR-ryumin-l.tfmを使って組版できます。
このスクリプトは、読み込ませるファイル名をR-ryumin-l.plではなく、例えば、
./makezenvf.pl R-hoge-b.pl
などとすると、R-hoge-b.vf を作成します。できたVFは H-hoge-b や H950-hoge-b などのフォント名に変換しますので、これらにpsfonts.mapでPostscriptフォント名を設定しておけば、「リュウミンL」以外のフォントでも全角英数を詰め処理してプロポーショナル欧文とするVFを作成することができます。
もっとも、「リュウミンL」以外は真っ当な従属欧文があると思いますので、普通はわざわざ全角英数を詰め処理する必要はないとは思います(笑)。ただ、プロポーショナル従属欧文は事実上Macの文字コードを指定しないとならないという制約がありますが、全角英数を詰め処理するならMacの文字コード (83pv) を使わなくて済みます。これを利点と感じる人もいるかもしれません。
もちろんこの場合、仮想活字幅のPLファイルは別に用意しておかないとなりません。また、「リュウミンL」では数字を95% 横縮小する……などといった比率でうまくいきましたが、フォントが違うと比率も違ってくるでしょう。これらのパラメータはスクリプトの先頭部分で設定していますので、別のフォントでやる場合は、適当にパラメータを編集して下さい。