Bug 624515 - PostScript with Zapfino fails
Summary: PostScript with Zapfino fails
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Ralph Giles
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-17 01:17 UTC by Jack Moffitt
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
PostScript generated by Acrobat 5.0.6 (65.24 KB, application/postscript)
2003-04-08 10:07 UTC, Raph Levien
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Moffitt 2002-10-17 01:17:37 UTC
Originally reported by: oneiros@users.sourceforge.net
The enclosed file is generated by the Acrobat Reader
5.0.6 under Linux from a PDF generated by InDesign 1.5
and uses the Linotype Zapfino Ligature font. When it is
fed to gs (either 7.04 or 7.30), gs fails with

Error: /invalidfont in -dict-
Operand stack:
   RTSVRR+LinotypeZapfino-Ligature-Identity-H  
--dict:7/10(L)--   Font  
RTSVRR+LinotypeZapfino-Ligature-Identity-H  
--dict:7/10(L)--  
RTSVRR+LinotypeZapfino-Ligature-Identity-H
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--   3   8  
%oparray_pop   3   8   %oparray_pop   --nostringval-- 
 --nostringval--   --nostringval--   7   9  
%oparray_pop   --nostringval--   7   9   %oparray_pop 
 --nostringval--   --nostringval--
Dictionary stack:
   --dict:1005/1123(ro)(G)--   --dict:0/20(G)--  
--dict:74/200(L)--   --dict:44/89(L)--  
--dict:76/160(ro)(L)--   --dict:63/78(ro)(L)--  
--dict:8/25(L)--   --dict:27/35(ro)(L)--  
--dict:17/17(ro)(G)--
Current allocation mode is local
Last OS error: 2
Current file position is 65309

Jaws and a Laserjet 4 have no problems with the file,
so it seems gs is buggy.
Comment 1 Jack Moffitt 2002-10-21 03:13:37 UTC
Comment originally by oneiros@users.sourceforge.net
Logged In: YES 
user_id=33472

This works in 7.31; now only the bbox-device reports nothing
with this file.
Comment 2 Alex Cherepanov 2002-11-19 09:07:47 UTC
Comment originally by alexcher@users.sourceforge.net
Logged In: YES 
user_id=65750

This is a known problem. it is analysed in detail in
http://www.ghostscript.com/pipermail/gs-devel/2002-August.txt

The file runs with
gswin32 -c save pop -f ampersand.ps
Comment 3 Raph Levien 2003-04-08 10:07:34 UTC
Created attachment 71 [details]
PostScript generated by Acrobat 5.0.6
Comment 4 Ray Johnston 2003-04-08 10:17:17 UTC
I recommend 'false 0 startjob pop' as the preferred method to
start Ghostscript as if under a job server.

Linux printing should use this to process files to avoid problems
with files that expect to run on printers.

The command line invocation is:  -c "false 0 startjob pop" -f 
Comment 5 Ralph Giles 2003-07-30 09:49:58 UTC
With Ghostscript 8.11 and later, applications invoking ghostscript in a printing
context need to also specify -dNOOUTERSAVE to disable another work-around for
files that expect to run in a jobserver environment.

See http://www.ghostscript.com/pipermail/gs-cvs/2003-July/003465.html for details.
Comment 6 Ralph Giles 2003-10-21 05:09:15 UTC
This has been kept open as a place holder for education efforts re the job
server options. The title is confusing, so I've created a new bug 687095 to
track that and am closing this one.