名前: ZR 日時: 2007-04-23 22:25:16 IPアドレス: 59.140.98.*
>>47722 >'000から'040までの33文字が，'241から'252，'255から >'303までの33文字に置き換わっているようです。 その符号位置の変化は、remap で起こるものと同じなので、 たぶん、dvipdfm の不具合で何かの拍子に remap の機能が 間違って働いているのだと思われます。 >T2Aの場合はキーマップとの組み合わせも考えなければ 「キーマップ」というのは inputenc のことですか? ■ remap について dvipdfm(x) が Type1 フォントを扱う場合、フォントを "reencode" して (つまり T1 の cm-super だったら実際に T1 エンコーディング(の サブセット)であるフォントを内部で作って)埋め込んでいます。 だから PDF の描画命令中の文字列のコードは DVI と同じになっている (T1 なら emdash は 16h)普通です。 ところが、cmr10 等の伝統的な OT1 エンコーディングのフォントは さらに "remap" という操作が行われています。これは、DVI での 0〜20h のコードを PDF 文字列において 80h 以上の位置に移すというものです。 この場合、埋め込んだフォントのコードもそれに合わせる必要があります。 ・例えば、cmr10 の Delta(OT1:01h) を出力した場合: - remap 無: PDF 文字列中で 01h; 埋込フォントの 01h は Delta. - remap 有: PDF 文字列中で A2h; 埋込フォントの A2h は Delta. ・remap の指定は .map ファイルで行う。例えば: - remap 無: "cmr10 ot1 cmr10.pfb" - remap 有: "cmr10 ot1r cmr10.pfb -r" ot1r.enc では A2h に /Delta がある。 # W32TeX では "cmr10 ot1r -r" と書いてあってそれは上と同じ意味。 # ptetex3 では ot1r ではなく別の名前になっている。 この操作の理由は、古いソフトでは、0〜20h のコードの文字を文字出力 に使うと問題が起こったからだと記憶しています。
この書き込みへの返事：