[bug-notifications] [graphviz 0004276]: PNG backend: dot files from scfdot converted to png contain extraneous line
Mantis Bug Tracker
noreply at opencsw.org
Mon Feb 15 19:34:35 CET 2010
A NOTE has been added to this issue.
======================================================================
http://www.opencsw.org/mantis/view.php?id=4276
======================================================================
Reported By: skayser
Assigned To:
======================================================================
Project: graphviz
Issue ID: 4276
Category: regular use
Reproducibility: always
Severity: minor
Priority: normal
Status: new
======================================================================
Date Submitted: 2010-02-15 13:56 CET
Last Modified: 2010-02-15 19:34 CET
======================================================================
Summary: PNG backend: dot files from scfdot converted to png
contain extraneous line
Description:
When i feed .dot files generated by scfdot to dot with -Tpng, the resulting
.png files contain an extra line at the top which makes the png unreadable
by image viewers. Deleting this line fixes the issue. Is this a bug in dot,
scfdot, or the png backend?
$ dot -V
dot - graphviz version 2.26.3 (20100126.1600)
# pkgutil -t http://mirror.opencsw.org/opencsw/testing -Ni scfdot
...
$ dot -Tpng -o test.png /opt/csw/share/doc/scfdot/examples/snv_24_x86.dot
$ file test.png
test.png: data
$ head -1 test.png
-36 2444.2 translate newpath user_shape_0
$ gsed -i -e '1d' test.png
$ file test.png
test.png: PNG image data
Simple graphs don't expose this problem.
$ echo "digraph G {Hello->World}" | dot -Tpng >hello.png
$ file hello.png
hello.png: PNG image data
======================================================================
----------------------------------------------------------------------
(0007441) ellson (manager) - 2010-02-15 19:34
http://www.opencsw.org/mantis/view.php?id=4276#c7441
----------------------------------------------------------------------
OK, It seems it may not be a bug, or it may be a different bug ;-)
In our documentation we say:
> External PostScript files
> If using the PostScript driver (-Tps) you can import node shapes as
external PostScript files such as EPS (Encapsulated PostScript). At a
minimum, the external file must have a valid BoundingBox header and not do
drastic things to the graphics state since we don't install a wrapper for
example to inhibit showpage.
>
> To import an external PostScript file, set the shape and shapefile
attributes as shown here:
>
>
> somenode [shape=epsf, shapefile="yourfile.ps" ];
>
> An EPSF shape is always clipped to its bounding box.
>
> The use of [shape=epsf, shapefile="yourfile.ps" ] is largely superceded
by the mechanism described in the previous section, using
[image="yourfile.ps" ].
So basically, you shouldn't be using shape=epsf unless your output is
-Tps.
You should be able to use the more recent imageloading code using
"image":
legend [shape=none,image="legend.ps",label=""];
Unfortunately, when I tried this on linux I got:
Error: legend.ps: gsapi_init_with_args() returned: -15 "rangecheck"
(PostScript Level 1)
This may be a platform issue? Using a simpler .ps image that I generated
locally worked ok. Also, converting your legend.ps to .epsi using
ps2epsi
produced an image that it would load.
More information about the bug-notifications
mailing list