Bug 688842

Summary: ghostscript-gpl chokes on one pdf-file printing with cups
Product: Ghostscript Reporter: Florian Mickler <florian>
Component: PS WriterAssignee: Default assignee <ghostpdl-bugs>
Status: NOTIFIED INVALID    
Severity: normal CC: htl10
Priority: P4    
Version: 8.54   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: cups debug log
corpus delicti
faulty ps file

Description Florian Mickler 2006-08-22 07:16:29 UTC
Hi!
I'm using gentoo and have  cups-1.1.23-r8 and ghostscript-gpl-8.54 installed and
am using the hp-lj
1320 with the standard postscript laserjet ppd(no manual fiddling with the cups
config or smth like that)

everthinh works fine. But I have trouble printing with one special pdf. Other
pdf's (even from the same source - means same pdfinfo besides title and date)
print just fine.

I have attached the cups-debug output. 
I have also attached the corpus delicti... (means the pdf in question)

could someone perhaps confirm this bug? 
and tell me whats wrong?

(Brief excerpt:)
D [22/Aug/2006:14:36:18 +0200] [Job 594] Error: /undefined in pdfLastFill
D [22/Aug/2006:14:36:18 +0200] [Job 594] Operand stack:
D [22/Aug/2006:14:36:18 +0200] [Job 594] --nostringval--
D [22/Aug/2006:14:36:18 +0200] [Job 594] Execution stack:
D [22/Aug/2006:14:36:18 +0200] [Job 594] %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--   --nostringval--
D [22/Aug/2006:14:36:18 +0200] [Job 594] Dictionary stack:
D [22/Aug/2006:14:36:18 +0200] [Job 594] --dict:1132/1686(ro)(G)--  
--dict:0/20(G)--   --dict:76/200(L)--   --dict:64/75(L)--   --dict:7/8(L)--  
--dict:2/2(L)--
D [22/Aug/2006:14:36:18 +0200] [Job 594] Current allocation mode is local
D [22/Aug/2006:14:36:18 +0200] [Job 594] Last OS error: 2
D [22/Aug/2006:14:36:18 +0200] [Job 594] GPL Ghostscript 8.54: Unrecoverable
error, exit code 1
E [22/Aug/2006:14:36:18 +0200] PID 4419 stopped with status 1!
E [22/Aug/2006:14:36:18 +0200] [Job 594] No pages found!
E [22/Aug/2006:14:36:18 +0200] PID 4420 stopped with status 1!


greets,
Florian

p.s. thx for your help!

p.s. converting pdf first via pdftops or pdf2ps and printing the ps-file does
not help either...
Comment 1 Florian Mickler 2006-08-22 07:17:15 UTC
Created attachment 2422 [details]
cups debug log
Comment 2 Florian Mickler 2006-08-22 07:18:41 UTC
Created attachment 2423 [details]
corpus delicti
Comment 3 Hin-Tak Leung 2006-08-23 04:00:30 UTC
both pdf file and result of pdftops work fine with AFPL 8.54 x86 linux
x11 or nullpage device.

Trying to see if you can display either of them (gs -sDEVICE=x11) or just
pass-through (gs -sDEVICE=nullpage). If they don't work, suspect
AFPL/GPL difference or gentoo specific modifications, and please try HEAD.

My AFPL gs are patched with these post-release patches:
Patch9:  gs688720-2227.patch
Patch10: gs688721-2228.patch
#Patch11: gs688725-2234.patch ==obsolete by patch12
Patch12: gs688725-2235.patch
Patch13: gs688724-2241.patch
Patch14: gs688725-2245.patch
Patch15: gs688532-2216.patch
Patch16: gs688736-2268.patch
Patch17: gs688741-2266.diff
Patch18: gs688764-6889.patch

The first number is ghostscript bug number, the 2nd one 
the attachment number to that bug. (most of them are already in
gs HEAD branch, I think).
 
Comment 4 Florian Mickler 2006-08-24 05:43:33 UTC
gs -sDEVICE=x11 works on the pdf-file but not on the ghostscript-file created
with pdftops.
albeit pdf2ps makes no problems...

investigating the differences between these to made apparent, that pdf2ps is
using gs while pdftops is using libpoppler...

so this bug could be likely unrelated to gs, but i am attaching the faulty
postscript-file anyways....

thx for your help, 
Florian
Comment 5 Florian Mickler 2006-08-24 05:47:11 UTC
Created attachment 2424 [details]
faulty ps file

created with pdftops:
pdftops -v    
pdftops version 3.00
Copyright 1996-2004 Glyph & Cog, LLC
Comment 6 Florian Mickler 2006-08-24 05:52:01 UTC
how can i determine if the ps-file is invalid/broken or if this is an gs-error?
Comment 7 SaGS 2006-08-25 00:59:48 UTC
The PostScript file (attachment #2424 [details]) is incorrect.

While creating a Type3 font (starting at line "%%BeginResource: 
font T3_41_0"), the file sets the graphics state, outside any 
(CharProc) procedure - don't know why, it doesn't seem necessary. 
For this it executes "sc" (line "[0] sc"), which refers 
"pdfLastFill". The latter is defined in a dictionary that exists 
on the dict stack only while inside pages, created and pushed by 
"pdfStartPage". Since no page begun yet, the dict was not created 
and "pdfLastFill" cannot be found.
Comment 8 Florian Mickler 2006-08-25 09:11:05 UTC
thx! you helped me very much!

greets,
Florian

p.s.: i reported this to the poppler-ml.
Comment 9 Hin-Tak Leung 2006-08-25 09:40:42 UTC
It does not seems to be a poppler problem, but *your copy* of poppler.
You need to report this to gentoo instead. (I am on fc5).

My pdftops generates almost identical ps code with -level3, 
except the offending "[0] sc" lines inside T3_41_0 as noted by 
SaGS is missing:

====================
@@ -2034,18 +2034,6 @@
 } bind def
 /CharProcs 2 dict def
 CharProcs begin
-[] 0 d
-1 i
-0 j
-0 J
-10 M
-1 w
-/DeviceGray {} cs
-[0] sc
-/DeviceGray {} CS
-[0] SC
-false op
-false OP
 /a1 {
 0 0 0 0 151 76 setcachedevice
 q
==================

pdftops -v
pdftops version 3.00
Copyright 1996-2004 Glyph & Cog, LLC

$rpm -qf /usr/bin/pdftops
poppler-utils-0.5.1-2
$ rpm -qa | grep 'poppler'
poppler-utils-0.5.1-2
poppler-0.5.1-2