えー、要するに
dvipdfmじゃなくてdvipdfmxを使おう
という話。
……というと、「え、そんなの至極アタリマエじゃん」と思うかもしれない。そう、確かにそれがアタリマエなんだけど、しかし「何か特段の理由があって敢えて（dvipdfmx があるシステムで）dvipdfm を使う」という“裏技”は利用されていた。だけどそれも 2013 年頃以降は“封印”されているのである。端的にいうと、次の通り。
- TeX Live 2013（および同時期の W32TeX）以降の TeX 環境について、LaTeX + dvipdfm で graphicx（または graphics）パッケージを用いる時に、ドライバ指定を dvipdfm にするのは間違いである。もちろん、dvipdfmx や dvips にするのも間違いである。つまり、そもそも graphics/x パッケージを使うことができない。
以下では、その辺の事情について詳しく解説する。*1
dvipdfm が“使えない”話
事の顛末をまとめると、以下のようになる。
- 2007 年 5 月以降、dvipdfm と dvipdfmx は非互換となり、graphics/x 用のドライバも別になった。（参考）
- 2009 年（あたり）に W32TeX／TeX Live では dvipdfm が廃止になった。代わりに、dvipdfm というコマンドを実行すると、dvipdfmx が「互換モード」で起動する。
- 画像読込の非互換な部分について、「互換モード」の dvipdfmx は dvipdfm の挙動を模倣する。したがって、“dvipdfm”を使う場合の graphics/x のドライバは以前と同じく dvipdfm 用のもの（dvipdfm.def）を使うのが正解であった。
- 2013 年の W32TeX／TeX Live では（以前から続いていたある不具合を解消する目的で）EPS 画像の読込における Ghostscript との連携処理が変更された。具体的には、Ghostscript の呼出で「-dEPSCrop」というオプションを指定するようになった。これに整合させるためにドライバの実装も改修された。（参考）
- ところで、Ghostscript の呼出のコマンドラインが書かれているのは、dvipdfmx の設定ファイルの dvipdfmx.cfg である。この設定ファイルに「-dEPSCrop」が使われているならば、当然、ドライバファイル dvipdfmx.def の実装も「-dEPSCrop」に対応した新しい版である必要がある。もちろん、TeX 配布においてはこの 2 つは整合する版が配置されているので、dvipdfmx に関しては問題がない。
- ところが、dvipdfm では問題が起こる。この時点の dvipdfm は実体が「dvipdfmx の互換モード」であるため、設定ファイルとして（dvipdfm.cfg ではなく）dvipdfmx.cfg を読む。ここには「-dEPSCrop」が書かれているため、graphics/x のドライバ dvipdfm.def はそれに対応したものである必要がある。ところが、「-dEPSCrop に対応した dvipdfm.def」は作られなかったのである。
- もちろん、「互換モード」の dvipdfm では dvipdfmx と挙動が異なるので、dvipdfmx.def を使うことも（従来通り）できない。
- 2009 年で「本物の dvipdfm」を廃止したのは、「dvipdfm を obsolete と扱う」意図があったのだろう。つまり、“偽物”の dvipdfm を用意したのも一種の“経過措置”であり、既に 6 年が経過しているので、もはや dvipdfm を残存させることを止めたのであろう。実際、TeX Live 2013 では、整合しなくなった dvipdfm.def を削除している。
- “偽物”の dvipdfm は現在（2015 年）でも（何故か）存在している。しかし、適合するドライバが存在しないため、少なくとも graphics/x パッケージを利用することはできない。それゆえほとんど使い物にならないといえる。*2
- “敢えて dvipdfm を使う裏技”の目的として「dvipdfmx のバグを回避する」というものがあった。しかし、“偽物”の dvipdfm は実体が dvipdfmx であるため、恐らくこの目的は果たせないだろう。つまり、この目的での“裏技”は 2009 年に既に封印されていたわけである。
それでも dvipdfm したい場合は
果たしてそんな需要があるのは知らないが、現状において可能な対策を挙げておこう。
- 実は、W32TeX には今でも本物の dvipdfm が「dvipdfmo」という名前で残っている。これが読む設定ファイルは dvipdfmo.cfg で、ここでの Ghostscript のコマンドラインは「-dEPSCrop」の入る前のものである。そして、昔のままの dvipdfm.def も残っている。従って、graphic/x のドライバオプションを“dvipdfm”にして、DVI ウェアのコマンド名を“dvipdfmo”とすることで、「本物の dvipdfm」を機能させることができる。
- 特に“dvipdfm の仕様”が必要なのではなく、単に“dvipdfm”というコマンド名で DVI ウェアが起動できればよい、という状況であれば、“dvipdfm”で本来の（互換モードでない）dvipdfmx が起動するようにすればよい。dvipdfmx のプロセスのコマンド名が“dvipdfm”になる（これだと互換モードになる）のを防ぐため、シェルスクリプト等を利用すればよいだろう。もちろんこの場合の graphics/x のドライバは“dvipdfmx”にする。
- dvipdfmx.cfg を「-dEPSCrop」が入る前の昔のものに差し戻して、かつ昔の dvipdfm,def を復活させると、“偽物”の dvipdfm（+ dvipdfm ドライバ）が使えるようになる。ただしこの場合、本来の dvipdfmx（+ dvipdfmx ドライバ）が不整合となって使えなくなってしまう。
- 頑張って「-dEPSCrop に対応した版の dvipdfm.def」を開発すれば、“偽物”の dvipdfm と本来の dvipdfmx を両立させることができる。どうしてもソレが必要であるなら、観念して TeX 言語しよう。
蛇足事項
- 今手元にある dvipdfm が“本物”か“偽物”（dvipdfmx の互換モード）かを見極めるには、「
dvipdfm --version」を実行してみればよい。現れるメッセージが、This is dvipdfmx Version ...
から始まっているのなら、ソレは dvipdfmx、つまり偽物である。((本物の dvipdfm の場合は--versionオプションがないので、多分ヘルプ画面が出ると思う。)) - W32TeX／TeX Live に含まれている（いた）dvipdfm は日本語対応拡張が施されたもの*3なので、pTeX の出力する DVI ファイルを扱える。しかし、日本語（CJK）対応の仕様は“拡張版 dvipdfm”と今の dvipdfmx では大きく異なっている。特に、「dvipdfmx 用の」和文フォントのマップファイル（TeX Live の ptex-ipaex.map など）は dvipdfm では使えない。すなわち、
dvipdfm -f ptex-ipaex.map test.dvi
のようなのはナンセンスである。（“偽物の dvipdfm”ではこれが通ってしまうので要注意。）
