On Sun, Feb 02, 2003 at 04:11:41PM +0000, Aaron Trevena wrote: > > From: John Edstrom <[EMAIL PROTECTED]> > > On Fri, Jan 31, 2003 at 11:40:24PM -0600, Lars Clausen wrote: > > > On Fri, 31 Jan 2003, John Edstrom wrote: > > > > I'm thinking of spitting out some data as digraphs. I looked at the > > > > xml output from simple graphs and think that I can figure it all out, > > > > but I'd rather spare myself the learning experience. > > > > > > Have you looked at the various programs available in the Links section of > > > the webpage? > > > > > > > Yes, but only briefly. I"m still just casing the joint at this point. > > AutoDia is the closest that I've seen to what I want, but I'm not > > really interested in UML. > > Cool - what else would you be interested in. I happen to be hacking > autodia this weekend and am working on dia->graphviz and vice versa. > Hopefully I can use similar code/logic to allow graphviz, argouml and dia > to interact.
Basically I'm just interested in labeled ellipses connected by labeled lines having an arrow on one end. Very simple stuff. The perl Graph package has a dot writer class that generates dot files OK. So far my biggest concern with a dot2dia transformation is that dot uses splines and dia doesn't. Some of dot's edges get pretty baroque in complex graphs and arcs and polylines can't do equivalently tortuous paths as well. > > As far as most of the autodia code is concerned diagrams are just > diagrams containing nodes and relationships - its should be easy enough to > add some classes or re-organise the internals so that different diagrams > with different types of nodes and edges can be produced/processed. > > > Layout is my main concern, more than rendering or manipulation. I use > > the perl Graph::Directed module which, happily enough, writes xml > > and/or 'dot' files ( from the graphviz package). With the right > > arguments dot will figure out a reasonably well-balanced layout for > > the digraph and dump the coordinates of the nodes and edges. > > I have just been looking at this, I have already done some simple > calculations to work out aproximate coords for dia diagrams that autodia > uses already. I considered doing that. But in arbitrarily complex graphs the arrangement of the nodes and edges gets difficult. Dot does a pretty good job and I figure that it would take a lot of work to do better. > > > I figure it shouldn't be too difficult to convert or rescale the > > dot-calculated coordinates into dia coordinates which would give me a > > better renderer of the same graph. If that's the case then my strategy > > is to convert from dot >>-> ( xml | xsl ) >>-> dia.xml. > > Hopefully autodia 1.4 will allow for dia ( not laid out) -> dot -> dia > (laid out). I don't know how much time you have to hack perl - but it > would probably be easier to transform dot to dia using perl than XSLT > which is unwieldy for most tasks beyond rss to html. That's probably true. There is a strong case to be made for at least a dot2dia standalone module or program. I haven't had a chance yet to figure out the best way to partition my particular problem. I'm only shopping around at this point. FWIW, here are my thoughts so far: This graph thing is only a part of a larger project. The core object is an automaton/digraph which will be subclassed for other purposes; the graph will govern the evolution and behavior of the object inheriting it. The display part is strictly secondary, only as a convenient method to see what the machine looks like and not have to debug structure by reading oodles of text. Also there is a possibility of a gaphic constructor so that complex machines can be designed by dragging & dropping sub machines into a larger composite automaton. The object itself will be described, stored and maninpulated via XML. So there will be a definitive XML description of the digraph part of the object available to begin with. So, for rendering, the first step will necessarily be an XML ( | XSL ? ) >>-> something transform of some sort anyway. What attracted me to dia in the first place was its ability to accept XML. It may also be desirable to be able to import externally derived machine designs into the object and I see that being XML as well. If I go with graphic machine design I'll also want to import the result via XML. The object will have an xml_graph_in method which will ignore all graphic information and an xml_graph_out method which will emit no graphic information. An XSL filter would work well at this interface, I think. That way dia could be used to edit the machine and not just rendering it. All that I'd need for rendering are some reasonable metrics for the overall layout. Right now I'm thinking that since an XML|XSL transform of just the nodes and edges to dot is simple then a good way to go would be to have a dot2dot transform pipe which would add the layout metrics to the nodes and edges and then, using perl, I'd just normalize those integer coordinates to floats between 0 and 1 and then put that normalized abstract layout into XML. Then that layout would be exported to almost any other format by renormalizing to whatever coordinate system the target needs. The actual arithmetic would almost certainly be done best in any XML-aware language rather than XSL. But I think that the other stuff is probably best done with XSL since each target will have different constraints. For example, dia knows about shapes, but not about nodes while, dot uses nodes where the shape is just an attribute of the node. I have no idea what other packages may require. I'd also like to see the final rendering be driven by XSL and that step would control minor things like line type, line thickness, color, font, etc., maybe more such things that will change often and oughtn't require recoding the perl module. At this point I can't say where rendering will take place. Possibly in a java applet, maybe an FO transform to pdf... who can say. I just don't want to restrict options at this point and XML is good for that. That's how I see XML fitting into the Great Scheme of (my) Things. > > Anyone wanting to discuss dia related tools like autodia might want to That may be a good idea. Its already drifting away from dia per se and perhaps should be continued elsewhere. I'm only responding here because I figured that dia folk may be interested in knowing how outsiders are thinking about dia. > email me off list, as I would like to set up a site / list for such > topics. I hope that connecting users and develoeprs of graphviz, dia, > argouml and the like would make for cooler tools and better integration. > Failing that I can just use everybodies code in my plan to take over the > world *cough*. > > regards, > > A. > > -- > Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant > AutoDia --- Automatic UML and HTML Specifications from Perl, C++ > and Any Datasource with a Handler. http://droogs.org/autodia > -- John Edstrom _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
