Bug 450712 - [CRM#1779256] evince does not display postscript documents in their entirety
[CRM#1779256] evince does not display postscript documents in their entirety
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: evince (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Kristian Høgsberg
Depends On:
Blocks: 391501
  Show dependency treegraph
Reported: 2008-06-10 11:49 EDT by Alan Matsuoka
Modified: 2010-10-22 21:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-19 04:12:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
eff_2.ps (122.87 KB, application/postscript)
2008-06-10 11:49 EDT, Alan Matsuoka
no flags Details
evince.png (25.18 KB, image/png)
2008-06-10 11:50 EDT, Alan Matsuoka
no flags Details
gs.png (13.29 KB, image/png)
2008-06-10 11:50 EDT, Alan Matsuoka
no flags Details
sysreport-ae-e-sl01.arianespace.fr-1779256.20071108204941.tar.bz2 (1.40 MB, application/x-bzip2)
2008-06-10 11:51 EDT, Alan Matsuoka
no flags Details

  None (edit)
Description Alan Matsuoka 2008-06-10 11:49:31 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

How reproducible:

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.

Actual results:

The bottom of the file is not displayed, see the numbers missing at the bottom:

zzzzzzzz∆aaaaaaaa       111111111111
xxxxxxxxxxxxxxxxxxx     222222222222

Expected results:

The file should be seen in its entirety like in

   gs -sDEVICE=x11 eff_2.ps

Additional info:

See eff_2.ps as sample (provided by the customer). ggv in RHEL4 exhibits the
same problem.

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
correct values.
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).
Comment 1 Alan Matsuoka 2008-06-10 11:49:32 EDT
Created attachment 308827 [details]
Comment 2 Alan Matsuoka 2008-06-10 11:50:08 EDT
Created attachment 308828 [details]
Comment 3 Alan Matsuoka 2008-06-10 11:50:27 EDT
Created attachment 308829 [details]
Comment 4 Alan Matsuoka 2008-06-10 11:51:17 EDT
Created attachment 308830 [details]
Comment 6 RHEL Product and Program Management 2009-03-26 13:20:11 EDT
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 "?".
Comment 7 Alan Matsuoka 2009-03-26 13:33:26 EDT
Moving to 5.5
Comment 8 Issue Tracker 2009-04-21 00:39:13 EDT

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
to 5.5.


Paul Novarese 

This event sent from IssueTracker by pvn 
 issue 247699
Comment 10 Tilman Baumann 2009-05-15 04:18:52 EDT
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. ;)
Comment 12 Marek Kašík 2009-06-15 08:58:41 EDT

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:

%%BoundingBox: ...
"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.


Comment 26 Marek Kašík 2009-06-19 04:12:15 EDT
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.



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