Bug 150722 - evince refuses to display valid PostScript files
Summary: evince refuses to display valid PostScript files
Alias: None
Product: Fedora
Classification: Fedora
Component: evince   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Marco Pesenti Gritti
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-09 22:39 UTC by Michal Jaegermann
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-31 10:34:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 306020 None None None Never

Description Michal Jaegermann 2005-03-09 22:39:52 UTC
Description of problem:

For example:

$ evince /usr/share/ghostscript/7.07/examples/snowflak.ps

produces only an alert "Unable to open document".

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Marco Pesenti Gritti 2005-03-12 12:53:41 UTC
gv works, ggv has the same issue

Comment 2 Marco Pesenti Gritti 2005-03-12 13:11:33 UTC
Ok the reason this fail is that it doesnt have a %!PS line at the top. In that
case evince/ggv test if it's really a ps file by passing it to gs and checking
the return value. Apparently gs is returning an error though... so this fails.
Need to find a proper solution for this...

Comment 3 Marco Pesenti Gritti 2005-03-12 15:09:14 UTC
Reassigning to ghostscript:

gs /usr/share/ghostscript/7.07/examples/snowflak.ps


gsnd /usr/share/ghostscript/7.07/examples/snowflak.ps


Or is there a legitimate reason for this behavior?

Comment 4 Michal Jaegermann 2005-03-12 18:26:41 UTC
> Ok the reason this fail is that it doesnt have a %!PS line at the top.

The file indeed starts with "%!<LF>".  This is not so frequent
nowadays but I have seen many PostScript files which open that way.
I do not have appriopriate documents handy, nor I pretend to be
a "PostScript wizzard", but I _think_ that this '!%' is good enough
according to PostScript standards.  You need "PS-Adobe-<something>"
when you claim a conformance to some specific PostScript level.
A document may be "non-conforming", which does not mean "incorrect",
and then, IIRC, it _has to_ start with "%!" and nothing else.
So even if a document is "conforming" then "%!PS-Adobe-..." is
not obligatory.

At least 'file', hence /usr/share/misc/magic, does not have any
doubts that in 'snowflak.ps' we are looking at a PostScript file
and ghostscript is willing, correctly, to accept that too.

Comment 5 Marco Pesenti Gritti 2005-03-13 01:06:38 UTC
>A document may be "non-conforming", which does not mean "incorrect",
>and then, IIRC, it _has to_ start with "%!" and nothing else.
>So even if a document is "conforming" then "%!PS-Adobe-..." is
>not obligatory.

Sure... and both evince and ggv handle that case. But they also try to
pass the poscript file to ghostscript with the NODISPLAY option to
verify it's actually a valid ps file.
Though for some reasons ghostscript fails to parse that file if
launched with NODISPLAY, while it works normally.

gsnd /usr/share/ghostscript/7.07/examples/snowflak.ps

Error: /undefinedresult in --div--
Operand stack:
   boxsize   72.0   0.0
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--
Dictionary stack:
   --dict:1112/1686(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--
Current allocation mode is local
Current file position is 1817
GPL Ghostscript 8.15: Unrecoverable error, exit code 1

While this works perfectly:

gs /usr/share/ghostscript/7.07/examples/snowflak.ps

I'm not a ghostscript expert really and I could be wrong... but that
seem like a ghostscript bug.

Comment 6 Michal Jaegermann 2005-03-13 05:02:40 UTC
Aha, NODISPLAY is really an explanation!  My bet is that with
that option 'pathbox' operator in snowflak.ps gives small enough
values for 'pagewidth' and/or 'pageheight' to end up below 'minsize'.
Therefore 'inwidth' or 'inheight' are set to zero and you are trying
to do a division by zero when calculating 'boxsize'.

If you will change in snowflak.ps these two definitions as follows:

/inwidth pagewidth minsize lt
     {1}{pagewidth minsize div} ifelse def
/inheight pageheight minsize lt
     {1}{ pageheight minsize div} ifelse def

then a resulting file is displayable by 'evince'.  No problems
with "%!" marker.

The above does not look to me like a ghostcript problem at all.
If this should be classified as a bug in 'snowflak.ps' or 'evince'
I am not that sure.  For one reason or another 'gv' does not have
a problem with that and what 'evince' eventually "paints" looks
remarkably similar to a 'gv' display.

Comment 7 Marco Pesenti Gritti 2005-03-13 09:38:01 UTC
Ok, that make sense. Reassigning back to epiphany. I need to look at
gv code to see how it handles this case.

Comment 8 Marco Pesenti Gritti 2005-05-31 10:34:19 UTC
I reported this upstream. Will try to get it fixed...

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