dvipdfm-cjk に移行しました。 dvipdfm-cjk ではより完全な日中韓サポートを目指して時々活動を行なっています。
具体的には
などをやってみようかと思っています。 現在、六割くらい完了したといったところでしょうか。現在は CJK になりました。
まだ試験的なものです。 いろいろな状況でテストをして、問題が生じた場合は報告して頂きたいと思います。 Adobe Acrobat をお持ちの方は生成される PDF ファイルのサイズなどを比較して結果を報告して頂けるとありがたいです。
ソースは dvipdfm-cjk のページ から取得して下さい。
日本語パッチからの変更点:
CID フォントの埋込みをサポートします。 比較的取り扱いやすい CFF/OpenType*1 のものに限ります。 また、Type 2 Charstring*2 のみがサポートされますが、 現在入手可能な OpenType フォーマットの CID フォントのほとんどは利用可能です。 Adobe の Heisei、小塚やヒラギノなどはおそらく大丈夫でしょう。 今後は CFF/OpenType で Type 2 Charstring のものが主流になると思われるので、 これ以外のものはサポートする予定はありません。
TrueType フォントの埋込みをサポート (CIDFontType 2*3 として) します。
文字コードはすべて Identity エンコーディング*4 になるように変換されます。 Identity エンコーディングに変換するので CMap リソースをインストールしていないような環境でも、 フォントが埋め込んであれば表示できる (はず) というメリットがあります。 リソースを用意することで特定のエンコーディングや文字集合に縛られることは (2 バイトで足りる範囲では) なくなります。
predefined フォントに中・韓フォントをいくつか (Acrobat Reader 用に Adobe が配布しているもの) 加えました。 中・韓 TrueType フォントを埋め込むための設定も加えてあります。 Omega の level-0/level-1 OFM や Ascii pTeX の JFM を利用する DVI ファイルを処理できます。
注*1: CFF とは PostScript Type 1 フォントをコンパクトに表現するために Adobe が開発したフォーマットで、 CFF データを内部にもつ OpenType (Adobe と Microsoft が提唱する TrueType の 後継フォーマット) フォントをここでは CFF/OpenType と表記します。 CFF/OpenType フォントは通常はファイル名に拡張子 .otf がつき、 ファイルの先頭の 4 バイトが 4F 54 54 4F (OTTO) になっています。 OpenType の CID フォントはすべてこれになります。 CFF/OpenType フォントは PostScript Type 1 フォントとフォント・メトリック情報をひとまとめにして、 さらにテキストレイアウトなどに必要な情報をくっつけたようなものになります。
注*2: Charstring とは字形を記述する PostScript プログラムを特別な方法でエンコードしたバイト列です。 Type 2 Charstring は従来の PostScript Type 1 フォントでもちいられていた Type 1 charstring を拡張する形でより合理的で無駄のないものにしたものです。
注*3: CIDFontType 2 CID フォントは TrueType フォントを CID フォントに見せかけて使うためのもので、 中身は元の TrueType フォントとほとんど違いはありません。 CID フォントとして PostScript プログラムや PDF で使うために必要な付加的な情報を付け足したりしています。
注*4: 文書中の文字列で使われる文字コードが CID と等しくなるようなエンコーディングです。 Identity-H (横) と Identity-V (縦) があり、 どのような文字集合のフォントに対しても利用可能です。
OFM に対するフォントマップが指定されていないと (PK フォントから Type 3 フォントを作ろうとする) 落ちるようですが、私のバグではないので手を付けていません。
CFF/OpenType CID フォント、TrueType フォント共に埋め込みが許可されているかどうかチェックはしますが、 フォントのライセンスには充分注意して下さい。 OpenType フォントと Windows や OS/2 用に作られた TrueType フォントには OS/2 テーブルと呼ばれるデータにフォントのライセンスに関する情報が記載されています。 埋め込みが行なわれるのは、 Installable embedding, Editable embedding および Preview & Print embedding の設定になっているものだけです。 Preview & Print embedding のフォントがある場合は
** NOTICE: This document contains `Preview & Print' only licensed font **
というメッセージがでます。 この場合、フォントの使用承諾書などで許可されていない限りは生成された文書を不特定多数の人間に配布したりしないで下さい。 OS/2 テーブルを持たない Mac 用の TrueType フォントはサポートされません。 TrueType フォントの埋め込みは Windows 用につくられたそれほど古くないものであれば大丈夫だと思います。
私はプログラミング、フォント、`文字' に関することその他に精通しているわけではないので奇妙な部分があるかもしれません。 Warning に注意して下さい。
基本的な利用方法は dvpdfm-cjk 附属の README や FONTMAP を参照して下さい。
CMap は少なくとも H がないと動きません。フォントマップ・ファイルは jpatch のものと互換性がありませんので注意して下さい (FONTMAP を参照)。
適切な OFM ファイルと CMap リソース (UniJIS-UCS2-H など) が必要です。 例えば omrml という名前の OFM を使う場合は、cid.map に
omrml UniJIS-UCS2-H Ryumin-Light
と書いて下さい。UniJIS-UCS2-H は UCS2 (Unicode) から CID (Adobe-Japan1) へのマッピングを記述した CMap リソースです。この CMap を使って DVI の内部コード (今の場合は UCS2) を CID (Adobe-Japan1) へ変換します。 中国語や韓国語をつかうには Unicode 用の CMap をそれぞれ用意して下さい: UniCNS-UCS2-H (中国語・繁体字)、 UniGB-UCS2-H (中国語・簡体字)、 UniKS-UCS2-H (韓国語) などです。
ttf2pk などで利用される sfd ファイルが必要です。 CID フォントにマップするにはフォントマップで
min@SJIS@ 90ms-RKSJ-H :0:kochi-mincho.ttf
のように記述します。@SJIS@ は sfd の指定で、この例では SJIS.sfd
の記述に従い、min01 .. min45 の subfont を Shift-JIS
エンコーディングのフォントにまとめあげています。
Shift-JIS に対応する CMap、90-ms-RKSJ-H が指定されていることに注意して下さい、
最終的には 90ms-RKSJ-H に従って文字コードは Adobe-Japan1 の CID に変換されます。
TrueType フォントを利用するには、通常の CMap に加えて CID から Unicode などへ変換するための特別な CMap が必要です。 日本語の場合は Adobe-Japan1-UCS2 や Adobe-Japan1-90ms-RKSJ などがあれば充分でしょう。
補助漢字 (JIS X 0212-1990) は Adobe-Japan1 に含まれる常用漢字とは別の文字集合 (Adobe-Japan2) に収められています。 補助漢字を使う場合は、 aj20.tar.Z に含まれる CMap (Hojo-H など) が必要です。 また、MS 明朝などの TrueType フォントを利用する場合は aj20.tar.Z に含まれる cid2code.txt から mkcmap (perl スクリプト) を使って Adobe-Japan2-UCS2 という名前の CMap リソースを生成します。 アーカイブ aj20.tar.Z の中から cid2code.txt を取り出し、
% perl mkcmap cid2code.txt
として下さい。Adobe-Japan2-UCS2 というファイルができます。
CMap リソースをインストールしたら、cid.map に
hjm Hojo-H :0:msmincho hjmv Hojo-V :0:msmincho
のような記述を加えます。
JIS78 + NEC 拡張外字を使いたい場合は Ext-H (Adobe-Japan1) を使います。
DVI は JPEG や PNG などのいわゆる画像フォーマットとは異なり、 PostScript や PDF と同類のページ記述言語に分類されます。
DVI はページ記述言語のなかでも非常に低水準のもので、256 個以下の命令を持ち、 これらはそれぞれ 1 バイトの数値 (opcode) に割り振られています。
DVI 命令は、以下のものから成り立ちます。 より詳しくは CTAN の dviware/driv-standard にあるドキュメントを参照して下さい。
special (opcode: 239-242)。
TeX の \special{} で与えられた内容が後に続く。
文字幅の情報は TFM から取得します (カーニングなどの処理は TeX が面倒を見ます)。 DVI ファイルはこれらの命令とそれが必要とする引数が並んだバイト列です。
special で与えられるものを除くとこれらはすべて
PostScript や PDF で定義されているオペレータで実現できます。
このため DVI から PostScript や PDF への変換は非常にうまくいきます。
詳しい情報は Adobe のサイト Technical Notes for Developers にある文書を参照して下さい。
もし PDF について全く知識がないのでしたら、 横浜工文社による `手書き PDF 入門' が良い出発点になると思います。 PDF の基礎概念が素早く理解できます。
dvipdfm は主に以下の部分から成り立ちます。
dvipdfm の日本語化は以下の部分から成り立ちます。
アスキー pTeX の縦組み対応のため pdfdev.c に若干大きな変更が必要でしたが、 ほとんどの部分は新しく付け足しただけです。 アスキー pTeX に関する情報は pTeX 附属のドキュメントを参照して下さい。
今は WMode が 1 (縦) の場合は GSUB テーブルの Feature list から vert タグのものを拾ってくるだけで Script や LangSys は見ていません。 JIS 78/83/90 などの切替えは WYSIWYG なものでの利用を前提としている (どのような異字体があるか列挙するだけ) ようなのでちょっと無理があります。