gs-esp: ERROR: /undefined in --get--

[Bill Moseley]

I have a PDF (I didn't generate) that includes form fields.
I can print it on my Postscript printer, but the pstoraster script is
failing when trying to send to an Epson inkjet.

I enabled cups debugging to determine the command that was being run,
then ran it manually:

bumby:/var/spool/cups$ file d01137-001
d01137-001: PostScript document text conforming at level 3.0


bumby:/var/spool/cups$ /usr/bin/gs-esp -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=/dev/null -c - <d01137-001

There's a ton of DEBUG output, but it ends like this:

DEBUG: matrix = [ 1.389 0.000 0.000 -1.389 -0.000 1100.000 ]
Finishing.
-dict-
-dict-
-dict-
-dict-
-mark-
-dict-
ERROR: /undefined in --get--
Operand stack:
( ) 0 --dict:12/15(ro)(L)-- 32 space --dict:4/256(ro)(L)-- space
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 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- %finish_stringwidth --nostringval-- --nostringval-- 5 6 2 --nostringval-- (gs_show_enum) %op_show_continue --nostringval--
Dictionary stack:
--dict:1122/1686(ro)(G)-- --dict:0/20(G)-- --dict:103/200(L)-- --dict:64/75(L)-- --dict:18/24(L)-- --dict:11/15(L)-- --dict:12/15(ro)(L)--
Current allocation mode is local
Last OS error: 2
ESP Ghostscript 815.03: Unrecoverable error, exit code 1
DEBUG2: cups_close(0x860dd8c)



I do not know how the PDF was generated. Is there a way to "validate"
this postscript or the PDF it came from?

[Helge Blischke]

Post by Bill Moseley
I have a PDF (I didn't generate) that includes form fields.
I can print it on my Postscript printer, but the pstoraster script is
failing when trying to send to an Epson inkjet.
I enabled cups debugging to determine the command that was being run,
bumby:/var/spool/cups$ file d01137-001
d01137-001: PostScript document text conforming at level 3.0
bumby:/var/spool/cups$ /usr/bin/gs-esp -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=/dev/null -c - <d01137-001
DEBUG: matrix = [ 1.389 0.000 0.000 -1.389 -0.000 1100.000 ]
Finishing.
-dict-
-dict-
-dict-
-dict-
-mark-
-dict-
ERROR: /undefined in --get--
( ) 0 --dict:12/15(ro)(L)-- 32 space --dict:4/256(ro)(L)-- space
%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-- %finish_stringwidth --nostringval-- --nostringval-- 5 6 2 --nostringval-- (gs_show_enum) %op_show_continue --nostringval--
--dict:1122/1686(ro)(G)-- --dict:0/20(G)-- --dict:103/200(L)-- --dict:64/75(L)-- --dict:18/24(L)-- --dict:11/15(L)-- --dict:12/15(ro)(L)--
Current allocation mode is local
Last OS error: 2
ESP Ghostscript 815.03: Unrecoverable error, exit code 1
DEBUG2: cups_close(0x860dd8c)
I do not know how the PDF was generated. Is there a way to "validate"
this postscript or the PDF it came from?

That is a known bug in ESP gs 8.15 which uses "space" as the substitution glyph
instead of the ".notdef" required by the specs, but fails to make sure that
the space glyph is defined even in subsetted fonts the used subset of which
lacks the space glyph.

File a bug for ESP gs
.

Helge

[Michael Sweet]

Post by Helge Blischke
...
That is a known bug in ESP gs 8.15 which uses "space" as the
substitution glyph
instead of the ".notdef" required by the specs, but fails to make sure that
the space glyph is defined even in subsetted fonts the used subset of which
lacks the space glyph.
File a bug for ESP gs

Please don't. We already had a bug open on this and decided the
simplest solution was to revert to the .notdef glyph in 8.15.4. You
can still select space as the replacement character...

The problem is that the PDF file's embedded font is broken (missing
a required character), so what you'll see is the standard Ghostscript
.notdef glyph which is usually a box character. The original reporter
(Tim Waugh) had suggested that we try both space and .notdef, but that
proved to be too complicated for a fork that will no longer be
maintained...

FWIW, all future Ghostscript development is happening in the official
(GPL) Ghostscript tree, so any bugs should be reported on
ghostscript.com; I'll be removing the ESP Ghostscript bug report page
from cups.org in the near future...

[Bill Moseley]

Post by Michael Sweet
The problem is that the PDF file's embedded font is broken (missing
a required character),

So, specific to my situation: I should mention to the producer of the
pdfs that their PDF generator is the problem?

And is there any way to "repair" the document on my end to get it to
print?

[Michael Sweet]

Post by Bill Moseley

Post by Michael Sweet
The problem is that the PDF file's embedded font is broken (missing
a required character),

So, specific to my situation: I should mention to the producer of the
pdfs that their PDF generator is the problem?

Yes.

Post by Bill Moseley
And is there any way to "repair" the document on my end to get it to
print?

There are probably programs that can do it. For Ghostscript, you
can add the "-sespgsMissingChar=/.notdef" option or just edit
gs_init.ps and swap the comments on the definition there (that's
what we did for 8.15.4...)