| Summary: | ghostscript-gpl chokes on one pdf-file printing with cups | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Florian Mickler <florian> |
| Component: | PS Writer | Assignee: | 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
Created attachment 2422 [details]
cups debug log
Created attachment 2423 [details]
corpus delicti
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). 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 Created attachment 2424 [details]
faulty ps file
created with pdftops:
pdftops -v
pdftops version 3.00
Copyright 1996-2004 Glyph & Cog, LLC
how can i determine if the ps-file is invalid/broken or if this is an gs-error? 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.
thx! you helped me very much! greets, Florian p.s.: i reported this to the poppler-ml. 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
|