[Output Generation] Custom EPS shape results in invalid output file
Ported Issue from Mantis Original ID: 259 Reported By: David Coppit
SEVERITY: MAJOR Submitted: 2003-07-26 18:25:49
OS: X86-LINUX-REDHAT 8.0
VERSION: 1.10.20030725.0415-1
DESCRIPTION
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:
--- 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.
STEPS TO REPRODUCE
digraph foo { be1 [label="be1\n1" shape="epsf" shapefile="etc/shapes/be.eps"]; }
ADDITIONAL INFORMATION
[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?