dvipdfmxの仕様についてお伺いさせてください。
下記のTeXソース（このメッセージの末尾）で，\char 3つで「T」「e」「X」と印字されますが（合計3zw），
文字送りがJFMと一致しませんでした。
VFはotfパッケージからお借りしたものです。
具体的には
===TeX ===
のように文字が詰まって印字されます
JFMでは3文字がそれぞれ1zwなので，
===T e X ===
となることを想像していました。
これはdvipdfmxの仕様でしょうか。
---
dvipdfmxのvf.cでは0xf2（LONG_CHAR）エントリの文字幅はskip_bytesで捨てており，
/* Skip over TFM width since we already know it */
skip_bytes (4, vf_file);
とあります（似たような箇所が複数箇所）。それ以降は私には追いかけられなかったのですが，結果的に3zw進んでいるので直接の原因ではないと思いました。
---
また，論点がずれますが，LONG_CHARエントリのSET2に続けてRIGHTを置いてもRIGHTは必ず無視されるようでした。
LONG_CHAR
SET2<XXXX>
RIGHT3<XXXXXX>
のような並びのときです。
---
さらに，
LONG_CHAR
SET2<XXXX>
SET2<1>
のように本来の文字の後ろにCID 1（空白）を付け足したVFを作ったところ，「TeX」という文字列が「右から左」に印字されるという現象もありました。dvipdfmxのlr_modeはデフォルトでは「右から左」なのでしょうか（RIGHTが効かないこととも関連がありますでしょうか）。
---
いずれにしろ，SET2で（同一フォントで？）非全角文字を連続で置いたとき，JFMの文字幅が1文字ずつ反映されないように思います（JFMの文字幅が反映されるほうが自然だと思います）。
また，VFにあるはずのRIGHT等（スキップ関連？）が無視される理由が分かりません（逆に通常の和文JFMで括弧などが正常に印字されることに対して合致しない挙動のようにも思いますが，頭がこんがらかってしまいました。
主なテストはTeX Live 2021で行い，メッセージ末尾のTeXソースはTeX Live 2023でも確認しました。mapファイルは「ヒラギノ」「リュウミン」1書体ずつで確認しましたが結果は同じでした（埋め込むOpenType依存ではなさそうです）。
TeX Live 2023 (Windows 11, ARM64):
e-pTeX 3.141592653-p4.1.0-230214-2.6 (utf8.sjis) (TeX Live 2023)
kpathsea version 6.3.5
ptexenc version 1.4.3
This is dvipdfmx Version 20220710 by the DVIPDFMx project team,
modified for TeX Live,
an extended version of dvipdfm-0.13.2c developed by Mark A. Wicks.
TeX Live 2021 (macOS Ventura, universal-darwin):
e-pTeX 3.141592653-p3.9.0-210218-2.6 (utf8.euc) (TeX Live 2021)
kpathsea version 6.3.3
ptexenc version 1.3.9
This is dvipdfmx Version 20210318 by the DVIPDFMx project team,
modified for TeX Live,
an extended version of dvipdfm-0.13.2c developed by Mark A. Wicks.
以下，TeXソースです。
---
% encoding: utf-8
\documentclass{jarticle}
\begin{document}
\parindent0zw
\font\f=cidjmr2-h at20pt
\f
===%
\char\jis"4448 % 槌 => T
\char\jis"4459 % 潰 => e
\char\jis"444C % 通 => X
===%
\end{document}
dvipdfmxの非全角幅のCID文字の扱い，VFの扱い
- Yoshihiro AOKI の投稿