The POS895 logo printed with a white line under every band. Root cause is
in PrintImageBitModeAsync, not in the adapter: between slices it advances
with a bare LF, which moves the paper by the CURRENT line spacing rather
than by the slice height. ESC @ leaves that spacing at 1/6 inch, about
33.8 dots at 203 dpi, so each pass painted 24 dot rows and then advanced
~34, leaving a ~10 dot gap. The code assumed LF advances exactly one
slice; nothing ever made that true.
Confirmed on hardware before changing anything: printed two identical
solid 576x96 blocks, one at default spacing and one after ESC 3 24. The
first came out striped, the second solid.
Fixed by setting the spacing to the slice height for the duration of the
image and restoring the default in a finally. The restore matters as much
as the fix - leaving it at 24 would compress every following line of text,
turning a logo defect into a whole-receipt one.
Fixed here rather than in POS895 because the assumption is wrong for any
caller of this method. Blast radius is nil: PrintImageBitModeAsync has no
other production consumer, since TM_T30IIITranslated uses the raster path
and TM_U220IITranslated.PrintImageAsync is an empty stub.
Three regression tests drive a real EpsonPrinter against a loopback TCP
listener and assert on the wire bytes: ESC 3 <sliceHeight> before the
first ESC *, ESC 2 after the last, and the spacing tracking the mode
(ESC 3 8 for 8-dot) rather than a hardcoded 24. All three failed before
the fix.
Verified on the printer: the logo now prints solid.
Claude-Session: https://claude.ai/code/session_01E6N3P4nSZLtp4BC2LXVref
