Problem printing UPS label

[GoogleCodeExporter]

Using the UPS API to generate the EPL label.

I seem to have problem printing it using jzebra 1.4.5. It does not get printed 
out at all.

The problem seems to go away when I remove away the GW line, which is 
supposedly a Direct Graphics Write command.

Original issue reported on code.google.com by yuchouc...@gmail.com on 9 Nov 2012 at 8:51

[GoogleCodeExporter]

Attached a sample epl file that was generated.

Original comment by yuchouc...@gmail.com on 9 Nov 2012 at 9:17

Attachments:

• 1Z8E899F0392944378.epl

[GoogleCodeExporter]

Which printer are you using?  Does it support ZPL?

Original comment by tres.fin...@gmail.com on 9 Nov 2012 at 9:05

[GoogleCodeExporter]

I've 2 printers. 

One is the Zebra S4M (firmware updated to EPL) and another is 2844.

We're trying to maintain EPL so both printers can be use interchangeably.

Original comment by yuchouc...@gmail.com on 10 Nov 2012 at 3:51

[GoogleCodeExporter]

Is this issue similar to #34 or I need to get the latest 1.4.6?

Original comment by yuchouc...@gmail.com on 10 Nov 2012 at 4:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue 34 is for those generating their own EPL commands.  Since yours is sent 
from UPS, it's already in the correct format.

Can you get this file in base64 format too?  There's a chance the image data is 
just not handled well during the whole process since it's being sent in binary 
(open the file with wordpad and scroll to the bottom to see what I mean).

Base64 encodes the binary data to a format the web browser can handle.  This 
seems to fix most problems with binary data being interpreted incorrectly.

Also, what platform are you testing this on?  There could be some encoding 
problems if this is being used on Mac or Linux.  
http://code.google.com/p/jzebra/wiki/TutorialWebApplet#Printing_Special_Characte
rs (See setEncoding() section)

-Tres

Original comment by tres.fin...@gmail.com on 10 Nov 2012 at 6:02

[GoogleCodeExporter]

I've tried using the base64 version too, it does not work.

I noticed 1 thing though. In the EPL doc for the GW command, the data expected 
is after the 4th parameter, but the file generated by UPS is on another line.

I re-flash my S4M to ZPL firmware, and the ZPL file from UPS works though.

Original comment by yuchouc...@gmail.com on 10 Nov 2012 at 6:03

[GoogleCodeExporter]

I've used the base64 directly from UPS too, so the special characters should 
not affect.

Frontend I'm running windows.

Original comment by yuchouc...@gmail.com on 10 Nov 2012 at 6:06

[GoogleCodeExporter]

Another a base64 file which I've tested.

Original comment by yuchouc...@gmail.com on 10 Nov 2012 at 6:08

Attachments:

• 1Z8E899F0393960385.epl

[GoogleCodeExporter]

Are you use appendFile() ?

-Tres

Original comment by tres.fin...@gmail.com on 10 Nov 2012 at 6:10

[GoogleCodeExporter]

I use append64 and the base64 file is read in using php.

Original comment by yuchouc...@gmail.com on 10 Nov 2012 at 6:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The applet needs an appendFile64() option.  I'll put that on the list.  In the 
mean time, I'm not sure what else can be done to fix that label other than 
contacting UPS to see if there are any known issues with certain printer models.

It may be the applet mucking it up, but it would be a substantial undertaking 
on my part to prove that.  I will leave this open, but not sure when I'll have 
the time to do a full investigation on the files you've attached.

Original comment by tres.fin...@gmail.com on 10 Nov 2012 at 6:19

[davidglezz]

@tobarbaro please remove the spam message.