マクロツイーター

はてダから移行した記事の表示が崩れてますが、そのうちに直せればいいのに(えっ)

埋め込むか、埋め込まざるか、の補足

前回の記事「埋め込むか、埋め込まざるか」について、updmap の幻のオプション dvipdfmDownloadBase14 についての補足を追記した。

やはり dvipdfmx での Base14 フォントの埋込を制御する方法は TeX Live では用意されてなさそうだ。しかしここで別の方法を思い付いた。最近の dvipdfmx は dvips/pdfTeX 形式*1のフォントマップの読込にも対応している。だったら、pdfTeX の非埋込設定のためのマップファイルを使うと簡単なのではないか。そう考えて、次のコマンドを試してみた。

dvipdfmx -f pdftex_ndl14.map sample.dvi

結果は、エラーや警告は出なかったが、Times がビットマップになってしまった。意外な結果だったのでもう少し詳しく調査してみた。結論から言うと、dvips 形式のフォントマップ読込機能では、非埋込のマップ行は正常に処理されずに、当該の TFM のマップが存在しないと見做されてしまうようである。つまり、dvips 形式のマップを利用するというアイデアは残念ながら使えない。

確認作業

以下のテスト用の plain TeX 文書と dvipdfmx のマップファイルを用意する。

[test.tex]

\nopagenumbers
\font\fTest=pcrr8r \fTest
Hello, world!
\bye

この文書では Courier(pcrr8r)で文字を出力している。*2

[test.map]

%(1) native format, embed
%pcrr8r 8r ucrb8a.pfb
%(2) native format, no embed
%pcrr8r 8r Courier-Bold
%(3) dvips format, embed
%pcrr8r NimbusMonL-Bold "TeXBase1Encoding ReEncodeFont " <8r.enc <ucrb8a.pfb
%(4) dvips format, no embed
%pcrr8r Courier-Bold "TeXBase1Encoding ReEncodeFont " <8r.enc

このマップファイルでは、標準の Courier の TFM にわざと太字の Courier-Bold の物理フォント(埋込の場合はクローンの NimbusMonL-Bold(ucrb8a.pfb)を用いた)を対応させている。その対応を表す 4 通りのマップ行を書いているが、今はどれもコメントアウトされている。

これについて次のコマンドを実行する。

tex test
dvipdfmx -vv -f test.map test

この際に、dvipdfmx の端末出力の中に以下のような行が含まれている。これは pcrr8r の TFM のマップ先を示している。

fontmap: pcrr8r -> ucrr8a.pfb(8r.enc)

今回の実験では、4 種類のマップ行をそれぞれ有効にした時に、このマップ先がどうなるかと結果の PDF ファイルでのフォントの埋込の状況を調べた。

結果は以下の通り。

マップ行マップ先フォント埋込状況
無しucrr8a.pfbNimbusMonL-Regu(Type1)の埋込
(1)ucrb8a.pfbNimbusMonL-Bold(Type1)の埋込
(2)Courier-BoldCourier-Boldで非埋込
(3)ucrb8a.pfbNimbusMonL-Bold(Type1)の埋込
(4)pcrr8rビットマップ(Type3)の埋込

すなわち、埋込の場合は、dvips 形式の行 (3) は dvipdfmx 形式の行 (1) と同じ働きをするが、非埋込の場合は dvips 形式の行 (4) は dvipdfmx 形式の行 (2) と同じにならない。ビットマップフォントとして扱われるというのは、マップ行が非指定の場合の挙動と一致する。従って、行 (4) が「無効な記述」と見做されて pcrr8r に対するマップ行が消滅してしまったという可能性が高い。

*1:pdfTeX の用いるフォントマップの書式は dvips のものを若干拡張したものである。以下では単に「dvips 形式」と記す。

*2:8r エンコーディングのフォントを直接用いているわけでだが、ASCII 文字のみなので書いたままの文字列が出力される。