Bug 690297 - pdf2ps -dLanguageLevel=1 produces a ps file that fails with /undefined in Ic
Summary: pdf2ps -dLanguageLevel=1 produces a ps file that fails with /undefined in Ic
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Writer (show other bugs)
Version: 8.64
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
URL:
Keywords: bountiable
Depends on:
Blocks:
 
Reported: 2009-02-19 15:18 UTC by William Bader
Modified: 2010-08-13 08:57 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
pdf file (570.64 KB, application/pdf)
2009-02-19 15:19 UTC, William Bader
Details

Note You need to log in before you can comment on or make changes to this bug.
Description William Bader 2009-02-19 15:18:11 UTC
The problem can be recreated with the commands below.
It works with -dLanguageLevel=2
The pdf file views OK with gs and with Acrobat Reader 5.0 (under wine), so I
think that it is valid, but it has some images at the bottom that xpdf does not
handle (which is why I tested the file with ghostscript).
At LanguageLevel 1, gdevps.c does not write psw_1_5_procset which contains
"/Ic{exch Ix false 3 colorimage}!", although maybe psw_copy_color() should
generate something else instead of Ic.
I have Fedora 8 Linux on a Core2Duo cpu, and I built gs from source.
William

$ pdf2ps -dLanguageLevel=1 testimagemask.pdf testimagemaskgs.ps 
$ gs testimagemaskgs.ps
GPL Ghostscript 8.64 (2009-02-03)
Copyright (C) 2009 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefined in Ic
Operand stack:
   --nostringval--   247   1018   53   1   --nostringval--   8
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1830   1   3   %oparray_pop   1829
  1   3   %oparray_pop   1813   1   3   %oparray_pop   1707   1   3  
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--  
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1143/1684(ro)(G)--   --dict:0/20(G)--   --dict:71/200(L)--  
--dict:53/80(L)--   --dict:36/197(L)--
Current allocation mode is local
Last OS error: 11
Current file position is 20439
GPL Ghostscript 8.64: Unrecoverable error, exit code 1
Comment 1 William Bader 2009-02-19 15:19:06 UTC
Created attachment 4802 [details]
pdf file
Comment 2 Ken Sharp 2009-02-24 03:32:14 UTC
The psw_1_5 procset is the ProcSet for level 1.5, which is why it doesn't get
written if you have level 1 output set. 

The problem seems to be (at least in part) that the job contains Pattern colour
spaces which use images to paint the pattern. Pattern colour spaces aren't
available in level 1, so the pattern fill gets converted to an image. The final
image seems to be in RGB, I'm not certain why at the moment, even setting
ProcessColorModel to DeviceGray doesn't seem to prevent this.

To solve this we would need to convert colour images to monochrome when output
level is set to 1.

While this is certainly a bug, pswrite is not really recommended any more, we
would rather see ps2write being used, and true level 1 devices must be pretty
hard to come by these days. Do you really need actual level 1 output, or would
level 1.5 be sufficient ?

Comment 3 William Bader 2009-02-24 05:20:50 UTC
Thanks for looking at the file.  I need to convert the file into a format that I
can use to do a software separation in postscript.  (I have a postscript page
built from images like this, and I want to make c, m, y and k versions of the
page by using prologues that redefine color operators.)  My separation prologue
can handle level 1 but not all of level 2, so when I have a pdf, I would prefer
to convert it to a level 1 eps because I know that my separation prologue will
handle it.  This file caused a problem when the conversion to level 1 failed. 
Since this particular file prints in b&w, converting it to level 2 worked well
enough, but in the future, I might have a similar file with color, and then I
would need to convert it to level 1.
The worst problem for me was that gs produced an invalid file without returning
an error status.  If gs finds a file that it can't convert to level 1, the best
for me would be if it produced a level 2 file instead and the next best would be
if gs would return an error status so that I could detect it inside my script.
Comment 4 Ken Sharp 2009-02-24 05:36:45 UTC
> Since this particular file prints in b&w, converting it to level 2 worked well
> enough, but in the future, I might have a similar file with color, and then I
> would need to convert it to level 1.

That's a fundamental problem. Level 1 PostScript doesn't support colour, not at
all, not even a little bit. If you must convert to level 1, then you can't have
colour. 

Which is why I suggest using level 1.5, this is level 1 incorporating common
extensions to the language that were created by vendors (including Adobe) to
overcome the missing features of level 1 PostScript, in particular the lack of
colour. Many of these were later codified and added to the language in level 2.

If your prologue redefines the colour operators then it isn't working with level
1 PostScript, more likely level 1.5. There's really no point in creating
separations from a level 1 PostScript file, because it all prints on the black
plate ;-)

While acknowledging the problem, as I said pswrite is not well supported any
more and we'd much rather people used ps2write. This issue is unlikely to be
looked at any time soon I'm afraid.
Comment 5 William Bader 2009-02-24 07:26:41 UTC
>This issue is unlikely to be looked at any time soon I'm afraid.

That is fine.  I have the work-around of creating a level 2 file, and I've asked
the people who made that file to try not to make files like that again.  We
suspect that the problem is photoshop psd images (three of the faces at the
bottom) that they pasted into a indesign page.