doxygen-develop — List for discussing new features, submitting patches, etc.

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

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

>Hi Fred,
>
>Sorry for the slow reply.

That's okay.

>On Thu, Mar 25, 2004 at 07:56:40PM +0000, Fred P. wrote:
> > >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?
>
>You can always provide a patch if you think that the best approach is to
>modify the non-dot part.

Currently, I sent you complete file replacement instead of a "patch"...

"
For patches please use "diff -uN" or include the files you modified.
If you send more than one file please tar or zip everything,
so I only have to save and download one file.
"

Anything else?

I'll clean it up and resent it to you, I will need a Config_getBool() thing.


> > If you have any source code quality requirements or source code taste 
>let
> > me know...
>
>If you can make it look like the rest of the code then that would be nice.

That's fine, that's what I did, hopefully...

>Also I don't like it if you would introduce new dependencies on external 
>libraries.

Currently, I'm not.

But if I was to do so, that would be #ifdef USING_DOT_LIB .... #endif
so the thing compiles anyway without it, but developper could do 
otherwise...
I really don't like to break things up... by experience ;-)

In other words, you could build doxygen AS IS without it.

However, you can use DOT as a library.
You can also change it as needed (see AT&T license)
as long as you provide them your changes too.
The entire thing is documented.

I also found out that we can use something like pos=  arguments in neato
to fix node in place before applying the neato algorithm.

I also found out that we can 'extend' the DOT internal structure
to add more 'custom' data into nodes/edges.

So, if I was to use DOT as a internal or external library (libagraph.so)...

http://www.research.att.com/sw/tools/graphviz/refs.html
http://www.research.att.com/sw/tools/graphviz/Agraph.pdf
http://www.research.att.com/sw/tools/graphviz/libguide.pdf

I could simply feed it to neato in the described steps:

int nG; /* number of vertices in g */
neato_init_graph(g);
nG = scan_graph(g);
shortest_path(g, nG);

/* circuit_model(g,nG)) */
initial_positions(g, nG);
diffeq_model(g, nG);
solve_model(g, nG);
adjustNodes(g);
spline_edges(g);
dotneato_postprocess(g, dot_nodesize);

I might also simply try to go as far as I can go with the DOT file format, 
instead... will see.
Currently, I'm still investigating what would be "the best approach".

> > 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

That's trivial, simple JavaScript/SVG.

> > - Add/Remove class/functions/variables

The difficult part is to calculate (x,y) where the text should go in 
JavaScript/SVG
and reajust the length of the box in consequence.
Basically, getBBox for the current font, would be easier if hard-coded,
since getBBox don't give accurate results on ASV3/6...

> > - Add/Remove/Modify source code

If it's generated, it could be edited using a CGI form,
you can also edit it using SVG, but scrolling/resizing text is still 
tricky/painful.

Currently, it would work like webmail clients, sort of.
I could also make it to accept diff/patch on the fly... as an option.

> > - Add/Remove links

Just delete it or make it invisible from the SVG using DOM.
This is important since people will want to duplicate diagrams
and "simplify them" for visualization purposes.

In situation X, I want to create a new diagram Y and
highlight A --> B --> C relationship or some design patterns,
so I delete everything else which is useless for that given situation.

> > - Reorganized things

If [pos=] works as stated, figure 8, page 9
http://www.research.att.com/sw/tools/graphviz/neatoguide.pdf

graph G {
n0 [ pos = "0,0!" ];
n1 [ pos = "2,0" ];
n2 [ pos = "2,2!" ];
n0 -- n1 -- n2 -- n3 -- n0;
}

that's easy, just drag'n'drop things around with JavaScript and with
XForms or XML-RPC, you can save that information.

We would have to find a way to feed that information back into Doxygen...

Any preference?
Should it be internal or external to some header files or could be both!?
Syntax: dot like, xml like, something else, something easy for flex? :-P

The easiest?
External file with simplified pseudo-static XML,
basically something flex could parse.
In other words, attributes would only be mandatory and accepted in a 
specific order.
Another way a perl script server with XML::Simple doing the conversion.

> > - Create new diagrams views explicitly and maintain those.

Combination of above.

> > - Visualize changes from CVS from v1.4 to 1.5 what was changed 
>graphically.

That's more tricky, but I'm working on it.
The easiest way would be parallel view,
doxygen v1.4 in left frame and doxygen v1.5 in right frame,
with a bottom frame for chosing the version comparision... let say.

> > - Commit those graphical change back into data files, patches and 
>hopefully
> > source code to be round-trip engineered.

Combination of above.

>That's quite a lot. But if you can add all this than that's definitely 
>nice.

Hopefully, yes... if I want to graduate at some time! =P
This is mostly research stuff, but I thing that your framework is quite nice 
to work with
and it would be useful for lots of people.

I might also submit you some "documentation" patch or documents or diagrams
as I find my way into your source code, to help others.
Some of it is "obvious" but some part is just a bit tricky. ;-)

BTW, it might be useful to have SHTML or PHP3/4 output to reduce
the doxygen'ed doxygen output under 90-100MB so you could put it live on 
sourceforge
or simply cut off libpng, zlib and qtools from the generation process.
If you ever do that make the generation into many sub dir, else good luck
with ls, mv and rm...

(I had to write a perl script to ls, mv or rm these files! eek..)
"
[doxygen.docs]% ls c*
-bash: /bin/ls: Argument list too long
"

Also, if I want to add more "Config_getBool" fields I need to change:
config.h and config.l --> config.cpp

So, I will probably let you add those flex fields
and use HARD compile-time #ifdef in the mean time.

Sincerely yours,
Fred.

_________________________________________________________________
Add photos to your messages 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

Re: [Doxygen-develop] problem with doxywizard 1.3.6

[Andy H. <And...@au...>]

Dimitri van Heesch wrote:

> Seems like a Qt/moc problem. Are you sure the moc you use (which moc) is
> the one coming with qt-3.1.1?
> 
> Regards,
>   Dimitri

Dimitri,

	You were right. I have both qt2 and qt3 installed. Moc is not in my 
path, but configure was picking up qt2. I made a change to the configure 
script to pick up the first qt that it finds. It was finding qt3, but 
then testing for qt2. Here a patch that worked for me.

Thanks for your help.

Andy


*** doxygen-1.3.6/configure.orig        Mon Apr 12 11:07:56 2004
--- doxygen-1.3.6/configure     Mon Apr 12 11:53:42 2004
***************
*** 232,245 ****
         fi
       fi
     fi
!   if test -d "/usr/lib/qt2/lib"; then
       if test -d "/usr/lib/qt2/include"; then
         if test -x "/usr/lib/qt2/bin/moc"; then
           QTDIR="/usr/lib/qt2";
         fi
       fi
     fi
!   if test -d "/usr/lib/qt/lib"; then
       if test -d "/usr/lib/qt/include"; then
         if test -x "/usr/lib/qt/bin/moc"; then
           QTDIR="/usr/lib/qt";
--- 232,245 ----
         fi
       fi
     fi
!   if test -z "$QTDIR" && test -d "/usr/lib/qt2/lib"; then
       if test -d "/usr/lib/qt2/include"; then
         if test -x "/usr/lib/qt2/bin/moc"; then
           QTDIR="/usr/lib/qt2";
         fi
       fi
     fi
!   if test -z "$QTDIR" && test -d "/usr/lib/qt/lib"; then
       if test -d "/usr/lib/qt/include"; then
         if test -x "/usr/lib/qt/bin/moc"; then
           QTDIR="/usr/lib/qt";

Re: [Doxygen-develop] problem with doxywizard 1.3.6

[Dimitri v. H. <di...@st...>]

On Sun, Apr 11, 2004 at 04:49:19PM -0500, Andy Howell wrote:
> Trying to compile this I get an error
> 
> moc/moc_doxywizard.cpp: In member function `void ConfigFile::changed()':
> moc/moc_doxywizard.cpp:204 invalid conversion from const char* tp `int'
> 
> Couldn't find anything in bugzilla about this. Maybe I Qt problem. I'm 
> running SuSE 8.1 with qt3-3.1.1

Seems like a Qt/moc problem. Are you sure the moc you use (which moc) is
the one coming with qt-3.1.1?

Regards,
  Dimitri

[Doxygen-develop] problem with doxywizard 1.3.6

[Andy H. <And...@au...>]

Trying to compile this I get an error

moc/moc_doxywizard.cpp: In member function `void ConfigFile::changed()':
moc/moc_doxywizard.cpp:204 invalid conversion from const char* tp `int'

Couldn't find anything in bugzilla about this. Maybe I Qt problem. I'm 
running SuSE 8.1 with qt3-3.1.1

Thanks,

	Andy

Re: [Doxygen-develop] DocBook Generator

[Dimitri v. H. <di...@st...>]

On Mon, Apr 05, 2004 at 04:20:15PM +0200, Oliver Fischer wrote:
> Dear developers of doxygen,
> 
> in one of our projects we use DocBook as main format for writing our 
> documentation. Since we aspire to use DocBook in as many places as we 
> could, I would like to write a DocBook extension to doxygen.
> 
> First at all I would like to know if this extension would be wellcomed 
> as contribution to doxygen.

I think they are.

> Secondly I would like to know, if some could assist me while 
> implementing the docbook extension, since I am not common with the 
> internal doxygen API.

You could also use the public API, either via the raw XML output or via
doxygen's XML parser, see addon/doxmlparser. I once started with this
but I never got beyond something very rudimentary due to a lack of time.
But maybe you can use it to get started, that's why I attached it.

Regards,
  Dimitri

[Doxygen-develop] Windows binaries available for Doxygen-1.3.6-20040324 in CVS

[Petr P. <Pr...@sk...>]

Hi,
  =20
If interested, you can download the doxygen binaries
compiled for MS Windows from
  =20
  http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/
  =20
This is the place where you should find also the next
releases.  The name of the archive is constructed=20
from the date of CVS release and looks like
doxygen_win32_2004mmdd.zip, where mm and dd is
month and day of releasing the version.
=20
The binaries are NOT created automatically, so it may
happen that some newer CVS sources were not compiled
because I am not present to do that or I forgot... ;)
  =20
Regards,
    Petr
=20
P.S. The translator report can be found in the file=20
     like tr2004mmdd.zip.


The excerpt from the translator report follows...

(1.3.6-20040324)

Doxygen supports the following 28 languages (sorted alphabetically):

Brazilian Portuguese, Catalan, Chinese, Chinese Traditional, Croatian,
Czech, Danish, Dutch, English, Finnish, French, German, Greek,
Hungarian, Italian, Japanese (+En), Korean (+En), Norwegian, Polish,
Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish,
Swedish, and Ukrainian.

Of them, 15 translators are up-to-date, 13 translators are based on
some adapter class, and 2 are English based.

----------------------------------------------------------------------
The following translator classes are up-to-date (sorted
alphabetically). This means that they derive from the Translator class
and they implement all 194 of the required methods. Anyway, there
still may be some details listed even for them. Please, see the
details for them:

  TranslatorBrazilian
  TranslatorChinesetraditional
  TranslatorCroatian
  TranslatorCzech
  TranslatorDanish
  TranslatorDutch
  TranslatorEnglish
  TranslatorFrench
  TranslatorGerman
  TranslatorHungarian
  TranslatorItalian
  TranslatorKorean
  TranslatorRussian
  TranslatorSerbian
  TranslatorSpanish -- Change the base class to Translator.

----------------------------------------------------------------------
The following translator classes need some maintenance (the most
obsolete at the end). The other info shows the estimation of Doxygen
version when the class was last updated and number of methods that
must be implemented to become up-to-date:

  TranslatorSwedish               1.3.3 	 4 methods to implement
  TranslatorPortuguese            1.3.3 	 4 methods to implement
  TranslatorJapanese              1.3.3 	 4 methods to implement
  TranslatorPolish                1.3   	11 methods to implement
  TranslatorSlovak                1.2.18	13 methods to implement
  TranslatorCatalan               1.2.17	14 methods to implement
  TranslatorSlovene               1.2.16	15 methods to implement
  TranslatorRomanian              1.2.16	15 methods to implement
  TranslatorChinese               1.2.13	17 methods to implement
  TranslatorUkrainian             1.2.11	18 methods to implement
  TranslatorGreek                 1.2.11	18 methods to implement
  TranslatorNorwegian             1.2.2 	44 methods to implement
  TranslatorFinnish               obsolete	91 methods to implement
   =20
--=20
Petr Prikryl (prikrylp at skil dot cz)
=20

=20

RE: [Doxygen-develop] DocBook Generator

[Ferdinand P. <fer...@ix...>]

Hi Oliver,

> From: Oliver Fischer [mailto:pl...@sn...] 
> 
> Dear developers of doxygen,
> 
> in one of our projects we use DocBook as main format for 
> writing our documentation. Since we aspire to use DocBook in 
> as many places as we could, I would like to write a DocBook 
> extension to doxygen.
> 
> First at all I would like to know if this extension would be 
> wellcomed as contribution to doxygen.
> Secondly I would like to know, if some could assist me while 
> implementing the docbook extension, since I am not common 
> with the internal doxygen API.

The easiest way would be to create a converting XSLT from the XML that is
usually possible to generate by doxygen. I created a convertor from the
doxygen XML into an ndoc XML to be able to finalize documentation in ndoc
and it was pretty straightforward (not finished yet though). If you are
familiar with XSLT it is the quickest way. Debugging of a native
documentation generator is harder than fixing a XSL template... But you can
decide what is the best for your needs.

Unfortunately I am not aware about the DTD.

Ferda

[Doxygen-develop] DocBook Generator

[Oliver F. <pl...@sn...>]

Dear developers of doxygen,

in one of our projects we use DocBook as main format for writing our 
documentation. Since we aspire to use DocBook in as many places as we 
could, I would like to write a DocBook extension to doxygen.

First at all I would like to know if this extension would be wellcomed 
as contribution to doxygen.
Secondly I would like to know, if some could assist me while 
implementing the docbook extension, since I am not common with the 
internal doxygen API.

Regards,

Oliver Fischer

[Doxygen-develop] question concerning scanner.l

[Benjamin Z. <bn...@ze...>]

hi,

i'm working on a patch to make doxygen support the eiffel language. 
however, i have some trouble understanding the way the entry-tree is 
created. so far parsing classnames works well and the inheritance hierarchy 
is nicely generated in the html output, but i don't manage to make doxygen 
output any method names. currently i'm trying to reconstruct the entry-tree 
from an c++ example which i have dumped (at least what i think is important 
of it) and analyzed by hand. i can't seem to find any major difference at 
this point. is there anything non-obvious i have to fulfill in order to get 
the methods listed in the output?

--
Benjamin Zeiss

[Doxygen-develop] Already Existing 200+ CPP files

[Subhabrata M. <sub...@ma...>]

Hi to all respected members:

This is Subho from Calcutta, India. I would be greatful if anyone can
suggest me something regarding Doxygen.

My question is:

Scenario: Already existing 200 + CPP files with C++ standard documentation
( // and /* ...*/ types)

I'm actually using Doxygen to extract the documentation part and do other
normal tasks of doxygen.


Steps I've followed:
Set INTERNAL_DOCS = YES in my <doxygen-confi-file>, EXTRACT_ALL = YES

In one CPP file, I have used the markups, @a, @param @class etc to extract
documentations. But it's not possible manually to do this for the whole
project !. The code is already there. It's not from scratch. What's the
solution in this situation ?

What I want :
SOME OPTION OR WHATEVER TO SET, SO THAT DOXYGEN WILL TAKE '//' parts from
the source code as comments to extract. I don't want to replace // with //<
in 50 thousand locations

Have I made my question clear ???. Please do reply ...

Eagerly waiting for your comment(s)

Thanks and Cheers !
Have a nice day ,
Sub.

RE: [Doxygen-develop] Q_PROPERTY working, more information would be helpful

[Randall, L. <l-r...@ti...>]

Dimitri,

Could we get rid of the RTF *sections* and extra CR/LF also?
Unnecessary sections are a BAD thing in an RTF/Word document!  I have to
strip the sections, and then strip all double CR in every document.  I
doubt that anyone really needs sections, but their creation could be
made optional.

Regards,
Larry Randall

-----Original Message-----
From: dox...@li...
[mailto:dox...@li...] On Behalf Of
Dimitri van Heesch
Sent: Monday, March 29, 2004 12:00
To: dox...@li...
Subject: Re: [Doxygen-develop] Q_PROPERTY working, more information
would be helpful

On Sun, Mar 28, 2004 at 01:22:15AM -0600, Marcus wrote:
> Replying to self...
>=20
> I can live without the scriptable and designable flags, since I can
get them=20
> at runtime, even though they would be nice to have.
>=20
> Noticed that Doxygen already takes note of whether properties are
readable or=20
> writable, but that it was not outputting that information. I do not
know=20
> exactly what the policy is on accepting patches and whether the
changes my=20
> patch makes to the output are cool, but I'm attaching it here.

Good, I'll include it in the next release.

Regards,
  Dimitri


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] Invalid XML attributes generated

[Dimitri v. H. <di...@st...>]

On Sat, Mar 27, 2004 at 12:35:10AM +0000, Marcus wrote:
> I ran into some problems processing the XML generated by Doxygen because under 
> certain conditions, it outputs attributes that contain < and > like the one 
> below:
> 
> <location file="<generated>" line="1"/>

That's a bug. Will be fixed.

Regards,
  Dimitri

Re: [Doxygen-develop] Q_PROPERTY working, more information would be helpful

[Dimitri v. H. <di...@st...>]

On Sun, Mar 28, 2004 at 01:22:15AM -0600, Marcus wrote:
> Replying to self...
> 
> I can live without the scriptable and designable flags, since I can get them 
> at runtime, even though they would be nice to have.
> 
> Noticed that Doxygen already takes note of whether properties are readable or 
> writable, but that it was not outputting that information. I do not know 
> exactly what the policy is on accepting patches and whether the changes my 
> patch makes to the output are cool, but I'm attaching it here.

Good, I'll include it in the next release.

Regards,
  Dimitri

Re: [Doxygen-develop] Q_PROPERTY working, more information would be helpful

[Marcus <ma...@my...>]

Replying to self...

I can live without the scriptable and designable flags, since I can get them 
at runtime, even though they would be nice to have.

Noticed that Doxygen already takes note of whether properties are readable or 
writable, but that it was not outputting that information. I do not know 
exactly what the policy is on accepting patches and whether the changes my 
patch makes to the output are cool, but I'm attaching it here.

So instead of just this:

<memberdef kind="property" id="classQButton_100" prot="public" static="no">

We get this:

<memberdef kind="property" id="classQButton_100" prot="public" static="no" 
readable="yes" writable="yes">


On Saturday 27 March 2004 11:39 pm, Marcus wrote:
> I see that Q_PROPERTY's are now implemented, at least in the XML output.
> However, the <property> tag does not indicate whether the properties are
> read-only, scriptable, designable.
>
> Is there any work going on for that part?

[Doxygen-develop] Q_PROPERTY working, more information would be helpful

[Marcus <ma...@my...>]

I see that Q_PROPERTY's are now implemented, at least in the XML output. 
However, the <property> tag does not indicate whether the properties are 
read-only, scriptable, designable.

Is there any work going on for that part?

[Doxygen-develop] Invalid XML attributes generated

[Marcus <ma...@my...>]

I ran into some problems processing the XML generated by Doxygen because under 
certain conditions, it outputs attributes that contain < and > like the one 
below:

<location file="<generated>" line="1"/>

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

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.
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.


  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

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... =(

> > 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/

> > 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?

Thanks!
Fred.

>Regards,
>   Dimitri

_________________________________________________________________
MSN Premium: Up to 11 personalized e-mail addresses and 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

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

[Dimitri v. H. <di...@st...>]

On Mon, Mar 15, 2004 at 09:57:47AM +0000, Fred P. wrote:
> 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.

> 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).

> 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.

> 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).

Regards,
  Dimitri

[Doxygen-develop] Basic SVG support for Image.h - Revision 2

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

/******************************************************************************
*
* $Id: image.h,v 1.7 2001/03/19 19:27:40 root Exp $
*
*
* Copyright (C) 1997-2004 by Dimitri van Heesch.
* Copyright (C) 2004 by Fred P. - Added Basic SVG support for ASV3 or 
ASV6pr1.
*
* SVG Support - Revision 2 - Optimized by hand Pixeled Font
*
* Permission to use, copy, modify, and distribute this software and its
* documentation under the terms of the GNU General Public License is hereby
* granted. No representations are made about the suitability of this 
software
* for any purpose. It is provided "as is" without express or implied 
warranty.
* See the GNU General Public License for more details.
*
* Documents produced by Doxygen are derivative works derived from the
* input used in their production; they are not affected by this license.
*
*/

#ifndef _IMAGE_H
#define _IMAGE_H
#include <qglobal.h>
#include <stdio.h>

class Image
{
  public:
    Image(int w,int h);
   ~Image();

    void setPixel(int x,int y,uchar val);
    uchar getPixel(int x,int y) const;
    void writeChar(int x,int y,char c,uchar fg);
    void writeString(int x,int y,const char *s,uchar fg);
    void drawHorzLine(int y,int xs,int xe,uchar colIndex,uint mask);
    void drawHorzArrow(int y,int xs,int xe,uchar colIndex,uint mask);
    void drawVertLine(int x,int ys,int ye,uchar colIndex,uint mask);
    void drawVertArrow(int x,int ys,int ye,uchar colIndex,uint mask);
    void drawRect(int x,int y,int width,int height,uchar colIndex,uint 
mask);
    void fillRect(int x,int y,int width,int height,uchar colIndex,uint 
mask);
    bool save(const char *fileName,int mode=0);
    friend uint stringLength(const char *s);
    uint getWidth() const { return width; }
    uint getHeight() const { return height; }
    uchar *getData() const { return data; }
    static uint stringLength(const char *s);

  private:
    int width;
    int height;
    uchar *data;

  // Added SVG Support:
  public:
    void svgPixel( int x, int y, uchar val );
    void svgRect(  int x, int y, int w, int h, uchar val );
    void svgPrintChar( char ch );

  private:
    FILE* file;
    bool alpha_def[256];
};

#endif // _IMAGE_H

// EOF

_________________________________________________________________
MSN Premium includes powerful parental controls and 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

[Doxygen-develop] Basic SVG support for Image.h/Image.cpp

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

/******************************************************************************
*
* $Id: image.h,v 1.7 2001/03/19 19:27:40 root Exp $
*
*
* Copyright (C) 1997-2004 by Dimitri van Heesch.
*
* Permission to use, copy, modify, and distribute this software and its
* documentation under the terms of the GNU General Public License is hereby
* granted. No representations are made about the suitability of this 
software
* for any purpose. It is provided "as is" without express or implied 
warranty.
* See the GNU General Public License for more details.
*
* Documents produced by Doxygen are derivative works derived from the
* input used in their production; they are not affected by this license.
*
*/

#ifndef _IMAGE_H
#define _IMAGE_H
#include <qglobal.h>
#include <stdio.h>

class Image
{
  public:
    Image(int w,int h);
   ~Image();

    void setPixel(int x,int y,uchar val);
    uchar getPixel(int x,int y) const;
    void writeChar(int x,int y,char c,uchar fg);
    void writeString(int x,int y,const char *s,uchar fg);
    void drawHorzLine(int y,int xs,int xe,uchar colIndex,uint mask);
    void drawHorzArrow(int y,int xs,int xe,uchar colIndex,uint mask);
    void drawVertLine(int x,int ys,int ye,uchar colIndex,uint mask);
    void drawVertArrow(int x,int ys,int ye,uchar colIndex,uint mask);
    void drawRect(int x,int y,int width,int height,uchar colIndex,uint 
mask);
    void fillRect(int x,int y,int width,int height,uchar colIndex,uint 
mask);
    bool save(const char *fileName,int mode=0);
    friend uint stringLength(const char *s);
    uint getWidth() const { return width; }
    uint getHeight() const { return height; }
    uchar *getData() const { return data; }
    static uint stringLength(const char *s);

  private:
    int width;
    int height;
    uchar *data;

  // Added SVG Support:
  public:
    void svgPixel( int x, int y, uchar val );
    void svgRect(  int x, int y, int w, int h, uchar val );

  private:
    FILE* file;
};

#endif

// EOF

/******************************************************************************
*
* $Id: image.cpp,v 1.14 2001/03/19 19:27:40 root Exp $
*
*
* Copyright (C) 1997-2004 by Dimitri van Heesch.
*
* Copyright (C) 2004 by Fred P. - Added Basic SVG support for ASV3 or 
ASV6pr1.
*
* Permission to use, copy, modify, and distribute this software and its
* documentation under the terms of the GNU General Public License is hereby
* granted. No representations are made about the suitability of this 
software
* for any purpose. It is provided "as is" without express or implied 
warranty.
* See the GNU General Public License for more details.
*
* Documents produced by Doxygen are derivative works derived from the
* input used in their production; they are not affected by this license.
*
*/

/**
* GOTCHA:
*   This file is used mainly for drawing UML diagram in PNG or SVG format,
*   currently pixel by pixel,  when HAVE_DOT = NO.
*   This file is not used at all if HAVE_DOT = YES.
*
*   To increase SVG support another add-on must be included
*   into the generating DOT UML format source code.
*
*   More SVG optimization should be provided,
*   most drawing are simple polygon,
*   text could be predefined in a <defs> and called with <use id='#f'/>
*   or used as <text> with normal fonts or create a custom SVG font.
*   Only letters which are used are required.
*
* NOTICE:
*   <defs> and <font definition> can be written anywhere in any order
*   inside the <svg>..</svg> tags.
*
*/

#include "qtbc.h"
#include "image.h"
#include "pngenc.h"
#include <qglobal.h>
#include <stdio.h>
#include <string.h>
#include "config.h"

const int charSetWidth = 80;
const int charHeight   = 12;
const int numChars     = 96;

unsigned short charPos[numChars]    =
  {
      0,  5,  8, 13, 20, 27, 38, 47,
     50, 54, 58, 65, 72, 76, 83, 87,
     91, 98,105,112,119,126,133,140,
    147,154,161,164,167,174,181,188,
    195,207,216,224,233,242,250,258,
    267,276,279,286,294,301,312,321,
    331,339,349,357,365,372,380,389,
    400,409,418,427,430,434,437,443,
    450,453,460,467,474,481,488,492,
    499,506,509,512,518,521,530,537,
    544,551,557,562,568,571,578,585,
    594,600,607,613,617,620,624,631
  };

unsigned char charWidth[numChars] =
  {
     5, 3, 5, 7, 7,11, 9, 3,
     4, 4, 7, 7, 4, 7, 4, 4,

     7, 7, 7, 7, 7, 7, 7, 7,
     7, 7, 3, 3, 7, 7, 7, 7,
    12, 9, 8, 9, 9, 8, 8, 9,
     9, 3, 7, 8, 7,11, 9,10,
     8,10, 8, 8, 7, 8, 9,11,
     9, 9, 9, 3, 4, 3, 6, 7,
     3, 7, 7, 7, 7, 7, 4, 7,
     7, 3, 3, 6, 3, 9, 7, 7,
     7, 6, 5, 6, 3, 7, 7, 9,
     6, 7, 6, 4, 3, 4, 7, 5
  };

unsigned char fontRaw[charSetWidth*charHeight] = {
  0x02, 0x50, 0x01, 0x06, 0x20, 0x60, 0xc6, 0x04, 0x00, 0x00, 0x00, 0x27,
  0x04, 0x1c, 0x38, 0x11, 0xf1, 0xc7, 0xc7, 0x0e, 0x00, 0x00, 0x00, 0x03,
  0x81, 0xf0, 0x10, 0x7c, 0x1e, 0x3e, 0x1f, 0x9f, 0x87, 0x88, 0x24, 0x09,
  0x09, 0x02, 0x02, 0x41, 0x0f, 0x0f, 0x83, 0xc3, 0xe1, 0xe7, 0xf4, 0x24,
  0x12, 0x22, 0x41, 0x20, 0x9f, 0xce, 0x30, 0x00, 0x10, 0x04, 0x00, 0x01,
  0x00, 0x30, 0x08, 0x12, 0x41, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40,
  0x00, 0x00, 0x00, 0x00, 0x01, 0xac, 0x00, 0x00, 0x02, 0x51, 0x43, 0x89,
  0x40, 0x90, 0x49, 0x15, 0x00, 0x00, 0x00, 0x28, 0x9c, 0x22, 0x44, 0x31,
  0x02, 0x20, 0x48, 0x91, 0x00, 0x00, 0x00, 0x04, 0x46, 0x08, 0x28, 0x42,
  0x21, 0x21, 0x10, 0x10, 0x08, 0x48, 0x24, 0x09, 0x11, 0x03, 0x06, 0x61,
  0x10, 0x88, 0x44, 0x22, 0x12, 0x10, 0x84, 0x24, 0x12, 0x22, 0x22, 0x20,
  0x80, 0x4a, 0x11, 0x00, 0x20, 0x04, 0x00, 0x01, 0x00, 0x40, 0x08, 0x00,
  0x41, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00,
  0x02, 0x22, 0x00, 0x00, 0x02, 0x51, 0x45, 0x49, 0x40, 0x90, 0x89, 0x0a,
  0x00, 0x00, 0x00, 0x48, 0x84, 0x02, 0x04, 0x51, 0x02, 0x00, 0x88, 0x91,
  0x00, 0x00, 0x00, 0x04, 0x44, 0xd4, 0x28, 0x42, 0x40, 0x20, 0x90, 0x10,
  0x10, 0x08, 0x24, 0x09, 0x21, 0x03, 0x06, 0x51, 0x20, 0x48, 0x48, 0x12,
  0x12, 0x00, 0x84, 0x22, 0x22, 0x22, 0x22, 0x11, 0x00, 0x89, 0x12, 0x80,
  0x31, 0xc5, 0x87, 0x0d, 0x1c, 0xe3, 0x4b, 0x12, 0x49, 0x29, 0x16, 0x1c,
  0x58, 0x69, 0x4c, 0xe8, 0x91, 0x44, 0x61, 0x44, 0xf2, 0x22, 0x00, 0x00,
  0x02, 0x07, 0xe5, 0x06, 0x80, 0x60, 0x10, 0x95, 0x08, 0x00, 0x00, 0x48,
  0x84, 0x04, 0x18, 0x51, 0xe2, 0xc0, 0x87, 0x11, 0x24, 0x18, 0x03, 0x00,
  0x89, 0x24, 0x44, 0x42, 0x40, 0x20, 0x90, 0x10, 0x10, 0x08, 0x24, 0x09,
  0x41, 0x02, 0x8a, 0x51, 0x20, 0x48, 0x48, 0x12, 0x11, 0x80, 0x84, 0x22,
  0x21, 0x24, 0x14, 0x11, 0x01, 0x09, 0x14, 0x40, 0x02, 0x26, 0x48, 0x93,
  0x22, 0x44, 0xcc, 0x92, 0x51, 0x36, 0x99, 0x22, 0x64, 0x99, 0x92, 0x48,
  0x91, 0x44, 0x52, 0x44, 0x12, 0x22, 0x00, 0x00, 0x02, 0x01, 0x43, 0x80,
  0x80, 0xa0, 0x10, 0x84, 0x08, 0x00, 0x00, 0x88, 0x84, 0x08, 0x04, 0x90,
  0x13, 0x21, 0x08, 0x8f, 0x00, 0x61, 0xf0, 0xc0, 0x8a, 0x24, 0x44, 0x7c,
  0x40, 0x20, 0x9f, 0x9f, 0x11, 0xcf, 0xe4, 0x09, 0xc1, 0x02, 0x8a, 0x49,
  0x20, 0x4f, 0x88, 0x13, 0xe0, 0x60, 0x84, 0x22, 0x21, 0x54, 0x08, 0x0a,
  0x02, 0x08, 0x90, 0x00, 0x00, 0x24, 0x48, 0x11, 0x22, 0x44, 0x48, 0x92,
  0x61, 0x24, 0x91, 0x22, 0x44, 0x89, 0x10, 0x48, 0x91, 0x24, 0x8c, 0x44,
  0x22, 0x22, 0x64, 0x00, 0x02, 0x07, 0xe1, 0x41, 0x31, 0x14, 0x10, 0x80,
  0x3e, 0x07, 0xc0, 0x88, 0x84, 0x10, 0x05, 0x10, 0x12, 0x21, 0x08, 0x81,
  0x01, 0x80, 0x00, 0x31, 0x0a, 0x24, 0x7c, 0x42, 0x40, 0x20, 0x90, 0x10,
  0x10, 0x48, 0x24, 0x09, 0x21, 0x02, 0x52, 0x45, 0x20, 0x48, 0x08, 0x92,
  0x20, 0x10, 0x84, 0x21, 0x41, 0x54, 0x14, 0x04, 0x04, 0x08, 0x90, 0x00,
  0x01, 0xe4, 0x48, 0x11, 0x3e, 0x44, 0x48, 0x92, 0x61, 0x24, 0x91, 0x22,
  0x44, 0x89, 0x0c, 0x48, 0x8a, 0x24, 0x8c, 0x48, 0x44, 0x21, 0x98, 0x00,
  0x02, 0x02, 0x85, 0x41, 0x49, 0x08, 0x10, 0x80, 0x08, 0x00, 0x00, 0x88,
  0x84, 0x20, 0x45, 0xf9, 0x12, 0x21, 0x08, 0x81, 0x00, 0x61, 0xf0, 0xc1,
  0x0a, 0x68, 0x82, 0x42, 0x40, 0x20, 0x90, 0x10, 0x10, 0x48, 0x24, 0x89,
  0x11, 0x02, 0x52, 0x45, 0x20, 0x48, 0x08, 0x52, 0x12, 0x10, 0x84, 0x21,
  0x40, 0x88, 0x22, 0x04, 0x08, 0x08, 0x90, 0x00, 0x02, 0x24, 0x48, 0x11,
  0x20, 0x44, 0x48, 0x92, 0x51, 0x24, 0x91, 0x22, 0x44, 0x89, 0x02, 0x48,
  0x8a, 0x2a, 0x92, 0x28, 0x42, 0x22, 0x00, 0x00, 0x00, 0x02, 0x85, 0x41,
  0x49, 0x18, 0x10, 0x80, 0x08, 0x00, 0x01, 0x08, 0x84, 0x20, 0x44, 0x11,
  0x12, 0x22, 0x08, 0x91, 0x00, 0x18, 0x03, 0x00, 0x09, 0xb0, 0x82, 0x42,
  0x21, 0x21, 0x10, 0x10, 0x08, 0xc8, 0x24, 0x89, 0x09, 0x02, 0x22, 0x43,
  0x10, 0x88, 0x04, 0x22, 0x12, 0x10, 0x84, 0x20, 0x80, 0x88, 0x22, 0x04,
  0x10, 0x08, 0x50, 0x00, 0x02, 0x26, 0x48, 0x93, 0x22, 0x44, 0xc8, 0x92,
  0x49, 0x24, 0x91, 0x22, 0x64, 0x99, 0x12, 0x49, 0x84, 0x11, 0x21, 0x28,
  0x82, 0x22, 0x00, 0x00, 0x02, 0x02, 0x83, 0x82, 0x30, 0xe4, 0x10, 0x80,
  0x00, 0x20, 0x05, 0x07, 0x04, 0x3e, 0x38, 0x10, 0xe1, 0xc2, 0x07, 0x0e,
  0x24, 0x00, 0x00, 0x01, 0x04, 0x00, 0x82, 0x7c, 0x1e, 0x3e, 0x1f, 0x90,
  0x07, 0x48, 0x24, 0x71, 0x05, 0xf2, 0x22, 0x41, 0x0f, 0x08, 0x03, 0xd2,
  0x11, 0xe0, 0x83, 0xc0, 0x80, 0x88, 0x41, 0x04, 0x1f, 0xc8, 0x50, 0x00,
  0x01, 0xd5, 0x87, 0x0d, 0x1c, 0x43, 0x48, 0x92, 0x45, 0x24, 0x91, 0x1c,
  0x58, 0x69, 0x0c, 0x66, 0x84, 0x11, 0x21, 0x10, 0xf2, 0x22, 0x00, 0x00,
  0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x20, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00,
  0x03, 0xe0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x40, 0x02, 0x00, 0x00, 0x00, 0x00, 0x40, 0x08, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x10, 0x02, 0x22, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x09, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x08, 0x10, 0x1f, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x04, 0x40, 0x02,
  0x00, 0x00, 0x00, 0x00, 0x40, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
  0x02, 0x22, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0c, 0x30, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x80, 0x04, 0x00, 0x00, 0x00, 0x00,
  0x40, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x01, 0xac, 0x00, 0x00
};

static Color palette[] =
{
  { 0xff, 0xff, 0xff },
  { 0x00, 0x00, 0x00 },
  { 0xff, 0xff, 0xc0 },
  { 0x9f, 0x9f, 0x60 },
  { 0x90, 0x00, 0x00 },
  { 0x00, 0x90, 0x00 },
  { 0x00, 0x00, 0x90 },
  { 0xc0, 0xc0, 0xc0 }
};

static Color palette2[] =
{
  { 0xff, 0xff, 0xff },
  { 0xe0, 0xe0, 0xe0 },
  { 0xd0, 0xd0, 0xd0 },
  { 0xc0, 0xc0, 0xc0 },
  { 0xb0, 0xb0, 0xb0 },
  { 0xa0, 0xa0, 0xa0 },
  { 0x90, 0x90, 0x90 },
  { 0x80, 0x80, 0x80 },
  { 0x70, 0x70, 0x70 },
  { 0x60, 0x60, 0x60 },
  { 0x50, 0x50, 0x50 },
  { 0x40, 0x40, 0x40 },
  { 0x30, 0x30, 0x30 },
  { 0x20, 0x20, 0x20 },
  { 0x10, 0x10, 0x10 },
  { 0x00, 0x00, 0x00 }
};

static int image_counter = 1;


Image::Image(int w,int h)
{
  data = new uchar[w*h];
  memset(data,0,w*h);
  width = w;
  height = h;

  QCString &outputDirectory = Config_getString("OUTPUT_DIRECTORY");

  char buffer[500];
  _snprintf( buffer, 500,
    "%s\\svg\\image%d_%dx%d.svg",
    (const char*)outputDirectory,
    image_counter++, w,h );

  file = fopen( buffer, "w+" );

  if ( file )
  {
    fprintf( file,
      "<?xml version='1.0'?>\n"
      "<svg width='%d' height='%d' \n"
      "enableZoomAndPanControls='false' \n"
      "xmlns:xlink='http://www.w3.org/2000/xlink/namespace/' \n"
      "xmlns:svg='http://www.w3.org/2000/svg' \n"
      "style='text-rendering: optimizeLegibility; shape-rendering: 
optimizeSpeed; "
      "font-family: Arial; font-size: 12;' >", w, h
    );
  }
}

Image::~Image()
{
  if ( file )
  {
    fprintf( file, "</svg>" );

    fclose( file );
  }

  delete[] data;
}

void Image::setPixel(int x,int y,uchar val)
{
  if (x>=0 && x<width && y>=0 && y<height)
  {
    data[y*width+x] = val;
  }
}

void Image::svgPixel( int x, int y, uchar val )
{
  svgRect( x, y, 1, 1, val );
}

void Image::svgRect( int x, int y, int w, int h, uchar val )
{
  if (file && x>=0 && x<width && y>=0 && y<height)
  {
    char buffer[500];
    Color c = palette[val];

    _snprintf( buffer, 500,
      "\n<rect x='%d' y='%d' width='%d' height='%d' fill='#%.2x%.2x%.2x' 
color='%d'/>",
      x,y,w,h,c.red,c.green,c.blue,val);

    fprintf( file, "%s", buffer );
  }
}

uchar Image::getPixel(int x,int y) const
{
  if (x>=0 && x<width && y>=0 && y<height)
    return data[y*width+x];
  else
    return 0;
}

void Image::writeChar(int x,int y,char c,uchar fg)
{
  if (c>=' ')
  {
    int xf,yf,ci=c-' ';
    int rowOffset=0;
    int cw = charWidth[ci];
    int cp = charPos[ci];
    for (yf=0;yf<charHeight;yf++)
    {
      unsigned short bitPattern=0;
      int bitsLeft=cw;
      int byteOffset = rowOffset+(cp>>3);
      int bitOffset  = cp&7;
      // get the bit pattern for row yf of the character from the font data
      while (bitsLeft>0)
      {
        int bits=8-bitOffset;
        if (bits>bitsLeft) bits=bitsLeft;
        bitPattern<<=bits;
        bitPattern|=((fontRaw[byteOffset]<<bitOffset)&0xff)>>(8-bits);
        bitsLeft-=bits;
        bitOffset=0;
        byteOffset++;
      }
      int mask=1<<(cw-1);
      // draw character row yf

      uchar font_color      = 0;
      uchar font_last_color = 0;
      uchar font_last_x     = 0;

      for (xf=0;xf<cw;xf++)
      {
        font_color = (bitPattern&mask) ? fg : getPixel(x+xf,y+yf);
        setPixel(x+xf, y+yf, font_color);
        svgPixel(x+xf, y+yf, font_color);

/*
        if ( xf > 0 && font_color != font_last_color )
        {
          int wf = xf - font_last_x; // == (xf-1) - font_last_x + 1;

          svgRect(x+font_last_x, y+yf, wf, 1, font_color);
          font_last_color = font_color;
          font_last_x     = xf;
        }
*/

        mask>>=1;
      }

/*
        // Save the last one
        if ( xf > 0 && font_color != font_last_color )
        {
          int wf = xf - font_last_x; // == (xf-1) - font_last_x + 1;

          svgRect(x+font_last_x, y+yf, wf, 1, font_color);
          font_last_color = font_color;
          font_last_x     = xf;
        }
*/

      rowOffset+=charSetWidth;
    }
  }
}

// 0 1 2 3 4 5

void Image::writeString(int x,int y,const char *s,uchar fg)
{
  if (s)
  {
    char c;
    while ((c=*s++))
    {
      writeChar(x,y,c,fg);
      x+=charWidth[c-' '];
    }
  }
}

uint Image::stringLength(const char *s)
{
  int w=0;
  if (s)
  {
    char c;
    while ((c=*s++)) w+=charWidth[c-' '];
  }
  return w;
}

void Image::drawHorzLine(int y,int xs,int xe,uchar colIndex,uint mask)
{
  int x,i=0,j=0;
  svgRect( xs, y, xe-xs+1, 1, colIndex );

  for (x=xs;x<=xe;x++,j++)
  {
    if (j&1) i++;
    if (mask&(1<<(i&0x1f)))
    {
      setPixel(x,y,colIndex);
    }
    else
    {
      svgPixel(x,y,0); // MASK
    }
  }
}

void Image::drawHorzArrow(int y,int xs,int xe,uchar colIndex,uint mask)
{
  drawHorzLine(y,xs,xe,colIndex,mask);
  int i;
  for (i=0;i<6;i++)
  {
    int h=i>>1;
    drawVertLine(xe-i,y-h,y+h,colIndex,0xffffffff);
  }
}

void Image::drawVertLine(int x,int ys,int ye,uchar colIndex,uint mask)
{
  int y,i=0;

  svgRect( x, ys, 1, ye-ys+1, colIndex );

  for (y=ys;y<=ye;y++,i++)
  {
    if (mask&(1<<(i&0x1f)))
    {
      setPixel(x,y,colIndex);
    }
    else
    {
      svgPixel(x,y,0); // MASK
    }
  }
}

void Image::drawVertArrow(int x,int ys,int ye,uchar colIndex,uint mask)
{
  drawVertLine(x,ys,ye,colIndex,mask);
  int i;
  for (i=0;i<6;i++)
  {
    int h=i>>1;
    drawHorzLine(ys+i,x-h,x+h,colIndex,0xffffffff);
  }
}

void Image::drawRect(int x,int y,int w,int h,uchar colIndex,uint mask)
{
  drawHorzLine(y,x,x+w-1,colIndex,mask);
  drawHorzLine(y+h-1,x,x+w-1,colIndex,mask);
  drawVertLine(x,y,y+h-1,colIndex,mask);
  drawVertLine(x+w-1,y,y+h-1,colIndex,mask);
}

void Image::fillRect(int x,int y,int lwidth,int lheight,uchar colIndex,uint 
mask)
{
  int xp,yp,xi,yi;

  svgRect( x, y, lwidth, lheight, colIndex );

  for (yp=y,yi=0;yp<y+lheight;yp++,yi++)
  {
    for (xp=x,xi=0;xp<x+lwidth;xp++,xi++)
    {
      if (mask&(1<<((xi+yi)&0x1f)))
      {
        setPixel(xp,yp,colIndex);
      }
      else
      {
        svgPixel(xp,yp,0); // MASK
      }
    }
  }
}

bool Image::save(const char *fileName,int mode)
{
  PngEncoder enc(data,
                 mode==0 ? palette : palette2,
                 width,height,
                 mode==0 ? 3 : 4,
                  0);

  if ( file )
  {
    fprintf( file,
      "\n<desc filename='%s' mode='%d' "
      "x='%d' y='%d'\n>"
      "File: %s - Mode: %d</desc>\n",

      fileName, mode,
      0, height-10,
      fileName, mode
    );
  }

  enc.write(fileName);
  return TRUE;
}

// EOF

_________________________________________________________________
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

[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);

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/ ]

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'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:

void ClassDiagram::writeImage(QTextStream &t,const char *path,
                             const char *fileName, bool generateMap)
{
uint baseRows=base->computeRows();
uint superRows=super->computeRows();
uint rows=baseRows+superRows-1;

uint lb,ls,xb,xs;
base->computeExtremes(&lb,&xb);
super->computeExtremes(&ls,&xs);

uint cellWidth  = QMAX(lb,ls)+labelHorMargin*2;
uint maxXPos    = QMAX(xb,xs);
uint labelVertMargin = 6; //QMAX(6,(cellWidth-fontHeight)/6); // aspect at 
least 1:3
uint cellHeight = labelVertMargin*2+fontHeight;
uint imageWidth = (maxXPos+gridWidth)*cellWidth/gridWidth+
                   (maxXPos*labelHorSpacing)/gridWidth;
uint imageHeight = rows*cellHeight+(rows-1)*labelVertSpacing;

Image image(imageWidth,imageHeight);

base->drawBoxes(t,&image,TRUE,TRUE,baseRows,superRows,cellWidth,cellHeight,generateMap);
super->drawBoxes(t,&image,FALSE,TRUE,baseRows,superRows,cellWidth,cellHeight,generateMap);
base->drawConnectors(t,&image,TRUE,TRUE,baseRows,superRows,cellWidth,cellHeight);
super->drawConnectors(t,&image,FALSE,TRUE,baseRows,superRows,cellWidth,cellHeight);

image.save((QCString)path+'/'+fileName+'.png');

if (generateMap) t << '</map>' << endl;
}


I want to add embedded html inlined <svg> diagrams output instead of png.

image->fillRect(x+1,y+1,w-2,h-2,colFill,mask);
image->drawRect(x,y,w,h,colBorder,mask);
image->writeString(x+(w-l)/2, y+(h-fontHeight)/2, di->label(),1);

For instance get transformed into:

See the following SVG documentation
http://www.w3.org/TR/SVG/shapes.html#RectElement
http://www.w3.org/TR/SVG/text.html#TextElement

char[] getHexRGBColor( uchar color )
{
char buffer[8];
Color c = palette2[ color ];

snprintf( buffer, 8, "%.2x%.2x%.2x", c.red, c.green, c.blue );

return buffer;
}

snprintf( buffer, BUFFER_SIZE,
"<svg:rect x='%d' y='%d' width='%d' height='%d' fill='#%s' mask='%s' 
stroke='#%s' />",
x+1,y+1,w-2,h-2, getHexRGBColor( colFill ),mask, getHexRGBColor( colBorder ) 
);

snprintf( buffer, BUFFER_SIZE,
"<svg:text x='%d' y='%d' fill='#%s'>%s</text>",
x+(w-l)/2, y+(h-fontHeight)/2, getHexRGBColor( 1 ), di->label() );


another way would be to have:

void Image::setPixel(int x,int y,uchar val)
{
if (x>=0 && x<width && y>=0 && y<height)
   data[y*width+x] = val;
}

being:

char[] Image::putPixel(int x,int y,uchar val)
{
char buffer[100];
snprintf( buffer, 100,
   "<svg:rect x='%5d' y='%5d' width='1' height='1' fill='#%s'/>\n",
   x, y, getHexRGBColor( val )
);

return buffer;
}

Image::Image(int w,int h)
{
printSvgHeader( w, h );
}

char[] printSvgHeader( int w, int h)
{
char buffer[400];
snprintf( buffer, 400,
"\n <svg:svg xmlns='http://www.w3.org/2000/svg' 
xmlns:xlink='http://www.w3.org/1999/xlink' "
"\n width='%5d' height='%5d' enableZoomAndPanControls='false' "
"\n style=' font-family: \"Ms Sans Serif\"; font-weight: normal; font-size: 
9pt; fill: black; "
"shape-rendering: optimizeSpeed; text-rendering: optimizeLegibility; ' "
">", w, h );

return buffer;
}

char* printSvgFooter()
{
return "\n</svg:svg>\n";
}

char[] printHtmlHeader()
{
char buffer[600];
snprintf( buffer, 600,
   "<?xml version='1.0' encoding='iso-8859-1'?> "
"\n<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'> "
   "\n<html "
"\n xmlns:svg='http://www.w3.org/2000/svg' "
"\n xmlns='http://www.w3.org/1999/xhtml' "
   "\n xml:lang='en' lang='en'> "
   "\n<head><!-- ASV6pr1 ActiveX entry tag -->"
   "\n<object id='AdobeSVG' 
classid='clsid:78156a80-c6a1-4bbf-8e6a-3cd390eeb4e2'></object>"
   "\n<?import namespace='svg' implementation='#AdobeSVG'?> "
   "\n</head>"
   "\n<body>"
  );

return buffer;
}


If you were kind enough to give me some hint,
I would really appreciate.

Fred 'diving into Doxygen source' P.

_________________________________________________________________
Free yourself from those irritating pop-up ads with MSn Premium. Get 2months 
FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

Re: [Doxygen-develop] documenting template parameters.

[Hagen M. <mai...@st...>]

Hi Dimitri,

thx for your inertial help. I had figured that out by now but now I am
stuck at a point where I don't know what to do. I managed recognization
and stuff, I avoided the translators for the time being and I did some
output with it:
My tparams seem to work but the content is appended to previous section. =
I
really don't know how to describe the problem any better, if I could I
certainly also could solve it.

Thx for any input ...

Regards,

Hagen.

Re: [Doxygen-develop] documenting template parameters.

[Dimitri v. H. <di...@st...>]

On Thu, Mar 11, 2004 at 12:38:57AM +0100, Hagen Moebius wrote:
> Hi List.
> 
> I would like to add the TODO-list item #29 which should allow documenting
> template parameters via the keyword @tparam or in place. This is just the
> announcement I have not done a single line for it, so pls go on and try
> and stop I you must. I would like to add this feature because gtkmm
> documentation may be in need of it in the future :).

Please proceed, and add it ;)

> Any input is aprreciated and you are welcome to request features applying
> to this task.

Look at src/docparser.cpp for a starting point. Commands are listed
in src/cmdmapper.cpp. The class that holds the info for a parameter section
is DocParamSect (defined in src/docparser.h). The output for the various
formats is generated by src/*docvisitor.* using the Visitor design pattern.

> Hagen
> 
> PS: Pls also tell me where I should send my patches. Bugzilla seems the
> right spot, is it?

Bugzilla is a good place indeed. You can also send patches directly to me,
but then there is no tracking available, and there is a chance I overlook
it/gets lost in the spam.

Regards,
  Dimitri

[Doxygen-develop] how to help

[kemal a. <as...@cl...>]

thru my last message probably most of you realized i am a newbie trying
to help. I submitted yesterday a problem compiling doxygen and the
solution to fix the problem. As i am not sure that is the appropriate
way to proceed to help. i am looking for guidance on how shall i get my
work into the software. who should i send the corrected file to ? 

Regards,
Kemal