Red Hat Bugzilla – Bug 450712
[CRM#1779256] evince does not display postscript documents in their entirety
Last modified: 2010-10-22 21:49:26 EDT
Description of problem:
When opening Postscript files, evince (the default PS viewer for PS and PDF in
RHEL5 under Gnome) does not display the page in its entirety.
Converting the file from PS to PDF using ps2pdf and then opening the resulting
PDF file gives allows to see the full content of the page.
kpdf does not suffer form this problem either (unfortunately kpdf is part of
kdegraphics which is *not* available in RHEL5 Server).
The problem seems to be still present in very recent version of evince/poppler
such as the ones included in Fedora 8, so there are good chances that the bug is
100% reproducible with the sample Postscript file.
Steps to Reproduce:
Open the attached file eff_2.ps in evince. Some part at the bottom is not
visible in evince whereas it's visible in kpdf or gs and printed correctly.
The bottom of the file is not displayed, see the numbers missing at the bottom:
The file should be seen in its entirety like in
gs -sDEVICE=x11 eff_2.ps
See eff_2.ps as sample (provided by the customer). ggv in RHEL4 exhibits the
The customer is using the RHEL5 server as a computational system and expects to
be able display the results prior to print them.
I suggested using kpdf as a workaround, but since it is not available in the
Server version of RHEL5, I had to provide the rpms (from the RHEL5 Client
channel) and ask the customer to install them by hand.
This seems to be an acceptable temporary solution for the customer, until a fix
for evince is available.
Notes from SEG:
hmm. In this case, evince is using ghostscript..
setting export EV_LOG_MODULES=all and
after running strace -ff -o g.strace evince eff_2.ps
running /usr/bin/gs -sDEVICE=x11alpha -dNOPLATFONTS -dGraphicsAlphaBits=4
-dTextAlphaBits=4 -dDOINTERPOLATE -dQUIET -dSAFER /home/alanm/Desktop/eff_2.ps
shows all the text
The problem seems to exist in the upstream svn version as well.
If I convert eff_2.ps to pdf with ps2pdf eff_2.ps eff_2.pdf
and display eff_2.pdf I get the correct display.
evince is reading the bounding box info directly from the .ps file
which says %%BoundingBox: 50 50 503 755
doing a gs -dQUIET -sDEVICE=bbox ~alanm/Desktop/eff_2.ps
%%BoundingBox: 59 57 554 739
%%HiResBoundingBox: 59.957998 57.293998 553.229983 738.719977
I would guess that when ps2pdf calls gs, gs computes the BoundingBox instead of
taking the value written in the file as being correct and then writes out the
Here's why kpdf works and evince doesn't.
kpdf converts the ps file by calling gs and writing out a temporary pdf file. It
then displays the pdf file using it's own version of the poppler code (from xpdf).
Created attachment 308827 [details]
Created attachment 308828 [details]
Created attachment 308829 [details]
Created attachment 308830 [details]
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Moving to 5.5
I spoke to the customer about this case and informed him that it got moved
back to 5.5.
His response was less than pleasant. Apparently this is a bigger deal to
them than he had originally let on. I'm not sure why they withheld this
information, but apparently evince is a pretty significant piece of the
launch process for the space shuttle. The people in mission control plot
various launch trajectories and other stuff like that in PDF format then
other people in mission control view it in evince.
This bug (and BZ 481593) are creating pretty significant problems in this
The customer is therefore requesting a review of the decision to bump this
This event sent from IssueTracker by pvn
ps2ps creates a .ps that evince can read.
The fidelity seems much higher than that of gimp (what I saw was very gritty, probably because it was rasterized).
Sure only a dirty workaround, but it might help. ;)
on the 39th page of "PostScript Language Document Structuring Conventions (DSC) Specification"
(http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf) is written:
"This comment specifies the bounding box that encloses all marks painted
on all pages of a document. That is, it must be a "high water mark" in all
directions for marks made on any page."
Since values of %%BoundingBox in the sample are wrong and
correcting them shows entire document, it can not be a bug in evince. It is probably a bug in software producing such files.
The problem described in this report is not a bug. Submitted postscript files don't have correct %%BoundingBox and %%PageBoundingBox values. Correcting these values shows postscript documents in their entirety.