doxygen-users — List for users of doxygen

[Doxygen-users] Understanding how Doxygen Documentation is generated.

[Bob S. <do...@bo...>]

I'm trying to use doxygen to generate general documentation, in the same way 
that is appears it is used to generate the doxygen documentation itself, but 
I'm having some problems understanding how this documentation is generated.

In particular I have the following questions.

1. How is the doxygen manual divided into 3 parts. For example Part I starts 
with the following heading

Part I
User Manual

Greping the doc directory in the doxygen source shows that the only place 
this text occurs is in doxygen_manual.tex (A latex file I believe). I've 
found nothing in the doxygen documentation about using latex files as part of 
the source for doxygen. So is this file generated by doxygen? If it is 
generated by doxygen then where is the source that it used to get the "Part I 
User Manual" text?

2. While trying to regenerate the doxygen documentation from the doc 
directory, if I type make pdf in the ../latex directory I get the following 
latex error. Do I need a particular version of Latex.

[59]
Underfull \vbox (badness 10000) has occurred while \output is active [60]
Underfull \hbox (badness 10000) in paragraph at lines 167--167

) [61] (config.tex

! LaTeX Error: Environment multicols undefined.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

l.25 \begin{multicols}
                      {2}
?

The make pdf command does work if I type it before doing the doxygen Doxyfile 
command in the doc directory.


3. How do you generate different chapters. In my documentation each /page 
ends up being a different section in one big chapter.


Thanks

Bob Stafford

[Doxygen-users] Using <PRE> with Doxygen (got a problem!)

[Asko K. <Ask...@fi...>]

Hi, everyone!

Short version:     :>

I'd want ALL text that is extracted from my source files into Doxygen's
ouput to retain the source code formatting, that is, to be presented as =
a
'<PRE>' block in the HTML output. This should happen automatically, =
since
inserting <PRE> and </PRE> per each function messes up the source all =
too
much.

Long version:=20

I'm evaluating Doxygen for extracting documentation from an existing =
source
base. The functions already have a "header block" above their code so =
not
many changes should be necessary. Also, I want to preserve as much of =
the
current formatting as possible to keep comments easy to read in source =
code
as well.

Here's a sample comment block (unmodified):

	/*-------------------------------------
	* FlexLib_MakeDir()
	*
	* Returns:  TRUE if the directory already existed or could be
created.
	*
	* Notes:    Unlike the normal 'MakeDir()', this function is capable
of
	*           creating several levels of directory names if necessary.
	*--------------------------------------
	*/
	bool
	FlexLib_MakeDir( const char* path_and_possible_filename )
	{
	...

Simply by adding '/*!' in the beginning, I will get the comments into
Doxygen output. However (and here's where the problems begin) since I'm =
not
using the '\returns' etc. doxygen tags, the output is messy (no =
linefeeds
etc.) so I add '<pre> as well.

	/*! <pre>
	*-------------------------------------
	* FlexLib_MakeDir()
	*
	* Returns:  TRUE if the directory already existed or could be
created.
	*
	* Notes:    Unlike the normal 'MakeDir()', this function is capable
of
	*           creating several levels of directory names if necessary.
	*--------------------------------------
	*/
	bool
	FlexLib_MakeDir( const char* path_and_possible_filename )
	{
	...

Now I get the output nice but also a lot of warnings about missing =
'</pre>'
tags. Adding them will make the code look messy - don't want to do =
that.

In my opinion, a 'USE_SOURCE_FORMATTING' configuration would do the =
trick.
Has anyone else faced a similar situation and how did you solve it? =
Sorry if
I've missed something but I tried to read the docs carefully before =
posting
here! :)

- Asko

P.S. Also, a more straightforward PDF generation on Win32 would be
appreciated but I guess Linux would be a "more suitable" platform for
that...

--
Asko Kauppi                  ask...@fi...
Flextronics Design Finland   tel. +358 205 345 251
P.O.Box 23 (Jaakontie 1)     fax. +358 205 345 332
FIN-39200 Kyr=F6skoski         reg.no 572.960


###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft =
Exchange.

[Doxygen-users] Namespaces can cause function declaration/definition mismatches.

[Enea Z. <zaf...@ti...>]

Hi all.

The attached sample code shows a problem whereby functions definitions 
and declarations are not matched properly when using namespaces. In 
particular, it seems that the matching depends on _how_ my classes and 
functions are inserted into a particular namespace.

I found the following message in the archives, which seems to report a 
very similar problem ...

 > From: Car...@no...
 > To: dox...@li...
 > Date: Mon, 7 Jan 2002 16:29:10 +0200
 > Subject: [Doxygen-users] Problem with namespaces and templates
 >
 > Hi,
 >
 > I think I found a problem in Doxygen related to the matching between a
 > functions's declaration and it's definition, when namespaces and
 > templates are used:

[Doxygen-users] A bug when using <CODE>.

[Enea Z. <zaf...@ti...>]

Hi all.

The following small program shows a bug related to the use of the <CODE> 
  and </CODE> tags. The error is visible when the code tags enclose both 
the template instantiation "<...>" and the scope "::" syntactic 
operators of C++.

I am using version 1.2.14 and a default configuration file.

Apologies if this bug has already been reported ...

Regards,
Enea Zaffanella

[Doxygen-users] Feature request

[Evil K. <evi...@ya...>]

Hi Dimitri,

I'd like to request some features to add to your Todo/wish list, if you 
think they are worth it.

1)	Add Titles to items in the Modules page.  So instead of one massive list 
of items, I can split the modules page into sections, each with a 	specific 
title.
2)	Again, to be able to do this with the class heirarchy too.  Think about 
multiple DLL's in a project, I'd like to organise the modules and 
class 	heirarchy to display per DLL, rather than jumble them all up into 
one massive list, which is awkward to look through
3)	The ability to define the order the items appear in the modules list, 
rather than leave it to doxygen.  I would like for example to put 
certain 	items above others

If you could consider these for your list and get back to me if you want 
clarification on anything I suggested.  Seeing any of these would be 
excellant, cause I'm crying out for them.  Thanks!

kosh


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Doxygen-users] What class (HTML not C++) values are created in each html page

[Evil K. <evi...@ya...>]

hi guys,

	I've noticed that doxygen uses class elements to identify parts of a 
webpage, or to add emphasis to them without affecting the rest of the page, 
I'd like to know if there is a way to ask doxygen to give me a list of the 
class elements it creates, so I can alter their look in the style sheet.

thanks

kosh


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Doxygen-users] Any way to add Titles to the Modules page?

[Evil K. <evi...@ya...>]

Hello,
         I'd like to know if I can add Titles to the Modules page, to break=
=20
up the list of modules into manageable chunks. An example of what is and=20
what I want:

*****What I have currently*******

Here is a list of all modules:
=B7       Fusion Core
=B7       Graphics Subsystem
=B7               DirectGraphics8 Subsystem
=B7               Texture Formats
=B7               VertexPool formats
=B7               Window Device Interface
=B7                       Win32 Device
=B7               OpenGL Subsystem
=B7       Module Loader Database
=B7       Virtual File System
=B7               FileInfo structures
=B7               Data filters
=B7               VFS Handles
=B7                       Local file system Handle
=B7               VFS Plugins
=B7                       Binary File Format
=B7                       Targa File format
=B7                       Text File format

in other words, just one big huge list of classes, with little explanation=
=20
of what they are until you click on them, which isnt very helpful (yes, I'm=
=20
aware people *could* guess what they are, but the problem with that is the=
=20
*guess* word =3D] nobody should have to guess)

*****What I would like********

Here is a list of all modules:
=B7       Fusion Core

Graphics Subsystem:
=B7       DirectGraphics8 Subsystem
=B7       Texture Formats
=B7       VertexPool formats
=B7       Window Device Interface
=B7               Win32 Device
=B7       OpenGL Subsystem

Helper Classes:
=B7       Module Loader Database

Virtual File System:
=B7       FileInfo structures
=B7       Data filters
=B7       VFS Handles
=B7               Local file system Handle
=B7       VFS Plugins
=B7               Binary File Format
=B7               Targa File format
=B7               Text File format

Or something similar.  Then I can extend this for all my classes.  Is this=
=20
possible? Thanks!

Kosh


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Doxygen-users] Doxygen-1.2.14-20020310 in CVS

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

Hi,

Besides applying the redesign of the web-site (thanks to Christian Hammond),
I also committed the following changes to CVS:
-------------------------------------------------------------------------------
+ CHG: Links in the documentation to const/volatile members are now
       possible by explicitly specifying "f() const" or "f() volatile"
       in case a non-const/volatile "f()" also exists.
+ ADD: EPS images included with "\image latex" are automatically converted
       to pdf's if USE_PDFLATEX is set to YES.
+ ADD: Extended XML parser API (see addon/doxmlparser/include/doxmlintf.h)
       with full access to documentation blocks. Started with providing
       access to the various graphs generated by doxygen.
+ BUG: "doxygen -w latex header.tex doxygen.sty Doxyfile" caused a segmentation
       fault (thanks to Aric Cyr for the patch).
+ BUG: Fixed argument matching problem that occurred in some rare cases
       that involved "using" of namespaces.
+ BUG: Using /**< Brief.\ more brief. Details. */ with ENABLE_JAVADOC = YES,
       now removes the slash just like it did with /**...*/ style comments.
+ BUG: Using a ordered, html-style list inside a @param command
       resulted in invalid output if list item contained blank lines.
+ BUG: STRIP_FROM_PATH now also works with Windows style paths
       (e.g. C:\MyPath\)
+ BUG: A module can now appear more than once in the module tree
       (thanks to Itai Frenkel for the patch).
+ BUG: Changed the way PNGs are generated, so they work with Internet Explorer.
-------------------------------------------------------------------------------
Enjoy,
  Dimitri

[Doxygen-users] Automatic links don't work (partially)

[Andreas R. <a.r...@gm...>]

Hi!

I use Doxygen to document my projects and am very satisfied. It's a
really great tool!

However, when documenting example code (as shown in the \dontinclude
documentation), there are no references for the classes and objects
mentioned, neither in the program text nor in the documentation.

Have I missed something obvious? The autolinks work in class
documentation and the like.

Regards,
        Andy
--=20
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.=
at
Georg-Rendlweg 28        | A-5111 B=FCrmoos | Austria       | Europe
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B=
62

[Doxygen-users] Example summaries in the example list

[Jeff G. <je...@cr...>]

Is there a way to get example summaries into the example list?

Currently if I do something like:

/*! @example foo.cpp This example demonstrates.... */

In the example list we only get a list of .cpp files without any descriptions.
I didn't see a way to do this -- am I missing something or is this a feature
request?

Thanks,

Jeff

RE: [Doxygen-users] Struct members displaying inconveniently

[Moritz V. <th...@gm...>]

> > 	const gchar* IResources::EntryName (SLR_DIRECTORY directory,=20
> guint index) =20
> >=20
> > ...instead.
> >=20
> > Is this possible? If so, how?=20
>=20
> This is possible by writing an input filter that does the translation
> and let doxygen use that to filter the input (INPUT_FILTER).

Oh, thank you very much. I'll RTFM into that. *bounces off happily*

--
Regards,
 Moritz Voss=20

[Doxygen-users] java package names and fully qualified classnames

[Benoit C. <b.c...@wa...>]

Hi,
I'd like to know if it is to configure doxygen to produce the fully
qualified class name (package + class name) on top of the class
documentation file when dealing with java classes.
Benoit

Re: [Doxygen-users] Struct members displaying inconveniently

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

On Thu, Mar 07, 2002 at 11:35:34AM +0100, Moritz Voss wrote:
> A revamping of a former question of mine:
> I have structs that contain function pointers, to serve as interfaces. Doxygen documents them as...
> 
> 	const gchar*(* IResources::EntryName)(SLR_DIRECTORY directory, guint index)  
> 
> ...for example. I'd like to have them shown as...
> 
> 	const gchar* EntryName (SLR_DIRECTORY directory, guint index)  
> 
> ...or...
> 
> 	const gchar* IResources::EntryName (SLR_DIRECTORY directory, guint index)  
> 
> ...instead.
> 
> Is this possible? If so, how? 

This is possible by writing an input filter that does the translation
and let doxygen use that to filter the input (INPUT_FILTER).

An alternative is to package the function pointer into macros, and let
doxygen's preprocessor expand them in the way you want. But this requires
changes to the original code.

Regards,
  Dimitri

RE: [Doxygen-users] Documenting abstract base classes

[Jan R. <ja...@mo...>]

Hello Evil,
	Yes I know what you mean. The answer depends on whom you documenting
for. If you are documenting for the users/clients of the classes then I
would say document the "behavior" of each pure virtual function in the
abstract base class. That is all the clients should worry about. Clients
should not need to read any docs for the derived (implementation) classes,
they just need to know that those concrete classes exist.
	On the other hand if you are documenting for the maintainer of the
code then the long description for each implementation member function could
discuss the method and quirks involved in carrying out that particular
implementation. I think you can use the \internal keyword for these types of
comments.  This will allow you to generate a complete set of docs for
maintainers and a more cleansed set for users/clients.  Either
way you don;t double document the member functions in the derived class.
	One feature that I would find nice is some way to get a member
function listed without requiring any comment text.  For example

class File
{
  virtual void Open(const char* name,bool read_only) const; //!<
};

This declaration is largely self documenting, putting in a comment like 
//<! Opens a file.

is redundant.  BUT Doxygen will ignore this function as typed above, I have
to put at least one character after //!< to get the function listed. And a
line is wasted in the generated docs.

Regards
Jan
	


> -----Original Message-----
> From: Evil Kosh [mailto:evi...@ya...]
> Sent: Thursday, March 07, 2002 10:45 AM
> To: Doxygen Mailing list
> Subject: [Doxygen-users] Documenting abstract base classes
> 
> 
> Hi guys, busy tonight huh =]
> 
> okay, I was wondering, if I have an abstract base class and a 
> derived type, 
> the methods in the base class and derived class do the same 
> job, but where 
> to put the documentation saying what the method does.  What I 
> mean, is 
> you've got the abstract base class, do you put the 
> documentation saying 
> what each method does in there with the class, or do you 
> leave all the 
> documentation for each implementation you do of that base 
> class?  Since if 
> you have a base class and derived class, if you document 
> both, you'll be 
> repeating documentation wont you, for each class, so it seems kinda 
> silly.  Especially when you read the documentation back to 
> yourself, you 
> read the definition, it says "Opens a File", then nothing 
> else, then you 
> read the implemenation, it says "Opens a File" and then goes 
> on to say what 
> the actions of the method are, what it does, etc etc.
> 
> Does anyone know what I mean? if they do, what do you do in 
> this situation? 
> do you only document the abstract base class or the derived, 
> or do you 
> document both?
> 
> thanks again!
> 
> kosh 
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

RE: [Doxygen-users] Struct members displaying inconveniently

[Moritz V. <th...@gm...>]

Hehe!

My point was, I want Doxygen to display it differently from the correct =
syntax which we're using :) Simply because it'd make it feel more like =
C++, not like C bent in ways it's not supposed to go (object =
orientation).


I actually wasn't aware, though, that K&R requires the function to be =
called=20

> (*st.EntryName) ();

this way. (thanks about that, but it's irrelevant as for my problem)


--
Regards,
 Moritz Voss=20

Re: [Doxygen-users] Struct members displaying inconveniently

[<eds...@ya...>]

The correct function pointer syntax is the syntax that
Doxygen uses: 

const gchar* (*IResources::EntryName) (....);

As a liberality (syntatic sugar), C++ allows you to
CALL (not declare) the function pointed to by
EntryName as:

IResources st;
st.EntryName = ...address of some function...;
st.EntryName ();

instead of the old K&R C style:

(*st.EntryName) ();

but you must not declare a function pointer as it
would be a method declaration:

const gchar* IResources::EntryName (....);

is a declaration of a method that returns a const
gchar * ...


 --- Moritz Voss <ma...@mo...> WROTE: > A
revamping of a former question of mine:
> I have structs that contain function pointers, to
> serve as interfaces. Doxygen documents them as...
> 
> 	const gchar*(* IResources::EntryName)(SLR_DIRECTORY
> directory, guint index)  
> 
> ...for example. I'd like to have them shown as...
> 
> 	const gchar* EntryName (SLR_DIRECTORY directory,
> guint index)  
> 
> ...or...
> 
> 	const gchar* IResources::EntryName (SLR_DIRECTORY
> directory, guint index)  
> 
> ...instead.
> 
> Is this possible? If so, how? 
> 
> --
> Regards,
>  Moritz Voss 
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
>
https://lists.sourceforge.net/lists/listinfo/doxygen-users 

_______________________________________________________________________________________________
Yahoo! Empregos
O trabalho dos seus sonhos pode estar aqui. Cadastre-se hoje mesmo no Yahoo! Empregos e tenha acesso a milhares de vagas abertas!
http://br.empregos.yahoo.com/

[Doxygen-users] Documenting abstract base classes

[Evil K. <evi...@ya...>]

Hi guys, busy tonight huh =]

okay, I was wondering, if I have an abstract base class and a derived type, 
the methods in the base class and derived class do the same job, but where 
to put the documentation saying what the method does.  What I mean, is 
you've got the abstract base class, do you put the documentation saying 
what each method does in there with the class, or do you leave all the 
documentation for each implementation you do of that base class?  Since if 
you have a base class and derived class, if you document both, you'll be 
repeating documentation wont you, for each class, so it seems kinda 
silly.  Especially when you read the documentation back to yourself, you 
read the definition, it says "Opens a File", then nothing else, then you 
read the implemenation, it says "Opens a File" and then goes on to say what 
the actions of the method are, what it does, etc etc.

Does anyone know what I mean? if they do, what do you do in this situation? 
do you only document the abstract base class or the derived, or do you 
document both?

thanks again!

kosh 


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Doxygen-users] Grouping parts of the class Heirarchy together

[Evil K. <evi...@ya...>]

Hi guys

I'd like to group parts of the class Heirarchy page together, each group, 
representing a module in my class library but I'm unsure whether you can do 
this, since this would clean up the page and make it a LOT more readable, 
especially since in some cases, my codebase uses directories to split 
classes apart from each other, rather than class names, for example

src/OpenGL/Graphics.cpp
src/Direct3D/Graphics.cpp

two different classes, but same filename and same class name, split only by 
the implementation.  Hence being able to group the classes together, say 
into OpenGL and Direct3D groups, would help make the page more readable.

Anyone have any suggestions?


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Doxygen-users] Struct members displaying inconveniently

[Moritz V. <ma...@mo...>]

A revamping of a former question of mine:
I have structs that contain function pointers, to serve as interfaces. =
Doxygen documents them as...

	const gchar*(* IResources::EntryName)(SLR_DIRECTORY directory, guint =
index) =20

...for example. I'd like to have them shown as...

	const gchar* EntryName (SLR_DIRECTORY directory, guint index) =20

...or...

	const gchar* IResources::EntryName (SLR_DIRECTORY directory, guint =
index) =20

...instead.

Is this possible? If so, how?=20

--
Regards,
 Moritz Voss=20

[Doxygen-users] Wrong include?

[DVZ <oc...@ma...>]

Hi,

I write the library with name CL and all includes of it are in the
common include path so to use some class from it one should write
#include <CL/memory.h> and desc of CL/memory.h is

/**
  * \file memory.h CL/memory.h
  * base and common exceptions
  *
  */


but doxygen class reference for some class from this library contains
#include <memory.h>.

Is it possible to make doxygen understand what include it should
write? I'm using doxygen 1.2.14.

-- 
Best regards,
 Denis

[Doxygen-users] Doxygen for MS-IDL

[Christian J. <Chr...@ma...>]

I downloaded Doxygen for the purpose of documenting COM-Interfaces and =
classes,=20
whose descriptions are read from IDL-Files (Microsoft Style).

Apparently, Doyxgen douesn't  know about CoClasses, at least it wo'nt =
generate any
html for them. I tried to use a preprocessor replacement =
(coclass=3Dclass), but this way,
Doxygen doesn't recognize the 'members' of my coclasses, which in fact =
are interfaces.

This behaviour seems strange, for Doxygen is said to cope with MS-IDL =
code
Did I miss a hint about a switch somewhere in the documentation?=20
Apparently nobody posted a similar question to this list in the past.

Thanks for a quick answer.
   Regards,
      Christian Jung

[Doxygen-users] Alphabetical ordering Class Heirarchy

[John <joh...@te...>]

Hi,

Regarding the Class Heirarchy page, is it possible to tell/hint doxygen to
include the namespace names that are prefixed to the class names when it
alphabetically orders the classes?

Thanks,
John

RE: [Doxygen-users] newbie with a question

[Glenn M. <gle...@vo...>]

You have to understand that Doxygen looks at the whole system at once on
multiple passes so that it can resolve dependencies and get hyperlinks.
It doesn't work well in your favor to fetch "just what it needs when it
needs it."

The solution is what you do outside of the doxygen calls. I use Doxygen
on Unix and always call it through script files. (If it were DOS, I'd be
doing it with batch files.) The script files wrap around the Doxygen
calls with operations like removing stuff from last run, checking out
code, running Doxygen, and then cleaning up.

Something else to consider is to break up your project into smaller
projects. Look into the tag file options, because they resolve
dependencies between projects. Incorporating multiple projects will
allow you to fetch smaller sections of code.

Download www.voyanttech.com/tp_tools.zip (1.8 MB), unzip, and launch
tp_tools/_start_here.html for ideas on what can be accomplished and
open-source tools on how.

Glenn Maxey
Technical Writer
Voyant Technologies, Inc.
1765 West 121st Avenue
Westminster, CO 80234-2301
Tel. +1 303.223.5164
Fax. +1 303.223.5275
gle...@vo...



> -----Original Message-----
> From: Christopher Bark [mailto:ba...@ne...]
> Sent: Friday, March 01, 2002 2:49 PM
> To: dox...@li...
> Subject: [Doxygen-users] newbie with a question
>=20
<snip>
=20
> Is there anyway to set up doxygen to receive input files from a source
> code control system (perforce in my case, but others could=20
> come in handy). =20
> The project I'm working on is large and I don't want to get every file
> onto my machine in order to generate doxygen documentation, I'd rather
> just retrieve the file from the server as doxygen needs it.
>=20
> If doxygen doesn't already do this (which it doesn't from=20
> what I've seen
> so far), are there any patches out there that will let it?
>=20
> Thanks in advance.
>=20
> --=20
>   Dude...where's my sig?
>=20
>   Christopher Bark
>   ba...@ne...
>=20
>=20
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>=20

[Doxygen-users] newbie with a question

[Christopher B. <ba...@ne...>]

Hi, sorry to pose this question here, but I can't find anything in the FAQ
or documentation that answers this.

Is there anyway to set up doxygen to receive input files from a source
code control system (perforce in my case, but others could come in handy).  
The project I'm working on is large and I don't want to get every file
onto my machine in order to generate doxygen documentation, I'd rather
just retrieve the file from the server as doxygen needs it.

If doxygen doesn't already do this (which it doesn't from what I've seen
so far), are there any patches out there that will let it?

Thanks in advance.

-- 
  Dude...where's my sig?

  Christopher Bark
  ba...@ne...

[Doxygen-users] Extra paragraph tags?

[Mark B. <ma...@ea...>]

I just started using doxygen 1.2.12-1 and I noticed that in the generated 
HTML, there seems to be extra paragraph tags.  Is this by design?

For example, the following java comment ...
	
    /**
     * Creates bar-coded tray labels for an automated standard mail
     * letter-size mailing.  Bar-coded tray labels are required for
     * mailings of automation rate First-Class Mail, Periodicals, and
     * Standard Mail letter-size pieces.
     *
     * Each tray label is built from three lines pieces of
     * information:
     [snip]
    
creates the following HTML (with three <p> tags):

[snip]
<hr><a name="_details"></a><h2>Detailed Description</h2> Creates bar-coded 
tray labels for an automated standard mail letter-size mailing. Bar-coded 
tray labels are required for mailings of automation rate First-Class Mail, 
Periodicals, and Standard Mail letter-size pieces. 
<p>

<p>

<p> Each tray label is built from three lines pieces of information:
[snip]

Is this how it is supposed to work?  In Konquerer, the paragraphs look 
like they are too far apart.  I've looked through the docs and the last 
few months of mailing list archives and didn't see any similar question 
posted.

Mark