gv works, ggv has the same issue

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

Reassigning to ghostscript:

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

while

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

fails.

Or is there a legitimate reason for this behavior?

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

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

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.

Ok, that make sense. Reassigning back to epiphany. I need to look at
gv code to see how it handles this case.

I reported this upstream. Will try to get it fixed...