kpathsea については http://www.tug.org/kpathsea/ を参照して下さい。
実際に dvipdfm で生成された PDF ファイルを表示するとき、 素の Ghostscript 6.x, 7.0 や Ghostscript-6.x + VFlib パッチ + jpdf パッチ では
/undefined in /Hと言われて終了してしまいます。 これは H という名前の CMap (大雑把にいうとエンコーディング) を理解できないためです。 この場合、H という CMap リソースを追加する必要があります。
以下の手続きを行なって下さい:
pssystemparams begin /FontResourceDir (/Resource/Font/) readonly .forcedef % pssys'params is r-o /GenericResourceDir (/Resource/) readonly .forcedef % pssys'params is r-o /GenericResourcePathSep (/) readonly .forcedef % pssys'params is r-o endとなっている部分の /Resource を ${GS_RESOURCE_DIR} が指すディレクトリ名に置き換えます。
GNU Ghostscript 6.51 がでたことですし、 gs-cjk のことも考えると Ghostscript-6.x や 7.x へ移行すべきでしょう (pdfwrite の日本語対応は充分ではないですが)。
Ghostscript 6.x とそれ以前のものでは和文フォントはいわゆるビットマップフォントになります。
英語版の Acrobat Reader や Unicode に対応していないプラットフォームでは日本語で書かれた `しおり' を読む事はできません。
JPEG, PNG, PDF を取り込むにはあらかじめ dvipdfm 附属の ebb というプログラムで BoundingBox を記述したファイルを生成する必要があります。 例えば foo.jpg という JPEG 画像を取り込むには
% ebb foo.jpgとして (foo.bb が生成される)、LaTeX で
\usepackage[dvipdfm]{graphicx}
.....
\includegraphics[width=72mm,height=50mm]{foo.jpg}
.....
のようにします。
前もって graphics パッケージが dvipdfm に対応していることを確認して下さい:
% grep dvipdfm `kpsewhich graphics.sty`
\DeclareOption{dvipdfm}{\def\Gin@driver{dvipdfm.def}}
% kpsewhich dvipdfm.def
/usr/local/share/texmf/tex/latex/graphics/dvipdfm.def
もし対応していないのであれば、dvipdfm の配布物に含まれる dvipdfm.def
を graphics.sty がインストールされているところに置いて
graphics.sty に
\DeclareOption{dvipdfm}{\def\Gin@driver{dvipdfm.def}}
を追加します。
EPS は問題を生じやすいので PostScript (EPS) にあまりこだわらない方が良いでしょう。
取り込まれた画像は Linux 版 Acrobat Reader を 16-bit color で使っている場合に表示が乱れることがありますが、 これは Acrobat Reader のバグで dvipdfm の責任ではありません。
gnuplot の `PLUS-enhanced patch' を使う場合にこれを防ぐには、出力の前に
gnuplot> set locale ""として下さい。
日本語関連で問題が生じたら gs-cjk を試してみて下さい。
メッセージに
<PDF> Invalid PDF name "#82l#82r#83S#83V#83b#83N"がでる場合は # を通すパッチ (patch-pass-numbersign.diff) でなんとかなると思います。
PDF ファイルが
<< /Type /Page (略) /Contents [ (略) ] (略) >>のよう ([ (略) ] のところ) になっていたらいまのところダメです。 ページの内容を分割しないようにアプリケーション側で設定できるのでしたらうまくいく可能性があります。 あるいは、 Content streams をひとまとめにするパッチ (patch-concat-stream.diff) でなんとかなるかもしれません。
dvipdfm は独自の PDF パーサが PDF ファイルを処理して、 1 ページ目の内容を PDF の Form XObject として取り込むように試みます。 複雑な PDF だと取り込みに失敗するか、 壊れた PDF を生成してしまうかもしれません。
% mpost foo.mpとすると foo.n (n は 整数) をいう名前の PostScript ファイルが生成されるので、 これを foo.eps のような名前に直して普通に
\includegraphics{foo.eps}
として DVI ファイルを作ります。
あとは dvipdfm が自動で処理してくれます。
フォントは TeX のフォントと同じような扱いになるので、 図と本文のフォントをあわせたい方は特にお勧めです。
これはダウンサンプリングを全く行なわないためです。 ほかのアプリケーションで出力装置の解像度にあわせて画像の解像度を調節する必要があります。
いくつかのフォントに関する情報が必要です。 下の表を参考にしてフォントファイル (または AFM ファイル) から情報を取得して下さい。 TrueType/OpenType フォントでは得ることが困難なものもあります。
| Key | PostScript Type1 | TrueType/OpenType |
|---|---|---|
| Subtype | CIDFontType0 を与える | CIDFontType2 を与える |
| Ascent | AFM の 'Ascender' | 'OS/2' テーブルの 'sTypoAscender' |
| CapHeight | AFM の 'CapHeight' | `H' の高さを計る ? |
| Descent | AFM の 'Descender' | 'OS/2' テーブルの 'sTypoDescender' |
| Flags | Symbolic に必要に応じて Serif, Italic, FixedPitch などを加える程度でよい | Symbolic に必要に応じて Serif, Italic, FixedPitch などを加える程度でよい |
| FontBBox | AFM の 'FontBBox' | 'head' テーブルの 'xMin', 'xMax', 'yMin' および 'yMax' |
| FontName | AFM の 'FontName' などから | 'name' テーブルから |
| ItalicAngle | AFM の 'ItalicAngle' | 'post' テーブルの 'italicAngle' |
| StemV | Private Dictionary の '/StdVW' から | 大雑把な値は 'OS/2' テーブルの 'usWeightClass' から (usWightClass/65)**2+50 程度らしい |
TrueType/OpenType で長さを示す sTypeAscender, sTypeDescender, xMin, xMax, yMin, yMax は PDF のユニットに変換します。 TrueType での値 xTTF は 'head' テーブルにある 'unitsPerEm' の値から、 xPDF = 1000 * xTTF / unitsPerEm で変換されます。
その他に付加的なものですが、/Style に /Panose を加えることが推奨されます。 これがないとフォントの代用がうまく行なわれません。 いくつかのフォントでは、 ゴシックの場合は 0801 (Sans Serif, IBM Neo-grotesque Gothic) で、 明朝などの場合は 0105 (Oldstyle Serif, Dutch Modern) などで始まっているようです。 Windows 用 TrueType フォントの場合は 'OS/2' table にある 'sFamilyClass' と 'PANOSE' を連結してそのまま持ってくると良いでしょう。 私はよく分からないので、詳細は Microsoft の OpenType Spec. から見つけて下さい。
Ghostscript ではフォントの代用が自動的には行なわれないので注意して下さい。 多くの場合、Courier になって文字化けしてしまいます。 同じような環境間で文書をやりとりする場合にのみ有効です (特に Mac ?)。
フォントを埋め込みたい場合は `開発版' を取得して開発に協力して下さい。
Times 系フォントは TeX で標準的に利用される Computer Modern フォントと比べると線幅が一様で太いのか、 ディスプレイ上でよりはっきりと見えることが多いようです。 数式も使う場合で本文と数式中の文字の見た目をあわせたければ TX フォントを使うといいと思います。
使い方は以下のページを参照して下さい:
TeX 標準の Computer Modern はディスプレイ上では見づらい場合が多いと思います。
dvipdfm は PostScript Type1 や TrueType フォントを埋め込むと、 (他のアプリケーションと比べて) ファイルサイズが大きくなる傾向があります。
rml Ryumin-Light gbm GothicBBB-Mediumで使うと生成された PDF はうまく表示できなくなるそうです。
Acrobar Reader を使うのであれば、cid.map を
rml HeiseiMin-W3 gbm HeiseiKakuGo-W5にすれば (`Darwin-jp なページ' にあるものは既にこの修正が行なわれています) 見ることはできますが、今度は OS 附属のビューアで見れなくなるそうです。
ヒラギノのエントリも加えようかと思ったのですが、 フォントそのものがどういうものか分からないのでちょっと手がだせません。 Web 上で拾った PDF に埋め込まれていたものは Registry-Ordering (文字集合) が Adobe-Japan1 ではなかったのですが (判別不能な文字列)、 どうなっているのでしょうか。