OpenPrinting
Add "direct graphics" mode for Zebra ZPL printers.
This mode uses the ^GF ZPL command to directly emit graphics into the printer's raster buffer, rather than storing the page raster into an on-device ZPL graphic, then emitting that graphic into the buffer later. Some printers (at least the ZP888/ZD120, possibly others) do not have sufficient onboard memory to store and recall an entire label's worth of graphics, causing prints on those devices to fail using the existing filter driver. This "direct mode" driver works on such printers.
Hi Justin,
thank you for the PR!
The intention to support a new mode in CUPS seems fine, however it concerns printer drivers, which are deprecated in CUPS for long time and its support will be removed in the near future. As for common label printers which don't support any driverless standard there is the LPrint project, so it would be great if you adjusted and sent the feature for LPrint as well (in case the mode makes sense to add in LPrint).
Ad PR itself - please check DEVELOPING.md - the PR contains some changes which are only because of different spacing, so it would be great if you cleaned up those. I haven't spotted any 'obvious to me' C issues.
@michaelrsweet Mike, would you mind reviewing the PR from technical point of view once you have a time?
OK, so from a technical perspective I am hesitant to change anything in the CUPS rastertolabel driver, both because drivers are deprecated and because I've moved development of this driver over to LPrint.
Some specific feedback:
- This driver has been in use for 20+ years, and this is the first time we've had anyone report issues with memory limits like this. The memory requirements are not high (128k to support 4x6 labels at 203 dpi) and ZPL supports vector graphics.
Memory issues were only my hypothesis here. After a bit more investigation, it seems that the ZP888 only supports a very small subset of ZPL. This doesn't surprise me - the ZP888 is designed as a super-cheap Zebra desktop printer for the Chinese market, with a sales price of around $100.
Even catting out a super-basic "Hello, world!" ZPL script directly to /dev/usb/lp1 does nothing, so it's entirely possible that the ZP888 doesn't support vector graphics or any of the "fancy" parts of ZPL at all. I went down this path because I sniffed how the printer worked under Windows, and it was using ^GF instead.
The exact script I sent to the printer:
^XA
^FO50,50^ADN,36,20^FDHello, world!^FS
^XZ
All that happens when I send it is that the light on it blinks, but no label comes out.
- Knowing whether to use ZPL normal or ZPL direct printing mode is not something we want the user to have to know. If the direct mode works with all printers then my preferred solution would be to switch to it instead (more generic, better compatibility across the board)
I'll leave that decision to you - I split this out because I thought that tossing the driver code that's worked just fine for, as you say, 20+ years would be a bad idea considering I only have one Zebra printer to test with, and said printer seems to be an oddball in Zebra's line. This does seem to be a more compatible way of dealing with raster graphics, but there's some things that don't work (^PQ for copies, ^PO to have the label print bottom-edge first) that'll need to be dealt with elsewhere in the stack.
- IIRC (and I'll need to dig out my ZPL programming manual to verify) the direct graphics mode doesn't support copies, so we'd either need to change the PPDs to specify manual copy generation or buffer the page in memory in rastertolabel.
I tested this and you're correct.
- If we take this change, I think it should wait for CUPS 2.5. In the meantime I can also look into using this for LPrint as well.
I could take a cut at trying to port this logic to LPrint, although I've never used LPrint before, so it may take me a bit, and I can't guarantee my PR won't break other things there.
Regardless, I definitely want to test this extensively with the Zebra printers in my office. Unfortunately, I won't be back to my office until September...
No rush on this - I solved my immediate problem and I'm fine using a locally-patched version until this lands upstream. I just figured I couldn't be the only person to run into this.
One of my Zebra printers supports this, one doesn't... Not for CUPS 2.x, might consider as an enhancement for LPrint if we can auto-detect support.
