36eab4b4b2
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
