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

[Doxygen-develop] Compiling Doxygen with GCC under Windows?

[Roy L. <Roy...@wd...>]

Hi,

Has anybody successfully compiled Doxygen with GCC under Windows?

My first trivial attempt generates the following error:

g++ -c -O -I../qtools -o ../objects/config.o config.cpp
In file included from ../qtools/qiodevice.h:42,
                 from ../qtools/qfile.h:42,
                 from ../qtools/qfileinfo.h:42,
                 from config.l:27:
../qtools/qglobal.h:132: #error "Qt has not been ported to this OS - talk to
qt-
bu...@tr..."

Anybody got any suggestions?  Or should I just go out and get MSVC?

Cheers,

Roy

[Doxygen-develop] Doxygen 1.2.13-20020210 segfaults

[Roberto B. <ba...@cs...>]

Hi there,

doxygen version 1.2.13-20020210 segfaults at the attached
input.  Here is what happens

$ gdb /usr/local/bin/doxygen
(gdb) run config
Starting program: /usr/local/bin/doxygen config

Program received signal SIGSEGV, Segmentation fault.
0x0814f616 in QGList::first() ()
(gdb) info stack
#0  0x0814f616 in QGList::first() ()
#1  0x0805947a in findMember(Entry*, QCString, bool, bool) ()
#2  0x0805c5eb in findMemberDocumentation(Entry*) ()
#3  0x0805c045 in findMemberDocumentation(Entry*) ()
#4  0x0805c045 in findMemberDocumentation(Entry*) ()
#5  0x080684b5 in parseInput() ()
#6  0x08049b53 in main ()
#7  0x40105627 in __libc_start_main (main=0x8049b30 <main>, argc=2,
     ubp_av=0xbffffa44, init=0x8049450 <_init>, fini=0x81d6fc0 <_fini>,
     rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffffa3c)
     at ../sysdeps/generic/libc-start.c:129
(gdb)

Here are the version of doxygen, the version of the GCC compiler
I have used to compile it, and the versions of the QT packages.

$ /usr/local/bin/doxygen --version
1.2.13-20020210

$ g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs
Configured with: ../gcc-3.0.3/configure --prefix=/usr/local
Thread model: single
gcc version 3.0.3

$ rpm -qa | fgrep qt
qt-designer-2.3.1-5
qt-devel-2.3.1-5
qt-2.3.1-5

In addition, it seems there is something wrong with Doxygen's
CVS repository: the only thing I am able to get ouf of it is
something like

cvs server: [07:51:12] waiting for kp3softd's lock in /u/kp3softd/cvsroot
cvs server: [07:51:42] waiting for kp3softd's lock in /u/kp3softd/cvsroot
...

Many thanks for all the good work.

       Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...

[Doxygen-develop] Bug: same name tags being used in one file.

[Carlo W. <ca...@al...>]

All versions, last version tried: doxygen-1.2.13.1

Doxygen generates name tags (<a name="a1" ...)
multiple times in the same file, causing the
browser to jump to the wrong (the first) item.

I've attached an example, search for 'name="a1"'
inside that file to see that it occurs more than
once.

~/c++/libcw/src/libcwd/documentation/html>grep 'name="a1"' namespacelibcw_1_1debug.html
<tr><td nowrap align=right valign=top><a name="a1" doxytag="libcw::debug::mem_size"></a>
<tr><td nowrap align=right valign=top><a name="a1" doxytag="libcw::debug::nonewline_cf"></a>
<a name="a1" doxytag="libcw::debug::libcw_do"></a><p>

-- 
Carlo Wood <ca...@al...>

[Doxygen-develop] Info on the status of the language translators (February 5th, 200 2)

[Prikryl,Petr <PRI...@sk...>]

Info on the status of the language translators (February 5th, 2002)

(Related to the Doxygen-1.2.13-20020203 in CVS; full
translator_report.txt included in the attached zip file.

Posted to doxygen-develop [for the language
maintainers], copy posted to doxygen-users [searching
for Finnish and Swedish language maintainers].)

Hi,

First of all, my special thanks to all language
maintainers. 

  -----------------------------------------------
  We are still searching for Finnish and Swedish
  maintainers because their translators became
  extremely obsolete.
  -----------------------------------------------
  
The attached traslator_report.txt shows the current
status of the Translator classes.  Here is an excerpt
that can help you to guess how much work it would
require to make your language translator up-to-date.
Notice, that the translator.pl script now shows also
what required methods are implemented by what
translators:

----------------------------------------------------------------------
The following translator classes are up-to-date (sorted alphabetically).
This means that they derive from the Translator class.  Anyway, there still
may be some details listed even for the up-to-date translators.
Please, check the text below if the translator is marked so.

  TranslatorBrazilian
  TranslatorCroatian
  TranslatorCzech
  TranslatorDutch
  TranslatorEnglish
  TranslatorFrench
  TranslatorItalian
  TranslatorRussian

----------------------------------------------------------------------
The following translator classes are obsolete (sorted alphabetically).
This means that they derive from some of the adapter classes.

  TranslatorChinese     (TranslatorAdapter_1_2_13)
  TranslatorDanish      (TranslatorAdapter_1_2_7)
  TranslatorGerman      (TranslatorAdapter_1_2_13)
  TranslatorGreek       (TranslatorAdapter_1_2_11)
  TranslatorHungarian   (TranslatorAdapter_1_2_1)
  TranslatorJapanese    (TranslatorAdapter_1_2_13)
  TranslatorKorean      (TranslatorAdapter_1_2_13)
  TranslatorNorwegian   (TranslatorAdapter_1_2_2)
  TranslatorPolish      (TranslatorAdapter_1_2_1)
  TranslatorPortuguese  (TranslatorAdapter_1_2_13)
  TranslatorRomanian    (TranslatorAdapter_1_2_1)
  TranslatorSlovak      (TranslatorAdapter_1_2_13)
  TranslatorSlovene     (TranslatorAdapter_1_2_13)
  TranslatorSpanish     (TranslatorAdapter_1_2_7)
  TranslatorUkrainian   (TranslatorAdapter_1_2_11)

----------------------------------------------------------------------
The following translator classes are implemented via deriving
from the English translator.  This should be done only in the case
when the language maintainer or the doxygen developers need to update
some really outdated translator.  Otherwise, deriving from
the translator adapter classes should be prefered for obsolete translators.
See details below in the report.

  TranslatorFinnish     (TranslatorEnglish)
  TranslatorSwedish     (TranslatorEnglish)

----------------------------------------------------------------------
The following translator adapter classes are implemented -- the older (with
lower number) are always derived from the newer. They implement the
listed required methods. Notice that some versions of doxygen did not
introduce any changes related to the language translators.  From here you
may
guess how much work should be done to update your translator:
      
  TranslatorAdapter_1_2_13      implements  2 required methods...
    QCString trImplementedFromList(int numEntries)
    QCString trImplementedInList(int numEntries)

  TranslatorAdapter_1_2_11      implements  1 required method...
    QCString trReferences()

  TranslatorAdapter_1_2_7       implements  1 required method...
    QCString trAuthor(bool first_capital, bool singular)

  TranslatorAdapter_1_2_6       implements 13 required methods...
    QCString trRTFansicp()
    QCString trRTFCharSet()
    QCString trRTFGeneralIndex()
    QCString trFile(bool first_capital, bool singular)
    QCString latexLanguageSupportCommand()
    QCString idLanguageCharset()
    QCString trClass(bool first_capital, bool singular)
    QCString trNamespace(bool first_capital, bool singular)
    QCString trGroup(bool first_capital, bool singular)
    QCString trPage(bool first_capital, bool singular)
    QCString trMember(bool first_capital, bool singular)
    QCString trField(bool first_capital, bool singular)
    QCString trGlobal(bool first_capital, bool singular)

  TranslatorAdapter_1_2_5       implements  2 required methods...
    QCString trBug()
    QCString trBugList()

  TranslatorAdapter_1_2_4       implements  8 required methods...
    QCString trInterfaces()
    QCString trClasses()
    QCString trPackage(const char *name)
    QCString trPackageList()
    QCString trPackageListDescription()
    QCString trPackages()
    QCString trPackageDocumentation()
    QCString trDefineValue()

  TranslatorAdapter_1_2_2       implements  2 required methods...
    QCString trProperties()
    QCString trPropertyDocumentation()

  TranslatorAdapter_1_2_1       implements  1 required method...
    QCString trDCOPMethods()

----------------------------------------------------------------------

Clearly, to pass the 1.2.4 and 1.2.6 translator
adapters requires more work.  Anyway, their methods
are not extremely difficult to implement.  

If you find some time, please do update your
translator.  The comming-soon work on the new
implementation of translators would otherwise be more
difficult for those who develop the core code. 

Thanks, 
  Petr
  

-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-develop] source compile error

[<ca...@Cr...>]

	definition.cpp
	Definition::setDocumentation( const char *d,const char
*docFile,int docLine,bool stripWhiteSpace=3DTRUE)
{
	...
}

	was not compile at msvc. Simplified change to=20
	Definition::setDocumentation( const char *d,const char
*docFile,int docLine,bool stripWhiteSpace)
{
	...
}
	remove error.

	- Alexandr Chelpanov -

Re: [Doxygen-develop] "libgd was not built with FreeType font support"

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

On Fri, Feb 01, 2002 at 04:47:51PM +0000, Simon A Watts wrote:
> 
> When running Doxygen, the following (error?) messages is repeated many
> time:
> 
> libgd was not built with FreeType font support
>  : doxfont in .
> 
> 
> Now, libgd.so (1.8.3) certainly links with libttf.so.2, so what does
> this mean?  What is producing this message, and how can I either enable
> TTF support, or get rid of this message?

This is a graphviz issue. Please look at the documentation of that package.

Regards,
  Dimitri

Re: [Doxygen-develop] wish: in-source macro expansion control

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

On Fri, Feb 01, 2002 at 11:36:22AM +0000, Simon A Watts wrote:
> I have been using Doxygen on a diverse project, and incorporated it into
> our build process.  Once limitation I have encountered is in the control
> of which pre-processor macros should be expanded.
> 
> Currently we have to specify in the Doxygen configuration file which
> macros should be expanded when generating the docs, unless an
> all-or-nothing approach is used.
> 
> But, we have a general config file for a series of sub-projects.
> 
> What would be nice is if there could be a command, associated with the
> documentation for a macro, to say whether that macro should be expanded
> or not.  Something like:
> 	
> 	/// @expand
> 	#define MYMACRO(ARG1,ARG2) ...
> 
> 	/// @noexpand
> 	#define KEY_SIZE 123
> 
> 
> If this was the case, I'd probably set Doxygen not to expand anything by
> default, and just expand what I've requested (which would mostly be
> code-generating macros in my case).

I've added it to my todo list.

> Of course, I could instigate this now by using using "grep" on the
> source files (since make already explicitly accumulates a list of the
> source files), and append to the EXPAND_AS_DEFINED config option. 
> Though for that I'd have to use "/// @expand MYMACRO(ARG1,ARG2)" type
> syntax instead. 

If you create a small perl script that looks at two lines, I think just
using @expand with arguments would do too.

Regards,
  Dimitri

[Doxygen-develop] "libgd was not built with FreeType font support"

[Simon A W. <sim...@ph...>]

When running Doxygen, the following (error?) messages is repeated many
time:

libgd was not built with FreeType font support
 : doxfont in .


Now, libgd.so (1.8.3) certainly links with libttf.so.2, so what does
this mean?  What is producing this message, and how can I either enable
TTF support, or get rid of this message?



Si.




-- 
Simon A Watts
Software Engineer
Philips Medical Systems
mailto:sim...@cl...
tel: +44(0) 1252 747 311

[Doxygen-develop] wish: in-source macro expansion control

[Simon A W. <sim...@ph...>]

I have been using Doxygen on a diverse project, and incorporated it into
our build process.  Once limitation I have encountered is in the control
of which pre-processor macros should be expanded.

Currently we have to specify in the Doxygen configuration file which
macros should be expanded when generating the docs, unless an
all-or-nothing approach is used.

But, we have a general config file for a series of sub-projects.

What would be nice is if there could be a command, associated with the
documentation for a macro, to say whether that macro should be expanded
or not.  Something like:
	
	/// @expand
	#define MYMACRO(ARG1,ARG2) ...

	/// @noexpand
	#define KEY_SIZE 123


If this was the case, I'd probably set Doxygen not to expand anything by
default, and just expand what I've requested (which would mostly be
code-generating macros in my case).

Of course, I could instigate this now by using using "grep" on the
source files (since make already explicitly accumulates a list of the
source files), and append to the EXPAND_AS_DEFINED config option. 
Though for that I'd have to use "/// @expand MYMACRO(ARG1,ARG2)" type
syntax instead. 



Si.


-- 
Simon A Watts
Software Engineer
Philips Medical Systems
mailto:sim...@cl...
tel: +44(0) 1252 747 311

[Doxygen-develop] Updated Croatian translation

[Boris B. <bor...@zg...>]

Hi,

Made TranslatorCroatian to inherit from Translator

Boris

[Doxygen-develop] Updated Croatian translation

[Boris B. <bor...@zg...>]

Here it is.

Boris

[Doxygen-develop] New Brazilian translator

[FJTC (F. J. T. Chino) <ch...@ic...>]

Hi.

Hi. Here goes the new version of brazilian translator.

See you...
FJTC


----------------------------------------------------------------------
         FJTC (Fabio Jun Takada Chino) - ch...@ic...
      Computer Science - ICMC - University of Sao Paulo - Brazil
              GBDI - Grupo de Base de Dados e Imagens
----------------------------------------------------------------------
Homepage
  http://www.icmc.sc.usp.br/~chino (main)
  http://gbdi.icmc.sc.usp.br/ (GBDI)
  http://www.fjtc.hpg.com.br/ (Anime - Portuguese Only)
  http://www.bbits.hpg.com.br/ (Game Programming - English Only)
======================================================================

[Doxygen-develop] Updated italian translation...

[Alessandro F. <afa...@da...>]

Here it is

Alessandro

[Doxygen-develop] statistics page and commenting doxygen source

[Stefan K. <ko...@im...>]

hi,

I am currently trying do add a statistics page functionallity to doxygen (based on the 1.2.13.1 sources).
This pages should be lined in under "Related Pages" (pages.html).
All I cuurently managed to achive is to add the Doxyfile option "GENERATE_STATS".
Please don't be offended, but what about adding doxygen comments to doxygen sources ?
Apart from it what do you think about it?

Stefan
-- 
       \|/
      <@ @> Stefan Kost  private                   business
+-oOO-(_)-OOo------------------------------------------------------------- - - -  -   -
|        __    Address  Zwenkauer Str. 24         HTWK Leipzig, Fb IMN, Postfach 300066
|       ///             04277 Leipzig             04277 Leipzig
|  __  ///              Germany                   Germany
|  \\\///      Phone    +49341 3910483            +49341 3076101
|   \__/       EMail    st...@gm...           ko...@im...
|              WWW      http://www.sonicpulse.de  http://www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -

[Doxygen-develop] French translator updated

[Xavier O. <xav...@an...>]

Hi,

Here is the French translator updated.

Thanks to Petr who has tested compilation. :)

Greetings,

Xavier.
--
 D2SET Scientific and Technical Non profit Association
  http://www.d2set.org/
  mailto:d2...@d2...

 Artificial Anthill Project
  http://www.aanthill.org/
  mailto:aan...@aa...

[Doxygen-develop] Czech translator updated

[Prikryl,Petr <PRI...@sk...>]

Hi, here it is...
 <<tr_cz.zip>> 

-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-develop] Why is Japanese RTF output broken ?

[Haruyuki O. <oh...@is...>]

Hello

Why are Japanese characters(Kanji)  in RTF output broken ?
What is a difference in treating Japanese characters in between outputing
HTML  and outputing RTF ?
In outputing HTML, Japanese characters are correctlly treated.
Any idea ?

---
Haru

[Doxygen-develop] Customization of HTML pages (patch)

[Johan E. <joh...@ua...>]

Hi all,
         attached are some files to customize HTML pages but could 
easily? be extended to include at least the LATEX output format. The 
patch makes it possible to add user defined commands in the same way as 
e.g. the $dateandtime, $projectname etc. by including them in the file 
defined by the HTML_HEADER tag. At creation time of an HTML file doxygen 
calls a program (via popen()) defined by an new tag HTML_OUTPUT_ADAPTER. 
As input arguments the program uses <source> <output_dir>:
<source> is most of the time a source file where the current object 
(e.g. a class) is defined but when generating index files the first 
value of the INPUT tag is used as the source.
<output_dir> is the definition of the OUTPUT_DIRECTORY tag.

The main idea behind the patch is to enable generation of  many 
subprojects, where the same group(s) (defgroup/ingroup) exists in more 
than one project and still keep the unique information that might exists 
from each subproject in the generated documentation. In that way it is 
possible to show this information while viewing the HTML file, such info 
could e.g. be a design responsible identification which lets the viewer 
immediatelly know who to contact for more info.

Design information (doxygen):
The current design only works for the HTML_HEADER cause that satisfy our 
needs, adding more such as HTML_FOOTER or LATEX_HEADER requires some 
more thoughts. Probably one more argument has to be used when invoking 
the "adapter program" since it is invoked for every generated file and 
therefore it adds time to the total generation time. The argument could 
state whether it is for the HTML header/ footer or the LATEX header so 
it possible to decide whether to terminate immediatelly.

Desigin information (adapter program)
As already stated, there are two arguments <source> and <output_dir>. 
The <source> usally contains the source file (including the absolute 
path) to the definition of the current object, such as a class or e.g. 
group definition. Sometimes the <source> argument contains the first 
value of the INPUT tag, this is when generating the index files where no 
real definition file exists.
The <output_dir> is always the value of the OUTPUT_DIRECTORY tag, as an 
example we are using it to get the relative path for an image used in 
the HTML header.
The output format shall be:
[USER_COMMAND]
$NameofVariable1FoundinHTMLHeaderfile=replacementString
$NameofVariable2FoundinHTMLHeaderfile=replacementString
$NameofVariable3FoundinHTMLHeaderfile=replacementString
$NameofVariable4FoundinHTMLHeaderfile=replacementString

In the current implementation the [USER_COMMAND] could have been left 
out but we kept it for now. It is used to tell doxygen the expected 
interpretation and where to temporarily store the information.

Regards,
              Johan

PS The patch is for version 1.2.11 DS

[Doxygen-develop] Doxygen's XML and encoding problems -- Translators Revisited (was : setEncoding ?)

[Prikryl,Petr <PRI...@sk...>]

(was "setEncoding ?") 
(The "Translator Revisited" working document attached.
If you participate on doxygen XML development, please,
read it and discuss.) 


Hi Haru and other doxygeners,

Haruyuki Ohtani asked...
> 
> I think the latest doxygen generates ISO-8859-1 encoding
> for XML output. But it does not seem to call
> QTextStream::setEncoding(QTextStream::Latin1) in
> genarateXML function. Is it correct ?

I am temporarily too busy to participate on the
development; however, I was thinking about how the
encoding problems should be solved.  It was in the
pre-XML era.  The result of the analysis was that if any
encoding problem is to be avoided for any language, more
than one encoding should be supported in the same time,
during the processing (generally) or some kind of
language-independent (i.e. encoding-independent)
solution should be used.  See the explanation below.

In other words, if the problem is touched now, it would
be nice to solve it carefully now.  XML existence can
make it easier, but it does not solve it automatically.

Firstly, as far as I know, a XML file can define
encoding being used, but only in the "per-file" way,
like:

 <?xml encoding="ISO-8859-2" ?>

Secondly, if the content of the file is a mixture of
texts taken from doxygen comments (in processed source
files to be documented) together with generated texts
(by Translator classes), then the encoding must be
unified during composition of the document.  Or the
input sources have to be converted to the same encoding
as is the one of the strings produced by the Translator
class instantiation, or the Translator object has to
convert its results.  

The the instantiation of the Translator class depends on
the chosen (human) language, and the encoding of the
generated strings depends on the decision of the
language maintainer who prepared the translated text.

The input sources encoding is not only dependent on the
human language used in comments, but it can depend also
on the OS being used.  For example, the default encoding
in MS Windows may differ from the default encoding used
in Unix.  This is the reason, why another Doxyfile
option should be introduced -- the input source
encoding. 

It is likely that some environment will start to use
Unicode versus the older 8bit encoding (i.e. similar
problem).  Because of this, some sources may use
different encoding than others.  This is also the reason
why another doxygen command should be introduced to
define the encoding of the source file explicitly, used
like here:

/*! \file xyz.cpp \encoding iso-8859-2 \brief Xxxxx... */

This could be directly used to define the heading of the
generated XML file as shown above.  Notice, that this
follows the approaches used with XML tools and files.

Even more general approach is to generate the XML output so that it 
is almost language independent.  I mean that the only
human-language related texts are extracted from the
documented source files.  The generated text can be
inserted via XML processing instructions with attributes
that will allow to decide the output language plus
encoding for the generated texts later.  The processing
instructions could look like this:

 <?doxtpl tpl="&trReimplementedFromList;" a1="&list001;" ?>

Some post-processor could be used to expand the doxygen
templates later.
 
However, there are some problems with the last mentioned
approach.  The main problem pointed by Dimitri is that
doxygen uses QT XML parser that is not capable to
process the entity definitions stored inside external
files.  Withou this capability, it does not make sense
to use the references to the entities.  This is probably
the main reason why Dimitri is using the approach that
resembles the current way of using translator classes.

If you are the developer who participate on XML part of
doxygen, on a generator part of doxygen, or if you are
the language maintainer familiar with XML and doxygen
internals, please read the attached document "Translator
Revisited" (just run doxygen to get the HTML form).
It is still a bit rough, but it contains many details 
that are directly related to the human languages known
to doxygen.  If QT XML parser became more capable or if
some XSLT library were chosen, then the approach could
be used.

 <<TranslatorsRevisited.zip>> 

I will appreciate comments to the "Translator Revisited"
and I will update it to include the discussion results;
however, I am currently too busy to produce any code for
doxygen.

Regards,
  Petr
-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-develop] setEncoding ?

[Haruyuki O. <oh...@is...>]

Hello

I think the latest doxygen generates ISO-8859-1 encoding for XML output.
But it does not seem to call QTextStream::setEncoding(QTextStream::Latin1)
in genarateXML function.
Is it correct ?

---
Haru

[Doxygen-develop] Is it better to add IO_Translate option for output text files ?

[Haruyuki O. <oh...@is...>]

I think it is better to add IO_Translate open file option for all output
*text* files.
I've checked the latest source code, but this option is rarely used.

Any suggestion ?

---
Haru

[Doxygen-develop] RE: DOCBOOK-APPS: Re: "Abbreviated" DocBook (notice about doxygen )

[Prikryl,Petr <PRI...@sk...>]

(This is related to "doxygen" and to its possible future
output into DocBook XML.  The message appeared in
doc...@li..., but now it seems to be
more related to doxygen than to DocBook.  Please, join
the dox...@li... if you want to
participate on doxygen development, and to follow this
discussion.)

Hi,

Matt Gruenke asked...
> > Petr Prikryl wrote...
> >
> > [...]  As far as I know, the XML
> > output will probably become a kind of intermediate (internal)
> > form of the generated results.  It is primarily tailored to
> > capture details generated by doxygen.  Then, the set of
> > generators then will produce final output formats.
> 
>  Are they planning on using XSLT to transform the XML into
>  the other output formats?  There are plenty of XSLT
>  libraries out there, including one from both the Apache
>  XML project and GNOME.  IMO, it'd be worth taking a very
>  close look at XSLT, for this.  From my own experience at
>  automatically generating DocBook from another fairly rich
>  XML vocabulary, I can say that one needs to actually put
>  a bit of thought into the architecture of the
>  stylesheets. (for those of you who're interested, this
>  might be a good place to start:
>  http://nwalsh.com/docs/articles/dbdesign/ )

Doxygen uses QT toolkit (the free part).  It implements
also some XML support.  I do not know if there is any plan
to use XSLT in doxygen.  Anyway, it seems to be natural to
use XSLT, IMHO.

> > There definitely are people among doxygen users who would
> > like to see DocBook XML as one of the final output form.
> > This is not the case, yet.  It would be nice to attract some
> > of the DocBook experts to doxygen development to accelerate
> > the DocBook XML generator development.
> 
> Since I'm currently working with documentation of software
> written in a fairly specialized, low-level language not
> supported by doxygen, I haven't spent much time looking at
> it.  However, since I'm interested in potentially using it
> for future projects, I have some ideas about the usage
> model I'd like to employ and features I'd like to use,
> relating to XML DocBook output.  Is there a forum for
> submitting such requests and suggestions?

As far as I know, there are some plans to separate input
parsers to be able to add other (programming) language
parsers.  So any volunteers will definitely be welcome.
In such case, you should probably contact Dimitri van Heesch,
the author of doxygen.

Try http://www.doxygen.org/ to obtain the general
information. Look also at the upper left corner of the
document for the reference to the mailing lists page
(dox...@li..., 
dox...@li...,
dox...@li...).

Regards,
  Petr

-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

Re: [Doxygen-develop] XML_MULTIPLE_FILES configuration tag

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

On Wed, Jan 09, 2002 at 03:42:15PM -0800, Christian Hammond wrote:
> Attached is a patch that provides an XML_MULTIPLE_FILES configuration
> tag. When this option is set to YES (and when GENERATE_XML is set to
> YES, of course), Doxygen will generate a file for each namespace,
> file, class, struct, etc., similar to the output method for HTML.

What a coincedence! Just after releasing 1.2.13.1 I made similar changes 
to the XML output (for memory saving reasons; just reading everything 
into memory does not work for large projects). I also generate an index
where all other XML files are listed.

> I plan to write another patch later that would generate the other
> files similar to annotated.html, files.html, functions.html, etc. My
> current plan is to add another config option, but perhaps these files
> should just be generated along with the other files when
> XML_MULTIPLE_FILES is set?

I like the idea. This would make it easier for generating documentation
when working directly with the generated output. IMHO, there is no need 
to make this optional.

Regards,
  Dimitri

[Doxygen-develop] XML_MULTIPLE_FILES configuration tag

[Christian H. <ch...@gn...>]

Attached is a patch that provides an XML_MULTIPLE_FILES configuration
tag. When this option is set to YES (and when GENERATE_XML is set to
YES, of course), Doxygen will generate a file for each namespace,
file, class, struct, etc., similar to the output method for HTML.

I plan to write another patch later that would generate the other
files similar to annotated.html, files.html, functions.html, etc. My
current plan is to add another config option, but perhaps these files
should just be generated along with the other files when
XML_MULTIPLE_FILES is set?

The patch was generated via a call to "cvs diff -u."

Christian

-- 
Christian Hammond         <>  The GNUpdate Project
ch...@gn...      <>  http://www.gnupdate.org/
   Computers are not intelligent. They only think they are.

[Doxygen-develop] Info on the status of the language translators (January 2002)

[Prikryl,Petr <PRI...@sk...>]

(January 8, 2002; zipped translator_report.txt attached)

Hallo to the language maintainers,

Firstly, I wish to all of you all the best in the New
Year.  You know, what are the things that would made
you happy.  Let's your good dreams come true.

My explicit thanks to all language maintainer who gave
their time for free to many many users.  My thanks to
the users who helped to improve doxygen.


Secondly,

   ----------------------------------------------------
   We are searching for Finnish and Swedish maintainers
   because their translators became extremely obsolete.
   Read the text below.
   ----------------------------------------------------

(This is the main reason why this message is posted
also to the "doxygen users" mailing list.)

Now, I am sending this as a reminder of status of the
translator classes for the supported languages (files
translator_xx.h).  No new translator methods were added
to the Translator class since doxygen 1.2.11.  Still,
there are things to improve.

Yesterday, I have updated the doxygen/doc/translator.pl
script that can help you with updating your TranslatorXxx class. 
The script and one of its results, the translator report, can be
found inside the zip fila attached to this message.

The translator report is generated automatically from
sources.  Because of this, it cannot capture human-like
recognition power.  On the other hand, the information
generated by the script should be quite accurate (or
accurately false -- tell me if you find some problem).

The last version of the translator report contains also
the following part:

----------------------------------------------------------------------
The following translator adapter classes are implemented -- the older (with
lower number) are always derived from the newer. They implement the
listed required methods. Notice that some versions of doxygen did not
introduce any changes related to the language translators.  From here you
may
guess how much work should be done to update your translator:
      
  TranslatorAdapter_1_2_11	implements  1 required method...
    QCString trReferences()

  TranslatorAdapter_1_2_7	implements  1 required method...
    QCString trAuthor(bool first_capital, bool singular)

  TranslatorAdapter_1_2_6	implements 13 required methods...
    QCString trRTFansicp()
    QCString trRTFCharSet()
    QCString trRTFGeneralIndex()
    QCString trFile(bool first_capital, bool singular)
    QCString latexLanguageSupportCommand()
    QCString idLanguageCharset()
    QCString trClass(bool first_capital, bool singular)
    QCString trNamespace(bool first_capital, bool singular)
    QCString trGroup(bool first_capital, bool singular)
    QCString trPage(bool first_capital, bool singular)
    QCString trMember(bool first_capital, bool singular)
    QCString trField(bool first_capital, bool singular)
    QCString trGlobal(bool first_capital, bool singular)

  TranslatorAdapter_1_2_5	implements  2 required methods...
    QCString trBug()
    QCString trBugList()

  TranslatorAdapter_1_2_4	implements  8 required methods...
    QCString trInterfaces()
    QCString trClasses()
    QCString trPackage(const char *name)
    QCString trPackageList()
    QCString trPackageListDescription()
    QCString trPackages()
    QCString trPackageDocumentation()
    QCString trDefineValue()

  TranslatorAdapter_1_2_2	implements  2 required methods...
    QCString trProperties()
    QCString trPropertyDocumentation()

  TranslatorAdapter_1_2_1	implements  1 required method...
    QCString trDCOPMethods()

----------------------------------------------------------------------

It clearly shows that it should not be very time
consuming to update the languages at least to the 1.2.4
status (4 of 25 languages).  

It also clearly shows that translators with status
1.2.7 and 1.2.11 can easily be updated to the
up-to-date status (5 languages).

The "Internalization" or "langhowto" part of the
documentation will be updated to match the
translator.pl improvements.

The main problem are the Finnish and Swedish
translators.  It seems that the maintainers are
unreachable.  Their translator classes are very
obsolete.  This will probably cause complication with
near future development.  In the worst case, the
languages may be removed from doxygen.

You can find the zipped translator_report.txt
attached to this message.  The content basically says 
what methods are to be implemented and what methods
should be removed (never used).

 <<tr200201.zip>> 
Here is the snippet from inside that lists the up-to-date
translators.

----------------------------------------------------------------------
The following translator classes are up-to-date (sorted alphabetically).
This means that they derive from the Translator class.  Anyway, there still
may be some details listed even for the up-to-date translators.
Please, check the text below if the translator is marked so.

  TranslatorBrazilian
  TranslatorCroatian
  TranslatorCzech
  TranslatorDutch
  TranslatorEnglish
  TranslatorFrench
  TranslatorGerman
  TranslatorItalian
  TranslatorJapanese    -- see details below in the report
  TranslatorKorean
  TranslatorPortuguese
  TranslatorRussian     -- see details below in the report
  TranslatorSlovak
  TranslatorSlovene

----------------------------------------------------------------------

It show that we have more up-to-date translators again.
Thanks to those, who updated.

The "see details below in the report" generally means
that there are probably some obsolete methods that
should be removed -- they are never used.  

Here the Russian is the exception, because it
implements some new, experimental methods, that were
recognized by the non-thinking script as obsolete (they
are not found in the abstract Translator class in
translator.h).  Read doxygen/html/langhowto.html (the
part of doxygen documentation) for details.

The "should be removed" methods are shown also for
obsolete translators.  In other words, removing
obsolete methods is the easiest way to make things
moving forward ;-)

Thanks for your attention,
  Petr
-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)