Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002372graphvizOutput Generationpublic2013-09-20 04:392013-12-05 11:02
Assigned Toerg 
Platformx86_64OSOS XOS Version10.8.4
Summary0002372: xdot output believes pad defaults to 0
DescriptionThe pad attribute is documented to have a default value of 0.0555 (inches, equals 0002091:0000004 points). However when no pad attribute is specified, xdot output behaves as though the default is 0.

From a graph that does not specify pad:

    graph [_draw_="c 9 -#fffffe00 C 58 -(33.03 23.43 8.11 27 18 32.45 2 0 7 -#ffffff 1 7 -#000000) P 4 0 0 0 36 54 36 54 0 ",

From the same graph, only modified to specify the default pad=0.0555:

    graph [_draw_="c 9 -#fffffe00 C 57 -(34.06 24.36 9.5 27 18 38.01 2 0 7 -#ffffff 1 7 -#000000) P 4 -4 -4 -4 40 58 40 58 -4 ",

Note not only the difference in the coordinates of the background polygon, but also the difference in gradient coordinates and radii.
Steps To Reproducedot -Txdot gradient-bgcolor.gv
dot -Txdot gradient-bgcolor2.gv
TagsNo tags attached.
Attached Files? file icon gradient-bgcolor.gv [^] (104 bytes) 2013-09-20 04:39
? file icon gradient-bgcolor2.gv [^] (92 bytes) 2013-09-20 04:39
? file icon bg.gv [^] (79 bytes) 2013-11-25 22:30
? file icon bg.gv.xdot [^] (350 bytes) 2013-11-25 22:30
png file icon bg.gv.png [^] (2,157 bytes) 2013-11-25 22:30

- Relationships

-  Notes
User avatar (0000544)
ryandesign (reporter)
2013-09-20 04:41

Some confused Mantis formatting in the description. I wanted to say the default pad is "0.0555 (inches, equals approx. 4 points)".
User avatar (0000546)
ryandesign (reporter)
2013-09-24 01:45

There's an additional problem with the xdot encoding of the background polygon, which has to do with the pen width. By experimentation I worked out that Graphviz expects any polygon (or other filled shape) to be both filled and stroked. However if the background polygon is stroked, then it is too wide and too tall, by the pen width, since a stroke straddles the border of the shape, so 1/2 of the pen width will be inside it and 1/2 of the pen width will be outside it. To solve this, the background polygon should not be stroked. To do this, xdot output should set the pen color to fully transparent, e.g. "c 9 -#ffffff00". An alternative would be to specify pen width 0 ("S 15 -setlinewidth(0)"), but that would be an additional 22 bytes of output, v.s. setting a transparent pen color which would only be an additional 2 bytes (since xdot output already includes a pen color equal to the background color).
User avatar (0000589)
erg (administrator)
2013-10-30 12:43

The documentation is incorrect. The default pad value is output-specific, with all concrete output having pad=4 while dot and xdot have pad=0. The idea is that real images would take kindly to a small margin, while the abstract output gives a tight boundary on the drawing, so that downstream manipulations can use the actual size of the drawing. So, I can fix the documentation or reset the default pad for dot and xdot. I prefer the former.

The second problem shouldn't arise if you assume you always start with penwidth=1 until you encounter a S op resetting the pen width. Note that for gradient backgrounds, xdot does start with a transparent pen color.

Someday, it would be nice to extend the graphviz graphics model to allow fill without stroking to avoid the transparent pen kludge. It would also be worthwhile to pull penwidth out of style and give it its own op, in the same way we introduced the explicit penwidth attribute.
User avatar (0000603)
ryandesign (reporter)
2013-11-25 22:30

Sorry for my delay in responding; I didn't receive email notification of your above reply until today.

Canviz is intended to be a drop-in replacement for a PNG (with output as close to a Graphviz PNG as I can make it), so I think I'll keep my code the way it is and continue to consider the default pad value 4 not 0.

In Canviz I do have penwidth start at 1, and the problem remains as described. I'll attach an example bg.gv which makes a 1in ✕ 1in node on a 1in ✕ 1in red background on a 3in ✕ 3in canvas at 72dpi. I ran this:

dot bg.gv -Txdot -obg.gv.xdot -Tpng -obg.gv.png

In the Graphviz-generated PNG, the background is exactly as requested: a 72px ✕ 72px red square with fully transparent pixels all around. But the xdot output says these commands should be used to draw that background:

c 7 -#ff0000 C 7 -#ff0000 P 4 0 0 0 72 72 72 72 0

This means: fill the 72px ✕ 72px square with red, and then stroke it with red (with the default pen width of 1). Since a stroke straddles the outline of the shape, 1/2 of the stroke will end up inside the shape where it makes no difference if the color is fully opaque, and 1/2 of the stroke will end up outside the shape where it will produce 50% opaque red pixels. The solution is to use a penwidth of 0 or a transparent pen color for the background.
User avatar (0000625)
erg (administrator)
2013-12-05 11:02

We never specified precisely the interplay between the coordinate system and the graphics primitives. There is the standard problem of how real numbers get mapped to the integral world of pixels. In particular, should a rectangle drawn with corners (0,0) and (72,72) be contained within a filled rectangle with the same corners. In any case, given that the background should just be a fill and nothing more, it is reasonable to turn off the stroke operation by making the pen color transparent.

- Issue History
Date Modified Username Field Change
2013-09-20 04:39 ryandesign New Issue
2013-09-20 04:39 ryandesign File Added: gradient-bgcolor.gv
2013-09-20 04:39 ryandesign File Added: gradient-bgcolor2.gv
2013-09-20 04:41 ryandesign Note Added: 0000544
2013-09-24 01:45 ryandesign Note Added: 0000546
2013-10-30 12:43 erg Note Added: 0000589
2013-11-25 22:30 ryandesign Note Added: 0000603
2013-11-25 22:30 ryandesign File Added: bg.gv
2013-11-25 22:30 ryandesign File Added: bg.gv.xdot
2013-11-25 22:30 ryandesign File Added: bg.gv.png
2013-12-05 11:02 erg Note Added: 0000625
2013-12-05 11:02 erg Assigned To => erg
2013-12-05 11:02 erg Status new => resolved
2013-12-05 11:02 erg Resolution open => fixed

MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker