Bug 253601 - xpdf-3.02 breaks printing of PDF files
xpdf-3.02 breaks printing of PDF files
Product: Fedora
Classification: Fedora
Component: xpdf (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-20 15:16 EDT by Michal Jaegermann
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: 3.02-3.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-04 18:13:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sample PDF "picture only" document (81.64 KB, application/pdf)
2007-08-20 15:16 EDT, Michal Jaegermann
no flags Details
results of printing on "generic PS printer" (114.05 KB, text/plain)
2007-08-20 15:22 EDT, Michal Jaegermann
no flags Details
patch to fix xpdf printing on 64 bit platforms (274 bytes, patch)
2007-08-21 14:58 EDT, Sammy
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2007-08-20 15:16:02 EDT
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)--  
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):

How reproducible:
always on files with graphics and x86_64
Comment 1 Michal Jaegermann 2007-08-20 15:16:04 EDT
Created attachment 161915 [details]
sample PDF "picture only" document
Comment 2 Michal Jaegermann 2007-08-20 15:22:10 EDT
Created attachment 161916 [details]
results of printing on "generic PS printer"

"print to file" produces different file but faulty picture encoding
is the same.
Comment 3 Sammy 2007-08-21 14:16:51 EDT
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.
Comment 4 Michal Jaegermann 2007-08-21 14:49:16 EDT
> 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.
Comment 5 Sammy 2007-08-21 14:58:29 EDT
Created attachment 161997 [details]
patch to fix xpdf printing on 64 bit platforms
Comment 6 Michal Jaegermann 2007-08-21 15:52:03 EDT
> patch to fix xpdf

Yeap!  Thanks!  Exactly of an expected kind.  I had troubles
figuring out what is really producing those encoding bytes. :-)
Comment 7 Fedora Update System 2007-08-29 13:27:16 EDT
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.
Comment 8 Fedora Update System 2007-09-04 18:13:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.