|Anonymous | Login||2017-11-23 00:45 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002203||graphviz||Dot||public||2012-02-25 08:52||2012-02-27 18:08|
|Summary||0002203: xdot output contains wrong edge render information when using attribute splines != spline|
|Description||The _draw_ attribute of transition A --> E in the generated output is |
A -> E [.... _draw_="c 9 -#000000ff B 7 111 144 122 128 135 108 135 108 135 108 137 73 138 46 ", ....];
which uses drawing type 'B', which is B-spline.
According to the documentation http://www.graphviz.org/content/output-formats#dxdot [^] I assume it should be 'p' as used by the nodes or 'L'.
In the opposite does the _draw_ attribute of the 'A' node uses the expected type 'p'
A [... _draw_="c 9 -#000000ff p 4 126 180 72 180 72 144 126 144 ",...];
|Steps To Reproduce||run |
dot -Tpng -o polyline.png polyline.dot
-> png file shows rendered polyline (see transistion A --> E)
dot -Txdot -o polyline-xdot.dot polyline.dot
|Additional Information||The problem with the current behavior is that it prevents the usage of graphviz as external node and edge placement engine for graphical applications. |
This problem has been detected while evaluating graphviz as external placement engine for umbrello http://uml.sourceforge.net/ [^]
|Tags||No tags attached.|
|Attached Files|| polyline.dot [^] (140 bytes) 2012-02-25 08:52|
polyline.png [^] (6,362 bytes) 2012-02-25 08:53
polyline.xdot [^] (2,434 bytes) 2012-02-25 08:53
It also looks like that the content of the pos attribute for the A --> E transition contain b-splines control points
pos="e,45.413,108.41 80.831,143.83 72.285,135.28 61.944,124.94 52.62,115.62",
where it should have polyline too ?
The documentation only specify b-splines as possible argument, so it may be intentional.
The uniform use of B-splines is intentional. Although the low-level graphics model knows about polylines, splines, etc., the internal data structures for edge representation only allows a list of cubic B-splines. Even if we converted this to use a typed representation, there is the problem of the format of the pos attribute. To allow polylines, we would have to extend its format or add auxiliary attributes. The only way to do this without breaking much old code would be to add, perhaps optionally, a parallel pos attribute that would handle polylines.
A possible workaround would be to check the splines type and if it is polyline, then the polyline is determined by the points pos[i], where i=0 mod 3 and the array pos represents the points specifed in the pos attribute.
|2012-02-25 08:52||rhabacker||New Issue|
|2012-02-25 08:52||rhabacker||File Added: polyline.dot|
|2012-02-25 08:53||rhabacker||File Added: polyline.png|
|2012-02-25 08:53||rhabacker||File Added: polyline.xdot|
|2012-02-25 09:02||rhabacker||Note Added: 0000192|
|2012-02-27 18:08||erg||Note Added: 0000196|
|2012-02-27 18:08||erg||Severity||important => feature|
|2012-02-27 18:08||erg||Status||new => acknowledged|
|MantisBT 1.2.5[^] Copyright © 2000 - 2011 MantisBT Group|