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

Made field origin configurable #8

Closed rosshadden closed 5 years ago

rosshadden commented 5 years ago

Fixes #7.

coveralls commented 5 years ago

Coverage Status

Coverage remained the same at 91.304% when pulling 32d0e985471569b5f3440996c2ddbdbfedee2e21 on whitebox-co:feature/configurable-field-origin into 403ed11d2c798607602d80cb9d03601ed0b7e805 on kylemacfarlane:master.

coveralls commented 5 years ago

Coverage Status

Coverage remained the same at 91.304% when pulling 32d0e985471569b5f3440996c2ddbdbfedee2e21 on whitebox-co:feature/configurable-field-origin into 403ed11d2c798607602d80cb9d03601ed0b7e805 on kylemacfarlane:master.

kylemacfarlane commented 5 years ago

Declined for the same reasons as #5.

optikalefx commented 5 years ago

What is the reason for the denial? I don't see anything in #5 about it. You reference your comment about the ZPL, but it's not overridable. So without configuration options, and without overriding the ZPL, the only option is fork the repo. I must be missing something.

kylemacfarlane commented 5 years ago

There are many reasons.

1) This is a project for debugging GRF rasters from CUPS. It is not a "printer driver" and the printing code only exists to test the rasters. There is no need to customise the origin.

2) The official Apple and Zebra rastertolabels always use 0,0. If you can convince either of them to update their filters then I'll consider it but most likely they will blame your printer's state.

https://github.com/steveathon/cups/blob/master/filter/rastertolabel.c#L624

https://sourceforge.net/p/zebratechcups/code/HEAD/tree/trunk/filter/rastertolabel.c#l691

3) For you it's just ^FO but for the next person it's ^LH, then the next wants the ^C* commands, etc. If even Zebra hasn't seen the need to offer these options in their official filter for the last 18 years why should I open that can of worms?

4) By adjusting the origin you are effectively setting a margin which begins to defeat the whole purpose of using rasters. Other thermal label languages such as Brother's are more explicit about this and will ignore margin settings when in raster mode (I have a private fork with Brother raster support so it'll make more sense in that context). It also destroys portability (which will be why Apple and Zebra stick to 0,0) and it's much better to always print to 0,0 and fix minor alignment issues by calibrating each individual printer in their LCD options (they will all be slightly different, even the same models).

https://www.zebra.com/us/en/support-downloads/knowledge-articles/printing-in-incorrect-location-on.html

https://www.zebra.com/us/en/support-downloads/knowledge-articles/adjusting-left-position-and-top-position-on-zebra-barcode-printers.html

5) The ZPL is easily customisable by subclassing it or using to_zpl_line() instead.