On macOS with Homebrew's argp-standalone, Findargp's link test for
argp_parse fails with an undefined strchrnul, because libargp.a itself
references that GNU extension and the platform has none. The module then
stops with "does not have a symbol named argp_parse", which is not what
is wrong.
Probe for strchrnul first (with _GNU_SOURCE, so glibc answers correctly).
Where it exists, the test is unchanged. Where it is missing, run the same
argp_parse test with a local definition of strchrnul, and have ptouch-print
supply that definition for the real build.
On glibc nothing changes: the probe finds strchrnul and the original test
runs. Checked on Debian stable in the same session.
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
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).