Bug 253601 - xpdf-3.02 breaks printing of PDF files
Summary: xpdf-3.02 breaks printing of PDF files
Alias: None
Product: Fedora
Classification: Fedora
Component: xpdf   
(Show other bugs)
Version: 7
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-20 19:16 UTC by Michal Jaegermann
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version: 3.02-3.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-04 22:13:42 UTC
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 19:16 UTC, Michal Jaegermann
no flags Details
results of printing on "generic PS printer" (114.05 KB, text/plain)
2007-08-20 19:22 UTC, Michal Jaegermann
no flags Details
patch to fix xpdf printing on 64 bit platforms (274 bytes, patch)
2007-08-21 18:58 UTC, Sammy
no flags Details | Diff

Description Michal Jaegermann 2007-08-20 19:16:02 UTC
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 19:16:04 UTC
Created attachment 161915 [details]
sample PDF "picture only" document

Comment 2 Michal Jaegermann 2007-08-20 19:22:10 UTC
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 18:16:51 UTC
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 18:49:16 UTC
> 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 18:58:29 UTC
Created attachment 161997 [details]
patch to fix xpdf printing on 64 bit platforms

Comment 6 Michal Jaegermann 2007-08-21 19:52:03 UTC
> 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 17:27:16 UTC
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 22:13:38 UTC
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.