Windows に入っている「Palatino Linotype」について、ec.enc を使って一連の作業を行って、Adobe Reader X で開くと……表示された！！((符号位置 18h と 1Ah に出力されているのは .notdef グリフである。本来 T1 でこの位置にあるグリフ（/perthousandzero と /dotlessj）はこのフォントは持っていない。すると普通に考えると TFM で未定義になり空白になるはずだが、実は otftotfm は「未使用の符号位置にリガチャを自動的に入れる」機能があり、本来のグリフがない個所が別のリガチャで置き換えられている。そしてその部分は dvipdfmx が未対応の /index???? 形式だからここでは出力されていないのである。興味のある人は pdfTeX で出力させてみよう。))
以下に書いたものは大間違いでした。（続編を読む）
これも、Adobe Reader 9 では表示されなかった。実は、私はこれまで、Palatino Linotype が上手くいかない原因は、「グリフ名の情報をもっていない*1」からだと判断していた。この場合、otftotfm は /uniABCD 形式のグリフ名を出力（修正後の）エンコーディングで用いるのであるが、そもそも本当はグリフ名は存在しないのだから「特別に対処する必要」があるはずで、それは pdfTeX では対応してても dvipdfmx ではダメねんだろうと考えていた。((同じ状況で、otftotfm は Unicode 文字のマップを持たないグリフに対して /index????? というグリフ名を割り当てる。こちらは本当に dvipdfmx は対応してないようだ。（pdfTeX は対応。）))でも、Adobe Reader X では表示されているということは、結局昨日述べたのと全く同じ現象であると判断すべきであろう。さらに、よく調べてみると、「M+ 1P」もグリフ名情報は持っていなかった。
ということは、昨日に述べた「欧文フォントなら大丈夫」というのも間違いだということになる。そして「IPAex明朝」（これも表示されない）は確かにグリフ名情報を持っていることを考えると、「グリフ名情報がないこと」が原因でもない。結局、「OpenType + .enc ファイル + dvipdfmx」が成功する十分条件が全く分からないということになる。悩ましい……。
*1:post テーブルの Version 値が 3.0 である。
