Bug 109059 - gs views a file fine, but fails when used as a renderer by Foomatic
gs views a file fine, but fails when used as a renderer by Foomatic
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: foomatic (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Tim Waugh
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-04 13:08 EST by Jason Tibbitts
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 3.0.0-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-05 10:39:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Job which fails to print (418.25 KB, application/postscript)
2003-11-04 13:09 EST, Jason Tibbitts
no flags Details
Full CUPS logfile (19.85 KB, text/plain)
2003-11-04 13:10 EST, Jason Tibbitts
no flags Details

  None (edit)
Description Jason Tibbitts 2003-11-04 13:08:59 EST
I have a file that seems to be valid postscript.  gs will view it just
fine, and it prints on Postscript printers without error.  But when
printing to an attached HP Business Inkjet 2200 using Ghostscript as
the renderer, everything bombs with the following Ghostscript error
(sorry for wrapping):

Error: /undefined in MathWorks
Operand stack:

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   .runexec2  
--nostringval--   --nostringval--   --nostringval--   2  
%stopped_push   --nostringval--   --nostringval--   --nostringval--
Dictionary stack:
--dict:1070/1123(ro)(G)--   --dict:0/20(G)--   --dict:101/200(L)--
Current allocation mode is local
Last OS error: 2
GNU Ghostscript 7.05: Unrecoverable error, exit code 1

I will attach the job and the full log.

This happens with Ghostscript 7.05-32.1 from Shrike and 7.07-11 from
Fedora.  Foomatic is 3.0.0-6.

My first guess at the problem is that something in the extra
postscript that foomatic inserts around the document interferes with
the document itself.  Unfortunately I don't know how to extract the
job that is sent to the renderer, nor do I know enough about
Postscript to be able to debug it if I could find it.  I was informed
on Usenet that the job prints fine when ESP Ghostscript is used as the
renderer, but my attempts to get it properly installed have failed.
Comment 1 Jason Tibbitts 2003-11-04 13:09:59 EST
Created attachment 95717 [details]
Job which fails to print
Comment 2 Jason Tibbitts 2003-11-04 13:10:40 EST
Created attachment 95718 [details]
Full CUPS logfile
Comment 3 Jason Tibbitts 2003-11-05 00:55:06 EST
Much debugging effort showed this to be a problem not in Ghostscript
but in Foomatic.  The modifications it made resulted in an invalid
Postscript file.  Upgrading to the foomatic-rip in
foomatic-filters-3.0-20031104 fixed the problem.

Changing the component to foomatic as that's where the bug is.
Comment 4 Tim Waugh 2003-11-05 10:39:41 EST
Fixed in foomatic-3.0.0-10.

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