pLaTeX2e における和文フォントの扱いと多書体化の話

大袈裟な標題をつけてしまいましたが、何も目新しいことも、難しいことも書いてません。

(p)LaTeX2e における （本文・和文） フォントの扱いについては、ZR さんのブログ の諸解説 （例えば ココ とか ココ とか） ですとか、たちゃなさんの解説 で必要な情報はひととおり尽くされていると思うのですけど、もう少しウダウダした説明を試みてみようかと思います。なお、ここでは大雑把な仕組みを理解することに主眼を置いてますので、具体的な設定方法については触れていません。

■ 前 提 ：

I．　基本的な仕組みについて

（1） NFSS によるフォント属性の組み合わせ

（2） NFSS の属性の組み合わせに対応する TFM のロード （\DeclareFontShape）

（3） TeX が使った TFM から dviware/driver の使う TFM へ （Virtual Font）

（4） TFM と実フォントとのマッピング （dviware/driver の map ファイル）

（5） まとめ

II．　多書体化 （ファミリやウェイトのバリエーションの増設） について

III．　多書体化パッケージについて

（1） モリサワ基本 5 書体パッケージ

（2） OTF パッケージ

Since: September 20, 2012.

(p)LaTeX2e のフォントの扱いをひとことでまとめるなら、原稿ファイルにおいて NFSS の属性を個々に変更することが出来て、それら属性の組み合わせに対応した tfm (jfm) がロード出来ると TeX によるタイプセットが可能になり、あとは dviware/driver が、その出来上がった dvi ファイルに使われた tfm と実フォントとをちゃんと対応させることが出来れば、めでたく出力することが出来る、ということになるかと思います （但し、dvips や dvipdfmx の場合は、約物のアキを調整するために (j)vf を使っているので、実際には、これらの dviware/driver は、ロードされた tfm と同名の vf を介して別の tfm を参照しているため、dviware/driver の map ファイルには、その参照先の tfm と実フォントとの対応関係を指定することになります）。

I．　基本的な仕組み

まず、デフォルトの和文フォントの設定について、確認します：

（1） NFSS によるフォント属性の組み合わせ

NFSS の 5 つの属性の組み合わせはよく、encoding/family/series/shape/size のようにスラッシュで区切って表現されます。

和文のエンコーディングは普通 JY1 か JT1 の 2 つのみで、また、フォントサイズの指定も特に複雑ではないので、encoding と size は原則省略して話を進めることにします。

デフォルトでは、和文フォントについては、family/series/shape が、

に対応する tfm しか用意されてませんよね。ファミリは “mc” と “gt” の 2 つありますが、それぞれ、シリーズは “m” のみ、シェイプも “n” のみです。

※ 実際には、縦書き用もあるので 2 書体 （mc と gt） について それぞれエンコーディングが 2 つずつ （JY1 と JT1）、計 4 種類の組み合わせ （JY1/mc/m/n, JT1/mc/m/n; JY1/gt/m/n, JT1/gt/m/n） に対応する tfm が用意されています。 なお、「書体」 という用語は意味が広いですけど、「多書体」 というときは、「複数のファミリ」 という意味にして、同一ファミリの series や shape の違いは 「多ウェイト」 とか 「多シェイプ」 と言ったほうが、整理がしやすいような気もします。でも、大抵は、同一ファミリでもウェイトやシェイプが違うと別の 「書体」 と呼ばれることが多いですね。

※ 実際は、mc、gt ともに、デフォルトでミディアム・ノーマル （m/n） のみでなく、ボールドエクステンディド・ノーマル （bx/n） の設定もされていますが、mc/bx/n は gt/m/n に代替され、gt/bx/n は gt/m/n に代替されるように設定されています。この代替をやめて、bx/n の組み合わせに対して m/n とは別の tfm を対応させれば、多ウェイト化が実現するということになります。 II． でもう少し詳しく説明をします。

※ NFSS の属性の変更は、\kanjifamily{}\selectfont, \kanjiseries{}\selectfont, \kanjishape{}\selectfont, \usekanji{}{}{}{}, \mcfamily, \textmc{}, \gtfamily, \textgt{}, \bfseries, \textbf{} 等々のコマンドで行います。例えば、

mc/m/n
　　↓
ファミリを gt に変更したい
　　↓
\kanjifamily{gt}\selectfont または \gtfamily, \textgt{}
　　↓
gt/m/n
　　↓
シリーズを bx に変更したい
　　↓
\kanjiseries{bx}\selectfont または \bfseries, \textbf{}
　　↓
gt/bx/n

（2） NFSS の属性の組み合わせに対応する TFM のロード （\DeclareFontShape）

NFSS の属性の組み合わせに対応する tfm をロードする設定は、fd ファイルや sty ファイル、cls ファイル内の \DeclareFontShape の宣言によっています。 デフォルトでは、

をそれぞれロードするように設定されています （参照： jy1mc.fd や jsclasses.dtx 等々）。 つまり、（縦書きまたは横書きの） 5 〜 10 ポイント用の tfm が、サイズ指定に応じてロードされるようになっているわけです （jarticle.cls 等の場合）。ここでは、話を簡単にするために、横書きの 10 ポイントの場合にだけ着目して、

が各々ロードされる設定になっていると考えることにしましょう。

　　↓
それで、原稿ファイルで NFSS の属性の組み合わせを指定して 〔（1）〕、LaTeX で処理をすると、対応する tfm が \DeclareFontShape の宣言にしたがってロードされて 〔（2）〕、 dvi ファイルが出来ます。 このとき、dvi の中には、タイプセットの際に使われた tfm のファイル名が、'min10'、'goth10'、'cmr10' のように、拡張子なしで書き込まれます。 あとは、この dvi をプレビューしたり印刷したりするのは、dviware/driver の役目です 〔（3）、（4）〕。
　　↓

（3） TeX が使った TFM から dviware/driver の使う TFM へ （Virtual Font）

和文フォントの一部のグリフについては、tfm 内のグリフの幅と実フォントのグリフの幅が異なっているため、それを調整するのに、dvips や dvipdfmx の場合は、virtual font を利用しています。TeX がタイプセットに使った tfm と同名の vf の中では、別の tfm が参照されていて、また、ズレが生じるグリフについては、水平方向にズレを調整するように設定がなされています。「vf が参照している別の tfm」 は、min10.tfm については rml.tfm で、goth10.tfm については gbm.tfm です。つまり、dviware/driver は、dvi ファイル内で “min10” という名前を見つけると、min10.vf を探し、min10.vf の中では rml.tfm が参照されている、というわけです。

（4） TFM の実フォントへのマッピング （dviware/driver の map ファイル）

最後に、タイプセットされた結果を実際に出力するには、dviware/driver のために tfm と実フォントとの対応づけが必要です。ここでは dvipdfmx 用の map ファイルのみを取り上げます。 上述 （3） より、rml.tfm と gbm.tfm に、実フォントを対応させればいいわけで、cid-x.map のエントリを見てみますと、

rml   H   :0:msmincho.ttc
gbm   H   :0:msgothic.ttc

となっていて、MS 明朝と MS ゴシックを埋め込む設定になっています （ちなみに、“:0:!msmincho.ttc” に変更すると、pdf を開く環境に MS 明朝があれば MS 明朝で表示されますが、埋め込みはされなくなります）。これは手元の、タイムスタンプが 2012/03/20 の cid-x.map の設定ですが、以前は、

rml   H   Ryumin-Light
gbm   H   GothicBBB-Medium

となってました （pdf ビューアが理解できる名前参照だけで、フォントは埋め込まない設定．この場合、Adobe Reader だと、多分、小塚明朝と小塚ゴシックで表示されます）。手元の W32TeX [2012/08/30] の $TEXMF/fonts/map/dvipdfm/base には、和文フォント関連の map としては、

なんかが用意されてます。msembed.map は現在の cid-x.map と同様に MS 明朝、MS ゴシックを埋め込む設定用で、noembed.map が以前のような、埋め込まない設定用ですね （なお、DVIPDFM-W32.txt の説明には、今でも、「配布パッケージの cid-x.map では、rml に対して Ryumin-Light, gbm に対して GothicBBB-Medium を対応させており、これらは埋め込まれません。TrueType フォントの埋め込みのテストをするには -f msembed.map を最初のオプションにします」 と書かれていますが、どこかのタイミングで変更されたのでしょう）。

【追記 1 】 [2013/04/11] 以降の W32TeX では、dvipdfmx 用の和文 map が大幅に追加され、且つ update されているようです （cmap も追加されてます）。
　　和文用に用意されてる map は、こんなに豊富になってます： hiragino.map, hiragino04.map, hiraginopron.map, hiraginopron04.map, ipa.map, ipaex.map, kozuka.map, kozuka04.map, kozukapr6n.map, kozukapr6n04.map, morisawa.map, morisawa04.map, morisawapr6n.map, morisawapr6n04.map, msmingoth.map, noembed.map, noembed04.map.
　　noembed.map とかについても、以前の noembed.map では rml, gbm, rmlv, gbmv についての設定しか書かれていませんでしたが、新しい noembed.map には、uptex や OTF の tfm についてもフォントを埋め込まない設定が追加されています。
　　あと、DVIPDFM-W32.txt の説明も、現在のタイムスタンプが [2012/09/26] のものではちゃんと 「配布パッケージの cid-x.map では、rml に対して msmincho.ttc, gbm に対して msgothic.ttc を対応させており、これらは埋め込まれます。」 となっていますね。 [Added: May 20, 2013]

【追記 2 】 現在の cid-x.map [2013/06/15] では、デフォルトの和文フォントの割り当てが、

　　rml H ipaexm.ttf
　　gbm H ipaexg.ttf

へと変更されています。 [Added: June 18, 2013]

【追記 3 】 W32TeX [2016/03/12] 以降の dvipdfmx.cfg では、デフォルトで読み込まれる map が、cid-x.map から kanjix.map へと変更されました。 〔参考〕 [Added: March 25, 2016]

（5） まとめ

以上、原稿ファイルにおける NFSS の属性の指定から、TeX によるタイプセットを経て、処理結果の dvi ファイルを dvipdfmx が pdf にする際の、デフォルトの和文フォント指定の流れをまとめますと、

mc/m/n --(\DeclareFontShape)--> min10.tfm  --(vf)--> rml.tfm --(map)--> msmincho.ttc

のようになっています。

繰り返しになりますが、NFSS によるフォントの属性は、\kanjifamily や \bfseries 等々で変更可能で、fd や sty、cls における \DeclareFontShape の設定により、属性の組み合わせに応じた tfm がロードされて、TeX による処理が可能となります。プレビューや印刷を担当する dviware/driver は、dvi ファイルに書き込まれた tfm 名から同名の vf を探し、その中で指定されている別の tfm を参照していて、map ファイルの設定により、その tfm と実フォントとを対応させて出力をしている、ということになります。

II．　多書体化 （＝ファミリやウェイト等、バリエーションの選択肢の拡大）

上で見たような仕組みから、いわゆる 「多書体化」 は以下のようにして可能になります （話を簡単にするため、横書きについてだけ考えることにして、あと、サイズ毎に tfm をロードするなんてことも、しないことにします）。

デフォルトでは、和文フォントについては mc/m/n、mc/bx/n、gt/m/n、gt/bx/n という 4 つの NFSS の組み合わせが設定されていますが、しかし、mc/bx/n は gt/m/n に代替され、gt/bx/n は gt/m/n に代替されるように設定されていますので、結局、ファミリは mc と gt という 2 つのみ、シリーズ、シェイプも各 1 バリエーションずつのみで、その m/n という組み合わせに対応した tfm しか用意されていません （横書きだけ考えて、サイズ別のロードもしないことにすれば、必要な tfm の数は、mc/m/n 用と gt/m/n 用がそれぞれ 1 つずつの計 2 つということになります）。

※ I．（2） で見ましたように、実際には、min や goth の場合、6 種類ずつのサイズが用意されているので、mc/m/n と gt/m/n という 2 つの組み合わせに対して、縦書きと横書きそれぞれ 6 サイズずつ、計 24 個もの tfm が用意されています。でも、実のところ、サイズの大小に応じてフォントのデザインを変えたりするのでなければ、ひとつの NFSS の組み合わせに対していくつものサイズの tfm を用意する必要はありません。というわけで、デフォルトの設定を満たすためには、横書きだけ考えた場合、tfm は mc/m/n 用と gt/m/n 用がそれぞれ 1 つずつあれば十分なので、それで、ここでは必要な tfm は 2 つと数えています。

そこで、この代替をやめて、また、ファミリやシリーズ、シェイプの選択肢を増やして、そして異なる組み合わせには異なる tfm を対応させれば、多ウェイト化や多書体化が実現できることになります。tfm ファイルは既存の min10 とか jis を別名でコピーすればよく、必要な vf とその参照先の tfm は makejvf というプログラムで作れます。

例えば、代替をやめるとすると、

のそれぞれの組み合わせについて、それぞれ異なる tfm をロードするように \DeclareFontShape の設定をして （つまり tfm は 4 つ必要）、それらの tfm に dviware/driver の map ファイルで適切な実フォントを割り当てればよい、ということになります （dvips や dvipdfmx の場合、正確には vf の参照先の tfm に、ですが）。これは、2 書体 （mc と gt） について、それぞれ 2 ウェイトずつ （m と bx） という構成です。

ウェイトについて、デフォルトではミディアム （m） の上がボールドエクステンディド （bx） になっているのは、LaTeX2e の \bfdefault の値が bx となっていることに合わせてなのですが、例えばもう一段階上にエクストラボールド （eb） を導入して、

という風に 2 書体それぞれに 3 ウェイトずつ、という構成にすることも考えられます （この場合、tfm はもちろん 6 つ必要）。

Windows にバンドルされている MS 明朝や MS ゴシックにはウェイトのバリエーションがないので適当な例を探すのが難しいのですが、例えばヒラギノ角ゴなんかだと、W3、W6、W8 と、同一ファミリでウェイトのバリエーションがあるので、

と割り当てることが出来ますね （明朝系で、同一ファミリで m, bx, eb の 3 ウェイト用意できるフォントは何があるかな…）。

NFSS の記号は、予め \DeclareKanjiFamily や \DeclareFontShape で宣言さえしておけば何でも構わないので、ファミリ、シリーズ、シェイプは、今出てきた、mc, gt, m, bx, eb, n に限られるわけではありません。

ファミリを増やすとすると、例えば、「丸ゴシック体」 （mg: marugothic） みたいなのを導入するとか、あとは、シリーズに 「細字」 （l: light） を用意したり、更には、個人的にはあまり感心しませんが、シェイプに 「斜体」 （sl: slanted） を導入する、というようなことも考えられます （但し、そういう実フォントが存在するか、dviware/driver の機能でそれが実現可能でなければ意味がありませんけど）。

なお、最終的にどのフォントで出力されるかというのは、map ファイルの設定次第なので、今見た 「2 書体各 3 ウェイトずつ」 という NFSS の組み合わせについても、（必要な実フォントさえあれば） map での割り当て如何では、1 書体 6 ウェイトの出力にしたりですとか、はたまた 6 書体 〔ファミリ〕 にしたりということも、可能です （つまり、必ずしも素直に NFSS の組み合わせの意味に即した実フォントを割り当てなくてもよい、ということです）。

※ ちなみに、次の III．で取り上げる 2 つのパッケージはいずれも、「明朝 2〜3 ウェイト、ゴシック 2〜3 ウェイト、丸ゴシック 1 ウェイト」 という構成になっていますが、それは恐らく、当初の目的が、モリサワなりヒラギノなりの既存のフォントパック （明朝 + ゴシック + 丸ゴシック） を利用することだったからなのであって、どういうファミリのフォントのどういうバリエーションを使用する構成にするかは、ユーザーが各々手元で利用可能なフォントに合わせて決定すればいいことです。

III．　多書体化パッケージについて

さて、仕組みが分かれば、あとは必要なバリエーションの数だけ tfm や vf を作って、必要な諸設定を施せばいいわけですけれど、和文の多書体化について、既にパッケージ化してくださっているものがいくつもあります。

代表的なのは、奥村晴彦先生の morisawa.sty と、齋藤修三郎さんの otf.sty でしょうか。

（1） モリサワ基本 5 書体パッケージ

奥村先生の morisawa.sty では、 
rml/m/n --(\DeclareFontShape)--> Ryumin-Light-J.tfm --(vf)--> ryumin-l.tfm
rml/bx/n --(\DeclareFontShape)--> GothicBBB-Medium-J.tfm --(vf)--> gtbbb-m.tfm
fma/m/n --(\DeclareFontShape)--> FutoMinA101-Bold-J.tfm --(vf)--> futomin-b.tfm
fma/bx/n --(\DeclareFontShape)--> GothicBBB-Medium-J.tfm --(vf)--> gtbbb-m.tfm
gbm/m/n --(\DeclareFontShape)--> GothicBBB-Medium-J.tfm --(vf)--> gtbbb-m.tfm
gbm/bx/n --(\DeclareFontShape)--> FutoGoB101-Bold-J.tfm --(vf)--> futogo-b
jun/m/n --(\DeclareFontShape)--> Jun101-Light-J.tfm --(vf)--> jun101-l.tfm
jun/bx/n --(\DeclareFontShape: ssub*jun/m/n)--> Jun101-Light-J.tfm --(vf)--> jun101-l.tfm
の 8 つの組み合わせについて設定がされています （横書きの設定のみをリストアップしましたが、実際には縦書きについても設定されています）。

NFSS の組み合わせとしては、明朝体 2 ファミリ各 2 ウェイト、ゴシック体 1 ファミリ 2 ウェイト、丸ゴシック体 1 ファミリ 2 ウェイトの構成ですが、この 8 つの組み合わせに対して実際にロードする tfm は、明朝用が Ryumin-Light-J と FutoMinA101-Bold-J、ゴシック用は GothicBBB-Medium-J と FutoGoB101-Bold-J、そして丸ゴシック用には Jun101-Light-J の 5 つとなっていることが分かります。

※ 元々想定されている “モリサワ基本 5 書体” は 「リュウミン L」 「太ミン」 「中ゴシック BBB」 「太ゴ」 「じゅん」 の 5 つ。これらを dvips で使用するための tfm, vf, map をまとめた 「モリサワ 5 書体 TFM & VF セット」 (morisawa.tar.gz) をアスキーが配布していて、morisawa.sty は、この tfm や vf を利用するものです。なお、末尾が “-J” のものは jis.tfm と同じ中味の tfm で、他に末尾が “-H” のものと “-V” のものも用意されていて、それぞれ、min10.tfm、tmin10.tfm と同じ tfm とのことです。W32TeX にも収録されています。

※ morisawa.sty では \mcdefault が rml に設定されていますが、rml/bx/n に対しては GothicBBB-Medium-J をロードしており、FutoMinA101-Bold-J.tfm をロードしたり fma/m/n に代替したりするようにはなっていないので、デフォルトでは 「太ミン」 を使うには、明示的に family を fma にする必要があるようです （「互換性のため明朝のボールドを中ゴシックにします。」 と、意図的にそういう設定にしてらっしゃることが morisawa.dtx できちんと説明されています）。

dvipdfmx で使うとするならば、map での実フォントの割り当ては例えば、

ryumin-l   H  HiraMinPro-W3
futomin-b  H  HiraMinPro-W6
gtbbb-m    H  HiraKakuPro-W3
futogo-b   H  HiraKakuPro-W6
jun101-l   H  HiraMaruPro-W4

とかでしょうか。うーむ、適当な実フォントが思いつかないので、ヒラギノを当ててしまいました。

「明朝体 2 ウェイト、ゴシック体 2 ウェイト、丸ゴシック体 1 ウェイト」 の構成に合うような実フォントを割り当てるのが素直な利用法ではありますが、しかし、手持ちのフォントに合わせて自由に map ファイルは書き換えて利用すればいいのではないかと思います （なお、手元の cid-x.map を見ますと、“Morisawa (CID)” という設定と、“Morisawa OpenType Basic 7 Family Pack” という設定が、コメントアウトされた状態で予め書かれています）。

※ morisawa.sty を使えぱ、map での割り当てを変えるだけで手持ちのフォントを 5 つまで使うことが出来るようになりますが、NFSS の意味に対応しない実フォントを割り当てるのが気持ち悪い （使いづらい） 場合には、morisawa.sty をマネして、手持ちのフォント用に新たに sty を書いてしまえばいいですね。 （プロポーショナルでない） 和文用の tfm は中味はどれも一緒でいいので、モリサワ用と銘打たれた tfm であっても中味は min10 や jis と同じものなので、他の和文フォントにもそのまま流用出来ます （それだからこそ、和文フォントの場合は、map で任意のフォントを当てることが可能なわけです）。

（2） OTF パッケージ

OTF パッケージが元々想定していたフォントの構成については、齋藤さんご自身が TeX Q & A: 54533 で、

OTFパッケージの開発目的はMac OS Xに付属するヒラギノを使うためでした． 従って、明朝体がW3, W6の2シリーズ、ゴシック体がW3, W6, W8の3シリーズ、 丸ゴシック体がW4の1シリーズの構成となっています．（明朝体にはW2用もありますが……）

とおっしゃっています。そして、マニュアル （otfmanual.pdf） には、

deluxe オプションを宣言すると、明朝体、ゴシック体それぞれ２ウェイトが使用出来ます。つまり、mc/m, mc/bx, gt/m, gt/bx/n に別々のフォントを割り当てるようにします。

また、丸ゴシックも使えるようになります。\mgfamily を宣言すると丸ゴシックになります。（勿論、丸ゴシックとして表示されるかどうかはフォントマップで割り当てられたフォント次第です）

また、プロポーショナル仮名、およびヒラギノ明朝W2 やヒラギノゴシックW8 も使えるようになります。フォントの切り替えはそれぞれ \propshape, \ltseries, \ebseries で行なえます。

と説明されています。つまり、deluxe オプション適用時には、

明朝体 （family: (h)mc）
- series: medium, bold extended
(h)mc/m/n --(tfm --> vf)--> otf-ujmr-h, otf-cjmr-h, hminr-h --(map)--> HiraMinPro-W3
(h)mc/bx/n --(tfm --> vf)--> otf-ujmb-h, otf-cjmb-h, hminb-h --(map)--> HiraMinPro-W6
- series: light 【for: (ex.) ヒラギノ明朝W2】
(h)mc/l/n --(tfm --> vf)--> otf-ujml-h, otf-cjml-h, hminl-h --(map)--> HiraMinPro-W2
- shape: proportional 【for: プロポーショナル仮名 of ヒラギノ明朝W3, W6 (only)】
(h)mc/m/prp --(tfm --> vf)--> hiramin-w3-h --(map)--> HiraMinPro-W3
(h)mc/bx/prp --(tfm --> vf)--> hiramin-w6-h --(map)--> HiraMinPro-W6

ゴシック体 （family: (h)gt）
- series: medium, bold extended
(h)gt/m/n --(tfm --> vf)--> otf-ujgr-h, otf-cjgr-h, hgothr-h --(map)--> HiraKakuPro-W3
(h)gt/bx/n --(tfm --> vf)--> otf-ujgb-h, otf-cjgb-h, hgothb-h --(map)--> HiraKakuPro-W6
- series: extra bold 【for: (ex.) ヒラギノ角ゴW8 】
(h)gt/eb/n --(tfm --> vf)--> hgotheb-h --(map)--> HiraKakuStd-W8
- shape: proportional 【for: プロポーショナル仮名 of ヒラギノ角ゴW3, W6 (only)】
(h)gt/m/prp --(tfm --> vf)--> hirakaku-w3-h --(map)--> HiraKakuPro-W3
(h)gt/bx/prp --(tfm --> vf)--> hirakaku-w6-h --(map)--> HiraKakuPro-W6

丸ゴシック体 （family: mg）
- series: medium
mg/m/n --(tfm --> vf)--> otf-ujmgr-h, otf-cjmgr-h, hmgothr-h --(map)--> HiraMaruPro-W4
- shape: proportional 【for: プロポーショナル仮名 of ヒラギノ丸ゴW4 (only)】
mg/m/prp --(tfm --> vf)--> hiramaru-w4-h --(map)--> HiraMaruPro-W4

という風に、NFSS の組み合わせとしては、明朝体が 1 ファミリ 3 ウェイト （+ プロポーショナル仮名 2 ウェイト）、ゴシック体も 1 ファミリ 3 ウェイト （+ プロポーショナル仮名 2 ウェイト）、そして丸ゴシック体が 1 ファミリ 1 ウェイト （+ プロポーショナル仮名 1 ウェイト） 使えるように設定されます （横書きの設定のみをリストアップしましたが、実際には、縦書きについても設定されています）。

※ 明朝体の 3 ウェイトというのは、m、bx と、l で、他方、ゴシック体の 3 ウェイトは、m、bx と、eb になっています。

※ ここでは、「map で “ヒラギノ基本 6 書体” + ヒラギノ明朝W2 を割り当てている例」 （hiraginox.map に相当） を表わしているつもりです。青字の 7 フォントについては任意の和文フォントに置き換えることが可能ですが、プロポーショナル仮名用の tfm は上記の 5 フォント専用なので、これら 5 つの tfm に割り当てる赤字のフォントについては変更は出来ません。

※ otfbeta では、明朝とゴシックのファミリがそれぞれ hmc、hgt ですが、\mcdefault と \gtdefault が hmc、hgt に設定されているので、\mcfamily、\textmc{} 等が普通に使えます。\kanjifamily や \usekanji でファミリを明示的に指定する場合には、hmc や hgt とする必要があります。

$TEXMF/doc/platex/japanese-otf/ を見ますと、dvipdfmx 用 map のサンプルとしては、

が用意されていますが、手元の cid-x.map には、このうち、hiraginox.map と （multi オプション適用時の簡体字・ハングル・繁体字用の） cktx.map に相当する設定がされていて、あと、kozukax.map に相当する設定がコメントアウトされた状態で書かれています （README.w32 には、「Windows 用の cid-x.map には、kpzukax.map に従ったものが予め記述してあります。hiraginox.map の場合も、コメントアウトして記述してあります。」 と説明されていますが、多分、どこかのタイミングで逆にされたのでしょう）。

【追記】 タイムスタンプが 2012/09/26 の現在の README.w32 では既に 「Windows 用の cid-x.map には、hiraginox.map に従ったものが予め記述してあります。他のいくつかの場合も、コメントアウトして記述してあります。」 となっていますね…。 [Added: May 20, 2013]

■ 参考：

Last modified: October 7, 2012.

【補足】

Added: September 28, 2012; Last modified: Sep 30, 2012.

【補足】

冒頭で 「具体的な設定法には触れない」 と言ったのに反する気もしますが、I．と II．に書いたことを、少しだけ具体的にもまとめておきます：

Added: October 4, 2012.

【補足の補足】

「“F”、“W”、“S” の文字列は何でもいい」 と思ってたのですけど、fntguide.pdf を確認しましたら、“6.4 Naming conventions” には一応、

Whenever possible, you should use the series and shape names suggested in The LaTeX Companion since this will make it easier to combine new fonts with existing fonts.

と書いてありました （一部省略して引用しています）。 また、The LaTeX Companion, 2nd だと、

The family names should not be longer than five letters, because they will be combined with possibly three more letters to form a file name, which on some systems can have at most eight letters. (p. 413)

とか

The naming convention covers internal TeX names for fonts (i.e., those used in \DeclareFontShape declarations as described in the next section), names for virtual fonts and their components (e.g., particular reencodings of physical fonts), and the names of physical fonts. (p. 420)

と説明されているところからすると、どうも、NFSS のファミリ名を tfm や vf のファイル名の一部としても使う場合を想定していて、且つ、ファイル名に 8 文字までしか使えない OS に配慮して、「ファミリ名は 5 文字以内に」、と言っているようなので、そのどちらにも当てはまらないのなら、多分、5 文字を超えても、また、小文字に限らなくとも、大丈夫なんじゃないかと思います （例えば、MinionPro パッケージなんかを見ると、“MinionPro-OsF” というファミリ名や、“sscit” というシェイプがあったりしますし）。

Added: October 5, 2012; Last modified: Oct 7, 2012.

【補足】　NFSS のたくさんの “default” について

I．（1） で、

ファミリを gt に変更したい
　　↓
\kanjifamily{gt}\selectfont または \gtfamily, \textgt{}

シリーズを bx に変更したい
　　↓
\kanjiseries{bx}\selectfont または \bfseries, \textbf{}

と書きましたが、前者のほうは、「または」 の前後ともに “gt” が使われているので、直感的にも理解し易いのですが、後者のほうは、「または」 の前では \kanjiseries を “bx” にしているのに、「または」 の後ろでは “bf” が使われているという点に、少し戸惑われたかも知れません。

実は、\kanjifamily{gt} や \kanjiseires{bx} は、直接ファミリやシリーズを変更していますが、それに対して、\gtfamily や \bfseires のほうは、ファミリやシリーズを間接的に変更しています。

つまり、\gtfamily や \textgt{} は、「ファミリを \gtdefault に変更する」 コマンドです。同様に、\bfseries や \textbf{} は、「シリーズを \bfdefault に変更する」 というコマンドとして定義されています。そして、\gtdefault の値が gt で、\bfdefault の値が bx となっています。

これを踏まえますと、III．（2） に書いた、

otfbeta では、明朝とゴシックのファミリがそれぞれ hmc、hgt ですが、\mcdefault と \gtdefault が hmc、hgt に設定されているので、\mcfamily、\textmc{} 等が普通に使えます。

も、同じことだとお分かりいただけるかと思います。つまり、\mcfamily や \textmc{} は、「ファミリを mc に変更するコマンド」 ではなくて、「ファミリを \mcdefault に変更するコマンド」 なので、\mcdefault の値を hmc に再定義すれば、\mcfamily や \textmc{} によって、ファミリが hmc に変更される、ということになるわけです。

NFSS ではたくさんの default が用意されていて、ユーザー用のコマンドは、それぞれの属性をその予め用意された default に変更するように定義されています。

例えば、\normalfont や \textnormal{} は、family/series/shape を、欧文については \familydefault/\seriesdefault/\shapedefault にし、和文については \kanjifamilydefault/\kanjiseriesdefault/\kanjishapedefault に変更するコマンドです。

ここで、それぞれの値が、

\familydefault: \rmdefault
\seriesdefault: \mddefault
\shapedefault: \updefault

\kanjifamilydefault: \mcdefault
\kanjiseriesdefault: \mddefault
\kanjishapedefault: \updefault

となっていて、これらの値が更に、

\rmdefault: cmr
\mddefault: m
\updefault: n
\mcdefault: mc

であるので、つまりは、欧文が cmr/m/n で、和文が mc/m/n となる、というわけです （ちなみに、cls ファイルの中とかでよく見かける \reset@font は \normalfont のコピーです）。同様に、

となっています。

そういうわけで、上の 【補足】 で、

原稿では、\kanjifamily{F}\selectfont、\kanjiseries{W}\selectfont、\kanjishape{S}\selectfont を使って個々の属性を変更出来ます （実際には、\Ffamily, \textF{}; \Wseries, \textW{}; \Sshape, \textS{} みたいなのを定義することが多いでしょう）。

と言ったことも、LaTeX の慣例に倣って定義するのであれば、例えば、\Ffamily や \textF{} というコマンドは、ファミリを直接 “F” に変更するのではなくて、一旦 \Fdefault を定義した上で、ファミリを \Fdefault に変更するようにして、そして、\Fdefault の値を “F” にする、という形になります （特定のフォント用の設定ならば、そこまで汎用性を考える必要は、ホントはない気もしますけど）。

Added: October 8, 2012.

【補足】 デザインサイズ や オプティカルサイズ と \DeclareFontShape のサイズ指定について

I．（2） では話を複雑にしないために、\DeclareFontShape のデフォルトの設定については、

つまり、（縦書きまたは横書きの） 5 〜 10 ポイント用の tfm が、サイズ指定に応じてロードされるようになっているわけです （jarticle.cls 等の場合）。

とだけ書きました。他方、II． では、

でも、実のところ、サイズの大小に応じてフォントのデザインを変えたりするのでなければ、ひとつの NFSS の組み合わせに対していくつものサイズの tfm を用意する必要はありません。

とも言いました。

それで、実際の JY1/mc/m/n についての \DeclareFontShape の宣言は、次のようになっています：

\DeclareFontShape{JY1}{mc}{m}{n}{<5> <6> <7> <8> <9> <10> sgen*min
    <10.95><12><14.4><17.28><20.74><24.88> min10
    <-> min10
    }{}

つまり、JY1/mc/m/n という組み合わせに対して、<5>, <6>, <7>, <8>, <9>, <10>, <10.95>, <12>, <14.4>, <17.28 >, <20.74>, <24.88>, <-> というサイズ指定がされていて、これらに対応してロードされる tfm としては、min5, min6, min7, min8, min9, min10 の 6 つが用意されています。

<5>, <6>, <7>, <8>, <9>, <10> については、min5, min6, min7, min8, min9, min10 がそのままロードされ、<10.95>, <12>, <14.4>, <17.28 >, <20.74>, <24.88> 及びそれ以外のサイズ （<->） に対しては、min10 が拡大・縮小されてロードされるように宣言されています。

ここで、min5 〜 min10 はいずれも （デフォルトの） vf を介すると rml.tfm に帰着されるため、せっかく 6 種類も tfm を用意しても、最終的には rml にマッピングされたひとつのフォントで出力されることになります （dvips や dvipdfmx の場合）。しかし、同一ファミリでもサイズに応じてデザインが異なるようなフォントがあるならば、min5 〜 min10 それぞれに、そのサイズ別のフォントを割り当てるようにすれば、よりきめの細かい組版が実現出来ます。

※ 尤も、min 等の等幅の和文フォントの場合は、以下で触れる cmr なんかとは異なって、サイズが違っても tfm の中味には差はないですし、5 pt 〜 10 pt でデザインに変化をつけてみても、その効果は小さいでしょう。下で仮定している “GoodFontPro” の例ですとか、最後に挙げた tumegumi.sty みたいな例のほうが、より現実的ではあります。

サイズの大小に即して、より美しい乃至より視認性が高いデザインを用意することを、「デザインサイズ」 とか 「オプティカルサイズ」 と呼ぶらしいです （でも、サイズごとにデザインを変えるとなるとコストが掛かるので、現在では一つのサイズを拡大・縮小して利用することが多いですよね 〔スケーラブルフォント〕）。

Computer Modern ではこのデザインサイズ 〔オプティカルサイズ〕 を採用していますので、例えば、cmr5, cmr10, cmr12, cmr17 をいずれも 30 ポイントに拡大したものを並べてみますと、こんな風になります：

デザインサイズが小さいほうの文字は、太くて幅が広く、デザインサイズが大きいほうの文字は、ほっそりしたデザインになっていますが、これらは、ウェイトが違うわけではなくて、サイズによってデザインを変えていることによります。

市販されているフォントでも、高級な欧文フォントだと、オプティカルサイズが提供されているものがあります。仮に、Caption, Regular, Subhead, Titling という 4 つのオプティカルサイズが用意されているようなフォント “GoodFontPro” があるとして、それぞれをサイズに応じて使い分けるとするなら、（ファミリ名を GdFntPro とすると） \DeclareFontShape の宣言は、

\DeclareFontShape{LY1}{GdFntPro}{m}{n}{
     <-9>    LY1-GoodFontPro-Caption
     <9-14>  LY1-GoodFontPro-Regular
     <14-24> LY1-GoodFontPro-Subhead
     <24->   LY1-GoodFontPro-Titling
     }{}

みたいな感じになるでしょうか。この場合、LY1/GdFntPro/m/n について、9 pt 未満では LY1-GoodFontPro-Caption.tfm がロードされて、9 pt 以上 14 pt 未満では LY1-GoodFontPro-Regular.tfm が、14 pt 以上 24 pt 未満では LY1-GoodFontPro-Subhead.tfm、そして、24 pt 以上では LY1-GoodFontPro-Titling.tfm がロードされる、という設定です （サイズを切り替える境界を 9 pt, 14 pt, 24 pt としているのは適当です）。

※ LaTeX2e における欧文フォントの扱い一般についてはこれ以上深入りしませんが、この例では、4 つの tfm のエンコーディングは LY1 にしてあって、原稿でも LY1 を使うという前提です。あとは、dviware/driver の map ファイルで texnansi.enc あたりを使って、それぞれの tfm に実フォント “GoodFontPro” の Caption, Regular, Subhead, Titling を割り当てることになります。

今の LY1/GdFntPro/m/n では、サイズが連続するような設定を考えてみましたが、上の JY1/mc/m/n （＝ 和文のデフォルト） の場合は、12 種類のサイズ指定と、それ以外の任意のサイズという指定になっていました。これに対して、OT1/cmr/m/n （＝ 欧文のデフォルト） の場合には、サイズ指定が 12 種類のみの決め打ちになっています：

\DeclareFontShape{OT1}{cmr}{m}{n}%
     {<5><6><7><8><9><10><12>gen*cmr%
      <10.95>cmr10%
      <14.4>cmr12%
      <17.28><20.74><24.88>cmr17}{}

JY1/mc/m/n の場合だと、最後に “<-> min10” が付け加わっているので、設定されたサイズ以外のサイズが指定されると、min10 が拡大縮小されてロードされますが、OT1/cmr/m/n の場合には、予め設定されているサイズに代替されてしまいます （つまり、デフォルトでは、欧文は <5>, <6>, <7>, <8>, <9>, <10>, <10.95>, <12>, <14.4>, <17.28 >, <20.74>, <24.88> の 12 サイズしか使えません）。

※ \tiny 〜 \Huge では内部でこれらの設定済みのサイズ （5 pt 〜 24.88 pt） が使われていますので、\fontsize で直接サイズを指定したりしないで \tiny 等々のコマンドを使っている限りでは、12 サイズしか使えなくとも格別不都合はありません。

※ ちなみに、type1cm.sty では、OT1/cmr/m/n について、サイズ指定を “<-6> cmr5 <6-7> cmr6 <7-8> cmr7 <8-9> cmr8 <9-10> cmr9 <10-12> cmr10 <12-17> cmr12 <17-> cmr17” としていて、サイズが連続するように変更されています。

※ OT1 と T1 の Computer Modern のデザインサイズに関する細かい話になりますが：
　ot1cmr.fd の OT1/cmr/m/n と type1cm.sty の OT1/cmr/m/n とでは、サイズ指定の仕方が違うだけで、使っている tfm は 同じ 8 個の tfm （cmr5.tfm 〜 cmr17.tfm） です。
　それに対して、t1cmr.fd の T1/cmr/m/n だと、サイズ指定が “<5> <6> <7> <8> <9> <10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> <29.86> <35.83> genb*ecrm” となっていて、サイズが 14 種類の決め打ちで、それに対応してロードされる tfm も ecrm0500.tfm 〜 ecrm3583.tfm の 14 個となっています （EC フォント）。
　上の min のところで言及しましたように、サイズ毎に対応する tfm を増やせば、それだけきめ細かい組版といえる一方、当然ですが、サイズによってデザインが変わるということにもなり得ます。
　つまり、OT1/cmr では 12 サイズに対して 8 個の tfm を拡大縮小して対応していたところを、T1/cmr では 14 サイズに対して 14 個の tfm を当てているので、サイズによっては OT1/cmr とはデザインが異なることになります （具体的には、<5> <6> <7> <8> <9> <10> <12> は OT1 でも同じデザインサイズがあったので、残りの <10.95> <14.4> <17.28> <20.74> <24.88> の 5 サイズについて、デザインに違いが生じることになります．<24.88> よりも大きいサイズはそもそも ot1cmr.fd では使えませんでしたが、仮に type1cm.sty を使って cmr17 を <29.86> や <35.83> に拡大したとしても、そのデザインは飽くまで cmr17 であって、t1cmr.fd の <29.86> <35.83> と同じではありません）。
　　※※ T1 の Computer Modern のサイズ指定を決め打ちではなく連続的にするものとしては、cm-super バンドルに入っている type1ec.sty がありますが、ロードする tfm の数とサイズが t1cmr.fd のものと変わらないので、デザイン差の問題は依然として残ります。
　　※※ この、T1 の Computer Modern のデザインがサイズによって OT1 のものと異なるということを回避し、且つ任意のサイズを指定できるようにしたものに、fix-cm.sty というのがあります （結局、T1 でロードする tfm の数とサイズを OT1 のときと同じにして、他方、サイズ指定は type1cm.sty や type1ec.sty のように連続的にしてあります）。それにしても、「T1 にしたら何か OT1 のときより少し線が細くなったんじゃない?」 なんて気付くのは、相当昔から Computer Modern を使われてた方ですよね…。
　　※※ なお、W32TeX には cm-super バンドルはデフォルトでは含まれていないので、手元の pdfmfnt.map には ecrm0500 等々のエントリはないですし、対応する sfrm0500.pfb といったフォントも収録されていません。そのため、W32TeX のデフォルトの状態で、エンコーディングを T1 にするだけで何もフォント関係の指定をしないでタイプセットをして dvipdfmx で pdf にすると、欧文フォント （Computer Modern） が Type3 になってしまいます。あちゃー。

ちょっと実験をしてみます。

\documentclass{jarticle}
\DeclareFixedFont{\test}{OT1}{cmtt}{m}{n}{12}
\pagestyle{empty}
\begin{document}

\fontsize{10}{15}\selectfont
\test(1) JY1/mc/m/n/10: \expandafter\meaning\csname JY1/mc/m/n/10\endcsname\par
\test(2) OT1/cmr/m/n/10: \expandafter\meaning\csname OT1/cmr/m/n/10\endcsname

\fontsize{9.5}{15}\selectfont
\test(3) JY1/mc/m/n/9.5: \expandafter\meaning\csname JY1/mc/m/n/9.5\endcsname\par
\test(4) OT1/cmr/m/n/9.5: \expandafter\meaning\csname OT1/cmr/m/n/9.5\endcsname

\fontsize{11}{15}\selectfont
\test(5) JY1/mc/m/n/11: \expandafter\meaning\csname JY1/mc/m/n/11\endcsname\par
\test(6) OT1/cmr/m/n/11: \expandafter\meaning\csname OT1/cmr/m/n/11\endcsname

\fontsize{12}{15}\selectfont
\test(7) JY1/mc/m/n/12: \expandafter\meaning\csname JY1/mc/m/n/12\endcsname\par
\test(8) OT1/cmr/m/n/12: \expandafter\meaning\csname OT1/cmr/m/n/12\endcsname

\fontsize{30}{15}\selectfont
\test(9) JY1/mc/m/n/30: \expandafter\meaning\csname JY1/mc/m/n/30\endcsname\par
\test(10) OT1/cmr/m/n/30: \expandafter\meaning\csname OT1/cmr/m/n/30\endcsname

\end{document}

をタイプセットすると、

(1) JY1/mc/m/n/10: select font min10
(2) OT1/cmr/m/n/10: select font cmr10
(3) JY1/mc/m/n/9.5: select font min10 at 9.5pt
(4) OT1/cmr/m/n/9.5: select font cmr9
(5) JY1/mc/m/n/11: select font min10 at 11.0pt
(6) OT1/cmr/m/n/11: select font cmr10 at 10.95pt
(7) JY1/mc/m/n/12: select font min10 at 12.0pt
(8) OT1/cmr/m/n/12: select font cmr12
(9) JY1/mc/m/n/30: select font min10 at 30.0pt
(10) OT1/cmr/m/n/30: select font cmr17 at 24.88pt

となります。

何をしているのかというと、デフォルトの状態で、\fontsize で具体的なサイズ指定をしたときに、mc/m/n と cmr/m/n で実際にロードされる tfm とそのサイズが何であるのかについて調べてみました （つまり、\DeclareFontShape の設定がどのように反映されているかの確認です．ここで、“\test” は、処理結果の出力を 12 pt の cmtt に揃えているだけです）。

※ サイズ代替が起きた場合には、log にその旨の Font Warning が書かれています。

なお、オプティカルサイズの例ではありませんが、ひとつの NFSS の組み合わせに対してサイズに応じてロードする tfm を変えている面白い例としては、乙部厳己先生の tumegumi.sty があります。その中核部分のみを抜き出してみますと、

\DeclareFontShape{JY1}{msmc}{m}{n}{%
     <-17> msmin
     <17-> mspmin
     }{}

のように宣言されていて、msmc/m/n について、17 pt 未満では、MS 明朝が使われ、17 pt 以上だと MSP 明朝が使われるという風になっています。17 pt というのは、本文が 10 pt のときの \LARGE に相当するサイズで、それ以上のサイズの場合には、自動的に MSP 明朝に切り替えて詰め組みを行う、という設定になっています。

Added: October 11, 2012; Last modified: Oct 15, 2012.

home