search

qzind / qz-print

Archive for legacy qz-print versions (1.8, 1.9). See https://github.com/qzind/tray for modern versions.
Other
141 stars 101 forks source link

Print job mangled in qz.print() but not in qz.printToFile() #47

Closed ragoley closed 9 years ago

ragoley commented 9 years ago

I have worked with the applet printing a good bit and have run into a wall with actual device printing. I use the append64() function to load a previously base64 encoded print job for transfer/printing thru the applet. If I send the print job to the print using qz.print(), it sends a mangled print job to the printer. It sends unreadable binary gibberish. If I use the qz.printToFile() function on that same base64 encoded/appended data, it decodes it perfectly in the file that is saved. I saw some previous bugs where the character set affected the print job decoding so I tried all of the recommended character set with qz.setencoding(). It seemed to change what the gibberish looked like but did not solve the problem. In my testing environment, the workstation running the applet is ubuntu 14.04. It has a working CUPS setup so I tried the alternate CUPS printing method but get the same gibberish results. Had hoped that if print to file worked that lpr -P printer filename might use that output but that does not seem to be the case. This is not just a result of the qz.append64(), this happens from all output of the qz.print() command no matter which of the qz.append*() functions are used to build the print job. The qz.printPS() called by the Print PDF demo button works correctly for this test environment. Has anyone else encountered this? I am using version 1.9.2.

tresf commented 9 years ago

@Ragoley,

A first step will be to post a snippet of your code and the hardware which you experience this issue on so that the problem can be reproduced.

Character encoding (which is what I suspect the problem to be) can be modified or assumed in a few places, so a working reproducible example is needed to troubleshoot this any further.

tresf commented 9 years ago

Note, I've also had this issue when encoding and Byte Order Mark (BOM) on the source file itself was set incorrectly.

If you cannot provide a working example, we'll have to close this out as invalid.

ragoley commented 9 years ago

You can close this issue. After getting the correct output result from the print to file function, I dug deeper into the local config. Somehow, CUPS was corrupting the print job when passing from my local Ubuntu 14.04 RAW queue to a print server's RAW queue running Ubuntu 12.04. I created a direct local queue on the 14.04 workstation and the issue went away.

tresf commented 9 years ago

:+1: