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 upstream. 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: yyyyyyyyyyyyyyyyyyyyyyy 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 returns %%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).
Created attachment 308827 [details] eff_2.ps
Created attachment 308828 [details] evince.png
Created attachment 308829 [details] gs.png
Created attachment 308830 [details] sysreport-ae-e-sl01.arianespace.fr-1779256.20071108204941.tar.bz2
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
Hi, 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 process. The customer is therefore requesting a review of the decision to bump this to 5.5. Thanks, -- Paul Novarese This event sent from IssueTracker by pvn issue 247699
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. ;)
Hi, 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. Regards Marek
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. Regards Marek