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.
Odd behavior in testing with my PT-H500: When printing with precut, and then printing the next label without precut, the next label still gets a precut. i.e. the label with the precut flag gets cut on both ends, even if the next label does not have this flag. The label after that works as expected.
I'm unsure if this is printer behavior or if it could be resolved by sending additional commands somehow (maybe resetting the flag).
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.
