Bug 150722
Summary: | evince refuses to display valid PostScript files | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | evince | Assignee: | Marco Pesenti Gritti <mpg> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | mpg |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-05-31 10:34:19 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michal Jaegermann
2005-03-09 22:39:52 UTC
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... |