Mooffie n/a schrieb:

>Arndt Roger Schneider wrote:
>  
>
>>Mooffie wrote:
>>    
>>
>>>(You believe the object graph DrX produces can be generated by existing 
>>>documentation tools? I'm not aware of similar tool(s). 
>>>      
>>>
>>doxygen generates a similar [...]
>>    
>>
>
>No, it doesn't.
>
>Doxygen, and similar tools, generate diagrams that are *not* suitable 
>for Ruby:
>
>* Ruby's object model is diagrammed best by using a grid where the 
>various lines of inheritance are shown orthogonal (in 
>parallel/perpendicular). That's what DrX does. Doxygen is good for 
>languages like C++ and PHP, whose class inheritance is mostly a tree. 
>Ruby's object model isn't a tree, it's a graph (and a circular one!). 
>And unless this is taken into careful consideration when generating the 
>DOT source, a very hard-to-read (and thus useless) diagram will come 
>out. The only reason people _might_ feel good with Doxygen diagrams is 
>because it blissfully ignores more than half of Ruby's object model (the 
>singletons hierarchy, and the run-time part).
>
>* In Ruby, much of the object model is generated at run-time. Static 
>diagramming tools are blind to this. For example, look at the DataMapper 
>diagram. Static tools like 'rdoc' can't tell us in which classes the 
>gazillion modules end up 'include'd.
>
>
>
>
>As for GraphViz's SVG problem:
>
>I think I vaguely remember that the font names it puts in the SVG file 
>aren't standard ones. Perhaps fixing this will alleviate the problem. 
>I'll need to investigate this. I certainly want SVG support. Let me know 
>if you have more ideas on this and similar subjects.
>
>Note that I'm not using Tk's canvas to draw the graph. I show the bitmap 
>GraphViz produces.
>  
>


Send a medium to large compressed svg via email to  me, then  I take a 
look at it.
I suspect the graphviz/svg issue can be solved inside the DOM-tree after 
graphviz generated
the svg.

-roger