Bug 109059 - gs views a file fine, but fails when used as a renderer by Foomatic
Summary: gs views a file fine, but fails when used as a renderer by Foomatic
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: foomatic
Version: rawhide
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-11-04 18:08 UTC by Jason Tibbitts
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: 3.0.0-10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-11-05 15:39:41 UTC
Type: ---
Embargoed:


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

Description Jason Tibbitts 2003-11-04 18:08:59 UTC
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 18:09:59 UTC
Created attachment 95717 [details]
Job which fails to print

Comment 2 Jason Tibbitts 2003-11-04 18:10:40 UTC
Created attachment 95718 [details]
Full CUPS logfile

Comment 3 Jason Tibbitts 2003-11-05 05:55:06 UTC
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 15:39:41 UTC
Fixed in foomatic-3.0.0-10.


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