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.
The raster packet buffer was fixed at 64 bytes, but a full raster line is
max_px/8 bytes plus up to 4 header bytes. For printers with a printhead
wider than 480px this overflows the buffer and smashes the stack. No
previously supported printer was wide enough to trigger it (the widest,
PT-9200DX at 384px, needs 52 bytes), but a 560px printhead needs 74.
Size the buffer to 128 bytes, which is the maximum a single packet can be
since ptouch_send() caps transfers at 128 bytes.
Brother's software may default to 0x0e, but that probably assumes you're making text labels and not printing images. For printing images you might want borderless (we certainly do), and for text labels you can always add the margins to the label before printing.
This commit uses 1px length margins instead of 0 to prevent some leftover black on the edges of the next print.
With this change my P700 produces about 2cm of waste tape followed by
the desired label, with no additional padding.
As far as I know all of these printers have a cutter, so I am not sure
what determines which modules should have this flag set -- perhaps some
of them can cut at the end of a label only, not at the beginning?
We could perhaps have a commandline option to disable precut.
Kevin Bradenstein