>>>> But it's just the implication that this is impossibly difficult that 
>>>> bothered me. How long can it possibly take to try all possible 
>>>> permutations of 10 nodes?
>>>
>>> Really, try implementing a brute force algorithm and see for yourself 
>>> how it scales.  Ten nodes may work, but what about twenty?
>>
>> Ah, I see. So you mean the problem is that *other people* might try to 
>> draw big graphs with it?
> 
> Heh, yeah I suppose that's the idea.  I think that "works with graphs of 
> up to 12 nodes!" is maybe not the best feature for a piece of software 
> to have.

I wonder how big the graphs they use it for are? I mean, you can only 
fit a small number of nodes in a single drawing anyway...

>> Trees that occasionally have nodes pointing back to their ancesters, 
>> yes. ;-)
> 
> Ahh, that makes sense.  If I remember you didn't want to order of the 
> nodes to be able to change, in which case you really don't have as much 
> choice

Yeah, I basically already know the relative XY positions of the nodes, I 
just need to put in appropriate spacing and draw the edges nicely. (I 
haven't figured out how to control font selection with Cairo yet!)

>> Weirdly, GraphViz manages to come up with some *really* strange 
>> layouts - and refuses to obey my hints to lay the graph out the way I 
>> actually want it...
> 
> I haven't actually used the program, so I unfortunately can't be of much 
> help here.  Since you have a small graph and pretty specific formatting 
> requirements, what happened with the app you were writing yourself to do 
> the layout?

I think I'm going to reimplement it in light of what I've learned from 
GraphViz. (E.g., it uses invisible nodes that don't show up on the 
drawing, but *do* help it to route edges so they don't collide. I can 
copy that easily enough.)

Post a reply to this message