Re: [Doxygen-develop] [Doxygen] SVG/Layout

[Fred P. <j2...@ho...>]

Hi Dimitry,

> > >> I was wondering about your layout/routing algorithm for the DOT 
>program
> > >> output.
> > >>
> > >>
> > 
> >http://j2k.sourceforge.net/docs/example/classVectorialImageFileIOStream.html
> > >> http://j2k.sourceforge.net/docs/example/classJFileInStream.html
> > >>
> > >> i.e. The way you draw arrows and box: positionate them, draw them.
> > >> I was reading your source code (diagram.* dot.*)
> > >>
> > >> bool TreeDiagram::layoutTree(DiagramItem *root,int r);
> > >> void TreeDiagram::moveChildren(DiagramItem *root,int dx);
> > >> void TreeDiagram::computeLayout();
> > >> uint TreeDiagram::computeRows();
> > >> void TreeDiagram::computeExtremes(uint *maxLabelLen,uint *maxXPos);
> > >
> > >For your info. Doxygen has a build in diagram generator (TreeDiagram in
> > >src/diagram.*) which can only do trees. All new development is done 
>with
> > >the DOT tool (as shown by your links), where doxygen only generates the
> > >graph description and DOT takes care of all the layouting.
> >
> > That's what I figured out yesterday... :-|
> >
> > Okay, so maybe you can merge my Version 2 or 3 of SVG for the non-dot
> > algorithm.
>
>I prefer to leave the non-dot algorithm as is for now and focus on the dot 
>part only.

Does this means you don't want 3rd party users (like me)
modify the non-dot part and provide patch?

If you have any source code quality requirements or source code taste let me 
know...

Currently, the simplest way for me 'right now' is to enhance the old algo,
until I merge or modify dot crazily.

I need to produce UML diagram like these with 'all the extra information' in 
it.
In other words, the SVG diagram must know that a "function" is a function,
it must know where it is in the code (LOC/offset), the parameters, etc.
in XML format or CDATA embedded inside SVG.
Samething for namespace, class, function, variable.

Think of it, as an 'intelligent' diagram.
Obviously the level of verboseness should be configurable using the Config 
file

Currently, Doxygen produce "static" document with some clickable map areas,
the goal I try to accomplish is to create "dynamic" plus-value enhanced web 
documents.

Basically, someone could:
- Drag and drop class around
- Add/Remove class/functions/variables
- Add/Remove/Modify source code
- Add/Remove links
- Reorganized things
- Create new diagrams views explicitly and maintain those.
- Visualize changes from CVS from v1.4 to 1.5 what was changed graphically.
- Commit those graphical change back into data files, patches and hopefully 
source code
to be round-trip engineered.

Basically, what I need from your parser is to be way more VERBOSE on what it 
knows
and spit out XML code out of it within the SVG code.

The second thing I would need is that the generated changes would be parsed 
back
when I call doxygen again on the same project.

One way would be to add C++ comment tags ala JavaDoc or have an external 
metafiles.


> > and add output support for SVG for the DOT version.
> >
> > It might be cleaner to have a derivate SvgImage : public Image class 
>with
> > virtual function
> > and have a switch or Factory to generate PNG or SVG or BOTH for the 
>non-dot
> > version.

Another simpler way, would be to have a if( Config...SVG ) statement around 
the SVG block.

> >  2,885  03-21-04  5:09a instream0.svg
> >  3,390  03-21-04  5:06a instream2.svg
> >    994  03-21-04  4:57a instream1.svgz
> >    953  03-21-04  5:09a instream3.svgz
> >    744  03-21-04  4:54a classInStream__coll__graph.dot
> >  1,028  03-21-04  4:46a classFileInStream__coll__graph.dot
> >  1,792  03-21-04  4:46a classFileInStream__coll__graph.png
> >  1,027  03-21-04  4:46a classInStream__coll__graph.png
> >
> > As you can see, the generated SVG file is bigger than png,
> > but not when gzip -9 -Sz, which in that case it's smaller.
> > If you produce "cleaner" code  you save 600 bytes uncompressed and 40 
>bytes
> > compressed.
> >
> > The generated grouping is not bad,
> > except that you lose the context inside the SVG file.
> >
> > So we need a couple of CONFIG options to keep the context in the DOT
> > generated version.
> > Some tweaking need to be done in the DOT SVG output, I'll try to contact
> > DOT team.
> >
> > I also need to change the colors of the UML output, I don't like it! =P
> > I want an IBM Rational Rose color scheme and icons.
> >
> > Something that looks like this:
> > http://j2k.sourceforge.net/UML/NTO/TrainLayoutTest_Big.png
>
>Looks good indeed.
>
> > generating an SVG UML diagram that can be "web-based" edited like this:
> > http://j2k.sourceforge.net/svg/august/umled12k.svg
> >
> > I have those "optimized" for SVG and also in GIF.
> >
> > For GIF See:
> > http://j2k.sourceforge.net/svg/attribute.gif
> > http://j2k.sourceforge.net/svg/function.gif
> >
> > Also, there should be a way to 'tweak' the anti-aliasing and fonts.
> > I prefer aliasing or non-anti-aliasing for shapes and small fonts, see:
> > http://j2k.sourceforge.net/svg/box.gif
> > http://j2k.sourceforge.net/svg/box2.gif
> > http://j2k.sourceforge.net/svg/box.svg
> >
> > UML buttons:
> > http://j2k.sourceforge.net/svg/btn_all4.svgz
> >
> > My current layout scheme (not based on doxygen nor dot):
> > http://j2k.sourceforge.net/svg/new_layout/layout5.js.svg
> >
> > >> I'm just wondering what are the "strict" dependancies on those...
> > >>
> > >> Also, I wanted to add SVG output support via
> > >> 1) external SVG files (instead of PNG)
> > >> 2) ActiveX embedded SVG within html (for ASV3 and ASV6pr1)
> > >> [ Adobe SVG Viewer http://www.adobe.com/svg/ ]
> > >
> > >Recent version of DOT can already do SVG output, so it is probably very
> > >easy to add SVG as an output format (besides jpg, gif, and png).
> >
> > Yeah I saw that. =)
> >
> > I guess I'll dig into DOT code, but it's kinda complicated a bit... =(
>
>I would try without requiring modification first and see how far one could 
>get.

Sure, but we might need to patch DOT so it can take/parse stuff that is not 
graphical
to be embedded in the SVG target, since currently you say node, edge,
but you don't say what's a node is about...

> > >> Looking at the doxygen source doxygened callgraphs,
> > >> modifying diagram/dot/image should probably be sufficient,
> > >> but I would like to make a patch and submitted to you,
> > >> so others can benefit from it.
> > >>
> > >> It's not hard at all to have SVG, it's just a question of duplicating
> > >the
> > >> code
> > >> and make the appropriate changes... see below.
> > >
> > >I think that with using dot, duplication can be avoided.
> >
> > Sure, but I might consider linking dot into doxygen for speed issue... 
>as a
> > first step.
> > I'm generating lots of stuff from this (100MB) just try doxygen doxygen 
>=^P
> > Maybe skipping the DOT format generator, system calls, DOT format parser
> > and provide direct linking would help.
> >
> > In such case, providing the interface to link GraphViz would be 
>sufficient
> > with a proper Config option DOT_LINK_LIBRARY
> >
> > Maybe I have to look if any license issues?
> > http://www.gnu.org/licenses/gpl.html
> > http://www.research.att.com/sw/tools/graphviz/license/
>
>The AT&T license is much more restrictive than the GPL, so there are 
>license
>issues, which is why I do not want to link against dot.

I can see the issue that's why I raise it, but you could not explicitly link 
against,
neither providing binaries for such thing, but provide the API for 
developers.

> > >> I'm just confuse where what is what and what is needed to perform 
>things
> > >> to translate layout into JavaScript, the overall minimal Qt
> > >infrastructure
> > >> for those class was translatate in JS, including a good part of them.
> > >>
> > >> Here some SVG possible things to do:
> > >>
> > >> If you were kind enough to give me some hint,
> > >> I would really appreciate.
> > >
> > >I suggest to look src/dot.cpp and look for places where 
>DOT_IMAGE_FORMAT
> > >is used. I think SVG could be added to the possible formats, and then 
>it
> > >is just a matter of tweaking the output (if needed at all).
> >
> > In my case that's needed. =)
> >
> > Is that too much to ask for release v1.3.7 ? ;-)
> > { discreetly crossing fingers... 8-) }
> >
> > Let say a 'quick' SVG add-on release with few Config options?
>
>Could be possible, but the focus must be: minimal changes, even though it
>might be tempting to change things, let's not do that for the first release
>unless absolutely required.

Well, for me everything is required, the thing is I prefer to have my source 
code being
in sync with you in CVS, than having to patch around for every release you 
make.

Any comments on the code I sent you so far?

Any comments on what I'm trying to achieve?! ;-)

Sincerely yours,
Fred.

_________________________________________________________________
Add photos to your e-mail with MSN Premium. Get 2 months FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines