Description of problem: After an update to 3.02 it is no longer possible on x86_64 to print files with embedded graphics. If this is a "text only" file then printing still works. Otherwise results may wary depending on a type of a printer used. With a non-PS printer jobs may just "vanish" and in cups logs then it is possible to find things like "[Job 590] /ioerror in --image--" without any further clue what went wrong. If printing to a PS printer then one may get an expected number of blank pages, or only graphics elements will be missing, apparently depending on how error recovery works in a printer interpreter. Attached is a sample PDF file which was produced to contain a jpeg image only (like something you will make, say, from a scan). Results from printing that "to a file" and via cups to "a generic Postscript printer", which actually is sending an output to a file, differ (the later output is attached as well) but in both cases attempts to run 'ps2ps' on a produced "Postscript" results in something of that sort: ERROR: /ioerror in --image-- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- 1 8 %oparray_pop Dictionary stack: --dict:1119/1686(ro)(G)-- --dict:0/20(G)-- --dict:109/200(L)-- --dict:65/75(L)-- --dict:18/24(L)-- --dict:0/15(L)-- --dict:0/15(L)-- --dict:0/15(L)-- Current allocation mode is local Last OS error: 2 Current file position is 14591 ESP Ghostscript 815.04: Unrecoverable error, exit code 1 If I will do the above in i386 machines with xpdf-3.02 (FC6, F7) then everything appears to work fine. Results of "Print to file" are of the same size but 'pdfIm' sections are totally different. It appears that 'PSOutputDev.cc' does that job. I had a quick look there but I am not wiser as for now. That file differs markedly between 3.01 and 3.02. Version-Release number of selected component (if applicable): xpdf-3.02-2.fc7 How reproducible: always on files with graphics and x86_64
Created attachment 161915 [details] sample PDF "picture only" document
Created attachment 161916 [details] results of printing on "generic PS printer" "print to file" produces different file but faulty picture encoding is the same.
I can confirm this as well. Writing to a file from xpdf and then trying to view the postscript file with ghostscript (even ghostscript 8.60) is giving the above error. Everything else produces a working ps file e.g. using pdftops (poppler) or adobe reader.
> Everything else produces a working ps file e.g. > sing pdftops (poppler) .... 'poppler' is based on a pretty old xpdf code. I am not entirely sure about version releationships but it looks that is derived from close to four years old version 3.00 even for poppler-0.5.91-2.fc8 from the current rawhide (which possibly means that a PDF 1.6 or PDF 1.7 file may give it a serious indigestion). If you will use instead pdftops compiled from xpdf-3.02 source then on x86_64 there is the same trouble. What really fails is a picture encoding in a produced Postscript (maybe a subject should be changed to that?). That trouble showed up in 3.02. In a sample attached to this bug the first four bytes after 'pdfIm' use should be "s4IA"; instead they are "nbeM". After that such groups of wrong four bytes are sprinkled all over encoding among of long runs of what you expect to be there. If you will set psLevel to "level1" (say in ~/.xpdfrc) then the picture is a bitmap and it should come up all right for a price of bloating an output.
Created attachment 161997 [details] patch to fix xpdf printing on 64 bit platforms
> patch to fix xpdf Yeap! Thanks! Exactly of an expected kind. I had troubles figuring out what is really producing those encoding bytes. :-)
xpdf-3.02-3.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
xpdf-3.02-3.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.