|Anonymous | Login||2017-11-19 10:59 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002372||graphviz||Output Generation||public||2013-09-20 04:39||2013-12-05 11:02|
|Platform||x86_64||OS||OS X||OS Version||10.8.4|
|Summary||0002372: xdot output believes pad defaults to 0|
|Description||The 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 Reproduce||dot -Txdot gradient-bgcolor.gv|
dot -Txdot gradient-bgcolor2.gv
|Tags||No tags attached.|
|Attached Files|| gradient-bgcolor.gv [^] (104 bytes) 2013-09-20 04:39|
gradient-bgcolor2.gv [^] (92 bytes) 2013-09-20 04:39
bg.gv [^] (79 bytes) 2013-11-25 22:30
bg.gv.xdot [^] (350 bytes) 2013-11-25 22:30
bg.gv.png [^] (2,157 bytes) 2013-11-25 22:30
|Some confused Mantis formatting in the description. I wanted to say the default pad is "0.0555 (inches, equals approx. 4 points)".|
|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).|
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.
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.
|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.|
|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|