最近，Windows上のW32TeXでVFを作ってみた所，いままでうまくいっていたものが，うまくいかなくなることに気付きました．
原因を調べてみた所，ovp2ovfのVer. 2.1で，
MAPFONT D 0
のエントリがないVFを作成しようとすると，MAPFONTの番号がずれるようです．
UTF/OTFパッケージのVFを作成するmkjvfというスクリプトで，まさにこのようなVFを作成していますので修正しました．
現在，expertオプションを使用した状態でdvipdfmxでPDFを作成する際にFONT IDに対する警告が出ないようなら，インストールし直す必要はありません．
よろしくお願いいたします．
>ovp2ovf: MAPFONT の番号が常に 0 からの連番だと解釈される
これが原因だと思われます．
(MAPFONT D 1
(FONTNAME rml)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
(MAPFONT D 2
(FONTNAME gbm)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
のようなovpからovfを作成すると，
(MAPFONT D 0
(FONTNAME rml)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
(MAPFONT D 1
(FONTNAME gbm)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
として作成したものと同様なovfが作成されますが，
CHARACTERの中のMAPエントリの(SELECTFONT D 2)となっている箇所はそのままですのでFONT ID 2が無いというエラーがでます．
「連番だと解釈される」ということはMAPFONTで0, 3, 5となっている場合，0, 1, 2にされるのですかね．
UTF/OTFパッケージについて，明日以降，もう少しちゃんと検証してみます．
これが原因だと思われます．
(MAPFONT D 1
(FONTNAME rml)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
(MAPFONT D 2
(FONTNAME gbm)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
のようなovpからovfを作成すると，
(MAPFONT D 0
(FONTNAME rml)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
(MAPFONT D 1
(FONTNAME gbm)
(FONTCHECKSUM O 0)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)
として作成したものと同様なovfが作成されますが，
CHARACTERの中のMAPエントリの(SELECTFONT D 2)となっている箇所はそのままですのでFONT ID 2が無いというエラーがでます．
「連番だと解釈される」ということはMAPFONTで0, 3, 5となっている場合，0, 1, 2にされるのですかね．
UTF/OTFパッケージについて，明日以降，もう少しちゃんと検証してみます．