Created attachment 34415 [details] Bad PostScript When generating PostScript output (printing) from the following pdf: http://www.yokogawa.com/ddm/catalog/bu/BU71M01A00-01E.pdf poppler? generates the the PostScript that contains the fragment in the attachment. The problem is that the line 'dup 76 <~>~> put' is not well handled by PostScript (the printer aborts the job), since ASCII85 strings of length 1 are illegal. The entire PS file (5 MB) is available on request.
Shouldn't all the loops that looks like: for (i = 1; i <= (useASCIIHex ? 1 : 4); ++i) { be: for (i = 1; i <= (useASCIIHex ? 1 : 5); ++i) { since ASCII85 is a 4->(1/5) byte encoding, which means that each 32 bits gives either 1 (all zeroes -> z) or 5 bytes of output.
How did you generate that ps? Because pdftops generates a completely different one
Created attachment 34421 [details] The ppd file for the printer used
Printing from evince on a Ubuntu 9.10 via cups to a printer with attached ppd file.
I'm going to blame it on the glib frontend then.
You can most probably pinpoint it to this file/function: poppler/PSOutputDev.cc: PSOutputDev::setupImage
No, if you were using PSOutputDev you would not get that ps, if you want to try PSOutputDev use pdftops and you'll see how different the file generated is.
'pstopdf -preload' gives very similar output.
Think I found the bug, the cups server was running 'pdftops version 0.10.7', which exhibited the problem. I have not been able to reproduce the bug with 0.12.4.
Closing as worksforme then, thanks for the investigation.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.