The PT-E560BT stays busy about 2.2 s after even an 8 mm label, so the
1 second default timeout cannot succeed on a job sent straight after
another: printing five chained labels gives a strip carrying three of
them. ptouch-print reports the timeout and exits non-zero correctly every
time, but no amount of waiting helps when the default is below the
printer's fixed overhead.
Add a trailing min_timeout to the device table. Every other row keeps its
initialiser and gets 0, which resolves to the old default of 1; only the
E560BT carries a value. An explicit --timeout always wins.
Raising the global default would also be defensible: ptouch_getstatus()
returns as soon as the status arrives, measured 0.13 s with --timeout 30
against 0.14 s with --timeout 1, so a higher ceiling costs nothing on a
printer that is ready. But that is a judgement about printers I do not
have, so this keeps it to the one that was measured.
On the PT-P900W the print area is not centered on the 560-pin printhead:
its center sits at pin 272 rather than the head center (pin 280), a fixed
8-pin offset that is constant across all tape widths. Centering the raster
data on the head therefore prints ~0.5mm off-center (measured as a constant
~1mm margin delta across 12/18/36mm tapes, confirmed against the spec).
Add a pin_offset field to _pt_dev_info (0 = centered, the default for all
existing printers) and apply it in print_img. Set it to -8 for the
PT-P900Wc, which reproduces the spec left-margin exactly for every tape
width ((560-print_area)/2 - 8 = documented left margin).
Reference: Brother "Software Developer's Manual - Raster Command Reference,
PT-P900/P900W/P950NW", section 2.3.5 "Raster line" (per-tape left/right
margin and print-area pin counts for the 560-pin head).
https://download.brother.com/welcome/docp100407/cv_ptp900_eng_raster_102.pdf
Add the PT-P900Wc with a 560px printhead and 360dpi resolution, using the
P700 init sequence, PackBits raster, the print-information command and
precut support. Verified printing on 36mm laminated tape.
The existing 360dpi handling doubled the 180dpi tape widths, which is wrong
for wide tapes: the 180dpi values are clamped by those printers' 128-pin
printheads, not the true printable area. Add a separate px360 column with
Brother's documented print areas (36mm = 454px, confirmed on hardware; the
narrower widths are from the raster reference and untested) and clamp the
result to max_px so 360dpi printers with a narrower head (PT-9200DX) stay
safe.
Also add the udev uaccess rule for 2085.
Kevin Bradenstein