lprint submit -n option ignored for Dymo LabelWriter 450

[ribbons]

The -n (number of copies) command line option for lprint submit currently appears to be ignored when printing to my Dymo LabelWriter 450. For example, the following command results in a single label being printed for me instead of the two copies specified:

lprint submit -o print-scaling=fill -o media=oe_lg-address-label_1.4x3.5in -n 2 /tmp/JbrFFQQ9m1.png

If my quick skim-through the relevant code for lprint and pappl is correct, my understanding is that the value is parsed by the pappl submit code and stored in the options struct but then not checked by the Dymo driver implementation in lprint-dymo.c (in contrast to lprint-zpl.c which does send the value to the printer). The LabelWriter technical reference manual doesn't appear to mention a printer command for requesting multiple copies (at least to my untrained eye), so it doesn't appear to be a case of passing this along to the printer to handle natively.

My reason for raising this issue instead of submitting a PR to fix this is I'm not entirely sure what or where the correct fix should be as there appear to be several potential solutions:

• The Dymo-specific driver code could repeatedly send each label as many times as requested
• pappl could have some more generic code to avoid having to implement that functionality for many types of printer
• The copies flag could be rejected as invalid by the pappl submit code for printers not supporting multiple copies natively

[michaelrsweet]

This should be working - if the printer doesn't natively support copies (which is most printers) then PAPPL will loop to produce them. Will see if maybe I have the wrong driver settings in the DYMO driver.

[michaelrsweet]

I wasn't able to reproduce with the Dymo driver, but the ZPL driver was producing N^2 copies so I fixed that:

[master 4b63276] Fix number of copies produced by the ZPL driver.

[ribbons]

Odd that you weren't able to reproduce it but the good news is that the fix for michaelrsweet/pappl#312 resolves the issue for me so it turned out to be a PAPPL bug in the end.