search

kylemacfarlane / zplgrf

Python utilities for converting to and from ZPL, GRF, PDF, and images
GNU General Public License v3.0
52 stars 11 forks source link

a few new handy options #4

Closed nubirstein closed 5 years ago

nubirstein commented 5 years ago

a) 'destination' option instead of hardcoded R: in the generated ZPL code b) possibility to pass a PIL.Image object to the 'from_image' function c) possibility to generate GRF without a ^XA...^XZ section (Such a ZPL has an effect of uploading GRF to the printer, without printing anything) d) unit tests extended to cover new functionalities e) examples updated in the README file;\ f) 'venv' added to .gitignore, for those who use classic python virtual environment approach

coveralls commented 5 years ago

Coverage Status

Coverage increased (+0.1%) to 91.453% when pulling b006e5235d222c80853ed70c183042c36ad81fc4 on nubirstein:printer_destination_flexibility into 825d9c6ce1b380b826b62661f495af4849da99e5 on kylemacfarlane:master.

kylemacfarlane commented 5 years ago

Since this is primarily a project to debug CUPS output every deviation from CUPS is a bad thing.

to_zpl() is purposefully simple and only implements options available in CUPS' rastertolabel or Zebra's official fork over on Sourceforge. For any other options you should subclass it. Forks from other "emulator" manufacturers like say Citizen or Brother are a bit of an edge case but so far I haven't even implemented features I use. ~PQ is a bit of an exception since those features aren't handled in rastertolabel but they are options elsewhere in CUPS.

load_image_only is redundant as the feature already exists as to_zpl_line().

image_object causes inconsistencies. Why not allow passing file like objects into from_pdf() or from_zpl() as well? Then you get into the problem of what if they're custom objects streaming from S3 and that adds more variables into your debugging. Best to just send the bytes in and let the internals handle it.

I've been asked to support loading all the ~DG and ~DY commands before but then they come back and ask me to add a huge list of other commands when they realise the size of their problem. Keeping it as ~DGR keeps the tight coupling with the fact that it's only meant to load CUPS output and that this project is not a ZPL renderer.

The only purposeful break from CUPS is the compression options but those were required to load the output from a Windows driver so I could compare it to the CUPS filter to figure out what was wrong with barcodes on Linux and OSX.