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--
%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
--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)--
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):
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.