OpenCSW Bug Tracker

Main | My View | View Issues
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0004276 [graphviz] regular use minor always 2010-02-15 13:56 2013-08-12 00:24
Reporter skayser View Status public  
Assigned To laurent
Priority normal Resolution unable to reproduce  
Status closed  
Summary 0004276: 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
Additional Information $ pkgparam CSWgraphviz VERSION
2.26.3,REV=2010.01.28
Tags No tags attached.
Attached Files

- Relationships
related to 0004288closedjames ghostscript Please rebuild ghostscript to link against CSW X11 

-  Notes
(0007436)
skayser (administrator)
2010-02-15 14:47

 FYI: Same problem can be observed with -Tjpg.

$ dot -Tjpg -o test.jpg /opt/csw/share/doc/scfdot/examples/snv_24_x86.dot
$ file test.jpg
test.jpg: data
$ head -1 test.jpg
-36 2444.2 translate newpath user_shape_0
(0007439)
ellson (reporter)
2010-02-15 18:54

 Definitely a bug in dot. We will fix this upstream.

Avoid the issue for now by commenting out the "legend" line in the source graph:

/* legend */
legend [shape=epsf,shapefile="/opt/csw/share/scfdot/legend.ps",label=""];
(0007440)
skayser (administrator)
2010-02-15 19:17

 Thanks for the feedback John! Just learned about using dot two days ago and honestly, I don't know how I could have survived without it so far! Sifting through Solaris SMF or Solaris Cluster dependencies has become a breeze. A very big thank you for packaging dot for Solaris.
(0007441)
ellson (reporter)
2010-02-15 19:34

 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.
(0007449)
skayser (administrator)
2010-02-16 15:20

 Tried the suggestion to use image instead shapefile. Now the resulting png image file is valid, but the legend is missing. Guess that has got to do with the missing "loadimage plugin" warning. Do I have to install an additional package to get that plugin or do you need to repackage graphviz/cairo?

$ cp /opt/csw/share/doc/scfdot/examples/snv_24_x86.dot test.dot
$ cp /opt/csw/share/scfdot/legend.ps legend.ps
$ ps2epsi legend.ps
$ vi test.dot
$ grep ^legend test.dot
legend [shape=none,image="legend.epsi",label=""];
$ dot -Tpng -o test.png test.dot
Warning: No loadimage plugin for "ps:cairo"
$ file test.png
test.png: PNG image data
(0007450)
ellson (reporter)
2010-02-16 15:47

 My bad. The ghostscript plugin was getting built but not packaged. Generating new packages now...
(0007467)
ellson (reporter)
2010-02-17 16:12

 Status update: The graphviz update is stalled pending a rebuild of ghostscript to use /opt/csw/X11/lib/

Ref: Mantis 0004288
(0007945)
skayser (administrator)
2010-05-25 21:40

 John, I have revisited this issue and the related bug against ghostscript. Not sure, why ghostscript was needed to be rebuilt against CSW's X11 ... but this might have changed: libXrender is now available again in version that links against vanilla X11 and installs in /opt/csw/lib (libxrender), while the version which links against CSW's X11 and which installs to /opt/csw/X11/lib was moved to a separate package (cx_libxrender).

Would you mind to have a look again?
(0010527)
laurent (manager)
2013-08-12 00:24

 GraphViz was updated to the latest version, however, it seems the files required to reproduce this test are not available anymore.
Closing as I can't check it, however, I might take another look if needed.

Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker