Hi,
According to the programming guide volume 2 the "~DGR:" is supposed to be equivalent to "~DG" as downloading to RAM is the default. Same about "^XGR:" = "^XG" and "^IDR:" = "^ID" (but there is no parsing error for "^IDR:" as this command is ignored). My guess (not a Java programmer) would be to replace in ParseZPL.jj:
< P_EG: "~EG" >
by:
< P_EG: ( "~EG" ("R:")? ) >
The problem is that the cups filters put the "R:" in the ZPL output. Removing them, with the help of your nice tool, clears the parsing error messages... but, alas the resulting graphic remains scrambled in the preview. It looks like there is another problem there. Do you support the "data compression" in the graphic data (with letters h...z and H...Z)?
Thanks
Pierre
Hi,
I created a perl script to fix the above issues. The idea is to filter the output of cups before loading the file into your zplviewer. It can then display the tag correctly.
Here comes the procedure:
Install a Zebra zm400 printer in CUPS as explained in https://www.zebra.com/content/dam/zebra/drivers/en/third-party/zsn108111-v3-en.pdf. Set for instance the default label size to 4x6.5", the resolution to 300dpi, the media tracking to Continuous, the media type to Thermal transfer.
Generate a pdf for the label printer (tag.pdf).
With the help of CUPS and an additional filter I wrote (labeltoviewer.pl), generate a zpl file out of it:
Last edit: Dehaen 2015-10-24
One additional note...
I would recommend to use the options "-o PageSize=Custom.4x3in -o fitplot" to the "cupsfilter" command, and to the "lp" when doing the actual print, because pdftops would otherwise insert your (3x4 inches in this example) pdf document into a letter-size page! The debugging of this explains why I added options to my filter to make the label borders visible...
Note that "Custom.10x7.5cm" or "Custom.288x216" (in points = 1/72") works as well.
I'm wondering if the cups default document settings are of any use as these options are anyway needed...
Last edit: Dehaen 2015-10-24