Phomemo のドライバーは、MPT-Ⅱのドライバーを採用してダミーデータを末尾に入れる方法を採用することにした。
当初はMPT-Ⅱドライバーでは印刷できなかったが、データ量が多い場合に印刷出来るが末尾が一定量印刷されない状況に気が付きダミーデータを入れる方法になった。
ESC/POSコマンド（全てではないみたい）が使えて、用紙節約機能も使えるのでダミーデータを多めに追加して最後に必要量をESC/POSコマンドで用紙送りする事で使い勝手が向上した。
ダミーデータの量は実際の文字データより大量に必要な事がわかっている。
（当初は目立たない罫線や点等を追加する方法も試したが、末尾に用紙節約で印刷されない白色データを追加する方法でなら見た目も変わらず使える事がわかった。）
文字では十行分の末尾が削除されるとした場合に、白色のボックスデータは明らかに多い量必要。
当初は、用紙節約機能で削除されるデータが1ドット分程削除されず残っているデータがダミーデータとなっているのではと思っていた。
しかし、ダミー量を倍増しても最後の用紙送量に変化は感じられなかった。
微妙な調整が不要で便利と思って、あまり深くは考えていなかった。
勝手にダミーデータと名付けているが、印刷データそのものが必要なのでは無さそう。
印刷用の何らかのバッファー領域にダミーで作られる、改ページコードのデータが必要なのでは？
おそらく、Phomemoのファームにはスマホからの印刷で使用されるバッファー領域が有りそこを改ページコードで埋めてしまう事で印刷出来ているのでは無いかと思う。
（印刷の実データ＋ダミーデータ）
がPhimemoに送られる際に、ドライバーの用紙節約機能により
（印刷の実データ）＋（改ページコード✖データ分の改ページ数）
となるのでは？
命令コードなので、バッファーを埋めるのに実データより大量な（アプリからの見た目上）データが必要なのでは無いかと思う。
課題と対策_φ(･_･
DPI値が異なるので印刷範囲可能範囲が変わって（端が印刷されない等）しまうかと思ったが変わらず印刷できた。
実際の印刷物は、おおよそ0.8倍となるので拡大印刷の設定と組み合わせればエクセル等のアプリから意識せずに実寸調整出来るはず。
ハードウェア的には一般的なレシートプリンタと、さほど変わっていない様にみえるがスマホから簡単に画像印刷出来るようにしたファームウェアがWindowsドライバー（勝手に使用している）との組み合わせで独特の動作をしている要因なのだろうと思われる。
なんとなく思っていたが、ファームの命令バッファーがダミーデータと関連していると仮定しておけば今後の対応・対策ができそう。
2025/11/12 追記 バッファーの仮説は間違い。
カスタム用紙長を調整していた際に、ダミーデータ量が増減しているので見当違い。（だと思う）
時々整理しないと忘れるが、印刷手順確率しつつ有るので忘れても良いかも(・・?
