Number: 333
Title: Custom EPS shape results in invalid output file
Submitter: David Coppit
Date: Sat Jul 26 13:25:49 2003
Subsys: output
Version: 1.10.20030725.0415-1
System: x86-Linux-RedHat 8.0
Severity: major
Problem:
No matter which way I create my EPS file, I can't get dot to output a PS file which Ghostscript can understand.

First, in the definition of /user_shape_0, Ghostscript doesn't wants %%BeginDocument to start a new line. Here's what dot is producing:

/user_shape_0 {%%BeginDocument:

I change this to: 


/user_shape_0 {
%%BeginDocument:

and that problem is solved.

The next problem isn't so easily solved. Here is Ghostscript's output: 


GSview 4.2 2002-02-07
Unknown in Page section at line 3195:
  %%EndPage: 1
Warning: code included between setup and first page
AFPL Ghostscript 7.04 (2002-01-31)
Copyright (C) 2001 artofcode LLC, Benicia, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Displaying DSC file Z:/research/software/nova_solver/fault_tree_10.ft.ps
Displaying page 1
Loading NimbusRomNo9L-Regu font from C:Program Filesgsfonts/n021003l.pfb... 1978760 610705 1662720 365950 1 done.
Scanning c:psfonts for fonts... 0 files, 0 scanned, 0 new fonts.
Error: /invalidaccess in --def--
Operand stack:
   --nostringval--   false   false   _pdfBoldBaseFont   _setwidthProc   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1   3   %oparray_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1015/1123(ro)(G)--   --dict:0/20(G)--   --dict:75/200(L)--   --dict:37/200(L)--   --dict:0/10(L)--   --dict:36/89(L)--   --dict:79/160(L)--   --dict:47/78(L)--   --dict:4/11(G)--
Current allocation mode is global
Last OS error: No such file or directory


--- Begin offending input ---
%%Page: 1 1
%%PageBoundingBox: 36 36 109 127
%%PageOrientation: Portrait
gsave
35 35 74 92 boxprim clip newpath
36 36 translate
0 0 1 beginpage
0 0 translate 0 rotate
0.000 0.000 0.000 graphcolor
14.00 /Times-Roman set_font


%	be1
gsave 10 dict begin
-19 -691 translate newpath user_shape_0
end grestore
endpage
showpage
grestore
%%PageTrailer
%%EndPage: 1


--- End offending input ---
file offset = 0
gsapi_run_string_continue returns -101


I'm attaching be.eps as the output file.

Input: 
digraph foo
{
  be1 [label="be1n1" shape="epsf" shapefile="etc/shapes/be.eps"];
}
Output file: b333.ps
Comments:
[north] I believe all %% headers have to be stripped out of the EPSF (or, better, munged somehow) since obviously they do not correctly apply to the containing Postscript document. This is a new bug because some earnest contributor recently improved the code by undoing the comment stripping in the EPSF shape loader ("hey, memory and disk are cheap now!") Feel free to contribute an appropriate improvement here.

[david] If I downgrade to 1.10, non-daily build, will I not encounter this bug? [later...] I tried several versions down to 1.08 and it didn't work...

[erg] See also bug b344 Even if you remove all of the %% headers, it still fails. It appears there are operations in the eps file which cannot be wrapped into a function?
Owner: *
Status: *