Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002203graphvizDotpublic2012-02-25 08:522012-02-27 18:08
Reporterrhabacker 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Summary0002203: xdot output contains wrong edge render information when using attribute splines != spline
DescriptionThe _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 Reproducerun

dot -Tpng -o polyline.png polyline.dot

-> png file shows rendered polyline (see transistion A --> E)

run

dot -Txdot -o polyline-xdot.dot polyline.dot

inspect polyline-xdot.dot

Additional InformationThe 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/ [^]
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT
VERSION2.29.0 (20120225.1310)
Attached Filesdot file icon polyline.dot [^] (140 bytes) 2012-02-25 08:52
png file icon polyline.png [^] (6,362 bytes) 2012-02-25 08:53


? file icon polyline.xdot [^] (2,434 bytes) 2012-02-25 08:53

- Relationships

-  Notes
User avatar (0000192)
rhabacker (reporter)
2012-02-25 09:02

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.
User avatar (0000196)
erg (administrator)
2012-02-27 18:08

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker