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

[Doxygen-develop] [PATCH] Bugs with bibliographies in HTML output

[Philipp M. <phi...@ge...>]

I have been trying to integrate \cite into our documentation and have
hit a few problems on the way. While trying to patch things, I came
across more issues and would like to know if anybody has clearer idea of
how to fix things.

First of all CiteDict::generatePage() in cite.cpp wont work when an
output directory is specified because the paths to the bib files wont
match up with the paths handed to bib2xhtml.pl

The attached doxygen_bib2xhtml_local.patch fixes this by using the
directory from which doxygen is run for the temporary citelist.doc and
the perl script.

[Doxygen-develop] Should <pre> blocks in code have uniform monospace?

[<fun...@ya...>]

The <pre> blocks in my code comments are normally ascii diagrams that refer to functions and classes.  As such, they are converted to links.  This is awesome.

Unfortunately, the font-weight of these links is "bold", which screws up the alignment of the ascii-diagram.  Could I suggest that font-weight be uniformly "normal" if you're inside a <pre> block?  

<style type="text/css">
    pre > .el { 
        font-weight:normal !important;
    }
</style>


I have a local workaround with using a customdoxygen.css per http://www.stack.nl/~dimitri/doxygen/customize.html.  Perhaps I'm weird for doing ascii-diagrams, but if I'm not, then others might like this fix.

Re: [Doxygen-develop] doxmlparser won't iterate past "protocol" compound

[Dimitri V. H. <do...@gm...>]

Hi Isaac,

I think a somewhat cleaner solution is given by the attached patch. Can you check if that works for you?

[Doxygen-develop] doxmlparser won't iterate past "protocol" compound

[Isaac W. <isa...@gm...>]

Hello everyone,

I'm trying to figure out how to use the doxmlparser classes and I've run
into a bit of trouble using the compounds() iterator. I have a bit of code
like the following:

ICompoundIterator *cli = dox->compounds();
> ICompound *comp;
>
> for(cli->toFirst(); comp = cli->current(); cli->toNext())
>   {
>           std::cout << "Processing " << comp->name()->latin1() <<
> std::endl;
>   }
>

But cli->current() returns 0 when it hits a compound with the kind
"prototype." I did a bit of digging and the offending code is in
compoundhandler.cpp's CompoundHandler::toICompound() which returns 0 if the
compound kind is not a class, struct, union, exception, interface,
namespace, file, group, or page. Surely the iterator shouldn't be halted by
an unknown type, should it? I think that the best behavior would be to
simply skip over compounds which aren't one of these predefined types.

My first thought was to change current() to something like this:

    CompoundEntry *ch = QListIterator<CompoundEntry>::current();
>
>     if(ch && !m_mainHandler->compoundById(ch->id.utf8()))
>     {
>       toNext();
>       return current();
>     }
>     else
>       return ch ? m_mainHandler->compoundById(ch->id.utf8()) : 0;
>

But that violates the const-ness of current() and doing away with the const
would be a very dirty hack (and I'm not actually sure if it would be
possible with the inheritance tree).

First I would like to know if this is indeed broken behavior. If it is,
what is the cleanest way to solve the problem? I am not particularly
familiar with doxmlparser. I'll keep hacking away, but I would love to know
if you have any simple solutions to the problem.

Regards,

Isaac

Re: [Doxygen-develop] Additional HTML character entities (for Greek symbols, etc.)

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

Charles Karney wrote:
>
> My goal is to be able to include text such as
> 
>    φ %le; 30°
> 
> in my source code and have the generated HTML documentation resemble
> the TeX math: $\phi \le 30^\circ$.  I would prefer not to have to deal
> with UTF-8 characters in my source files; lots of things will start to go
> awry if I don't stick with plain old 7-bit ASCII in my source; also
> it's faster for me to touch type φ than to figure out how to
> generate the UTF-8.  (Oh and the generated HTML will just contain φ
> etc.)
> 
> There was already a mechanism for dealing with HTML entities and it was
> simple enough to expand this.  Here's the list I ended up implementing
> (I constrained myself to entities which appear correctly with the
> default fonts for Firefox, Konqueror, and Internet Explorer).

I see.  You should probably discuss that directly with Dimitri because
he is the one to accept/refuse the code.  He may know what the pitfalls
are.  It may be related to the other-format output generators (like 
the LaTeX one). 

Petr

Re: [Doxygen-develop] Additional HTML character entities (for Greek symbols, etc.)

[Charles K. <cha...@sr...>]

My goal is to be able to include text such as

   φ %le; 30°

in my source code and have the generated HTML documentation resemble the
TeX math: $\phi \le 30^\circ$.  I would prefer not to have to deal with
UTF-8 characters in my source files; lots of things will start to go
awry if I don't stick with plain old 7-bit ASCII in my source; also it's
faster for me to touch type φ than to figure out how to generate the
UTF-8.  (Oh and the generated HTML will just contain φ etc.)

There was already a mechanism for dealing with HTML entities and it was
simple enough to expand this.  Here's the list I ended up implementing
(I constrained myself to entities which appear correctly with the
default fonts for Firefox, Konqueror, and Internet Explorer).

* Upper case Greek: Γ Δ Θ Λ Ξ Π Σ
   Υ Φ Ψ Ω

* Lower case Greek: α β γ δ ε ζ
   η θ ι κ λ μ ν ξ π ρ
   σ τ υ φ χ ψ ω ς

* Miscellaneous math symbols: § ° ′ ″ ∞
   ∅ ± × − ⋅ ∂ ∇ √ ⊥
   ∑ ∫ ∏ ∼ ≈ ≠ ≡ ∝ ≤ ≥ ←
   → ∈ ∉ ⌈ ⌉ ⌊ ⌋


On 2012-06-19 06:50, Petr Prikryl wrote:
>> From: Charles Karney
>> Sent: Thursday, June 14, 2012 7:17 PM
>>
>> I'm interested in adding support to Doxygen for the following HTML
>> character entities:
>>
>> * Upper case greek:ΓΔΘΛΞΠΣ
>>       ΥΦΨΩ
>> * Lower case greek:αβγδεζ
>>       ηθικλμνξπρ
>>       στυφχψω
>> * Variants of lower case greek:ϵϑϰ
>>       ϖϱςϕ
>> * Inequality relations:≤≥≠
>>
>> This all looks pretty straightforward (search for all occurrences of
>> AElig in the source and do the obvious thing).
>>
>> * Please let me know if someone already has this in hand.
>> * Are there any potential pitfalls I should be aware of?
>> * Are there other HTML character entities I should consider adding?
>
> In my opinion, the UTF-8 support is the way to go.  If the translator
> class supports UTF-8, there should be no problem with generation of
> the HTML in the UTF-8 encoding.
>
> What is your exact goal?  Do you mean to translate the entities
> from the source file into normal characters?
>
> Thanks,
>     Petr

Re: [Doxygen-develop] Additional HTML character entities (for Greek symbols, etc.)

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

> From: Charles Karney
> Sent: Thursday, June 14, 2012 7:17 PM
> 
> I'm interested in adding support to Doxygen for the following HTML
> character entities:
> 
> * Upper case greek: Γ Δ Θ Λ Ξ Π Σ
>      Υ Φ Ψ Ω
> * Lower case greek: α β γ δ ε ζ
>      η θ ι κ λ μ ν ξ π ρ
>      σ τ υ φ χ ψ ω
> * Variants of lower case greek: ϵ ϑ ϰ
>      ϖ ϱ ς ϕ
> * Inequality relations: ≤ ≥ ≠
> 
> This all looks pretty straightforward (search for all occurrences of
> AElig in the source and do the obvious thing).
> 
> * Please let me know if someone already has this in hand.
> * Are there any potential pitfalls I should be aware of?
> * Are there other HTML character entities I should consider adding?

In my opinion, the UTF-8 support is the way to go.  If the translator
class supports UTF-8, there should be no problem with generation of
the HTML in the UTF-8 encoding.

What is your exact goal?  Do you mean to translate the entities
from the source file into normal characters?

Thanks,
   Petr

Re: [Doxygen-develop] qhelpgenerator input file index.qhp broken in doxygen 1.8.1.1

[Dimitri V. H. <do...@gm...>]

Hi Acenes,

Can you send me an example of a problematic file? or better; and example that allows me to reproduce the problem?

Regards,
  Dimitri

On Jun 15, 2012, at 8:34 , Acenes wrote:

> After updating to 1.8.1.1 the heplgenerator stopped working. In doxywizard all seems ok, no error messages – but no qch file generated.
>  
> When manually running qhelpgenerator against index.qhp, this error is displayed:
>  
> „Error in line 1231: Opening and ending tag mismatch.“
>  
> After reinstalling 1.8.1 everything works again.
>  
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] qhelpgenerator input file index.qhp broken in doxygen 1.8.1.1

[Acenes <ac...@gm...>]

After updating to 1.8.1.1 the heplgenerator stopped working. In doxywizard
all seems ok, no error messages - but no qch file generated.

 

When manually running qhelpgenerator against index.qhp, this error is
displayed:

 

"Error in line 1231: Opening and ending tag mismatch."

 

After reinstalling 1.8.1 everything works again.

 

[Doxygen-develop] Additional HTML character entities (for Greek symbols, etc.)

[Charles K. <cha...@sr...>]

I'm interested in adding support to Doxygen for the following HTML
character entities:

* Upper case greek: Γ Δ Θ Λ Ξ Π Σ
     Υ Φ Ψ Ω
* Lower case greek: α β γ δ ε ζ
     η θ ι κ λ μ ν ξ π ρ
     σ τ υ φ χ ψ ω
* Variants of lower case greek: ϵ ϑ ϰ
     ϖ ϱ ς ϕ
* Inequality relations: ≤ ≥ ≠

This all looks pretty straightforward (search for all occurrences of
AElig in the source and do the obvious thing).

* Please let me know if someone already has this in hand.
* Are there any potential pitfalls I should be aware of?
* Are there other HTML character entities I should consider adding?

Thanks.

-- 
Charles Karney <cha...@sr...>
SRI International, Princeton, NJ 08543-5300

Tel: +1 609 734 2312
Fax: +1 609 734 2662

Re: [Doxygen-develop] [doxygen - doxygen-develop] wishlist : option to clean output

[Stefan G. <goe...@rh...>]

I definitely support this!

Cheers
Stefan

-- 
Dipl.-Ing. (FH) Stefan Göckeritz, M.Sc.
Fachhochschule Koblenz
RheinAhrCampus
Raum C209
Südallee 2
53424 Remagen
Tel: 02642/932-221
Fax: 02642/932-359


Am 26.05.2012 15:58, schrieb SourceForge.net:
> Read and respond to this message at:
> https://sourceforge.net/projects/doxygen/forums/forum/130996/topic/5304468
> By: asugix
>
> ask for feature to clean output files from doxygen command line or from
> doxywizard.
>
> _____________________________________________________________________________________
> You are receiving this email because you elected to monitor this topic or entire forum.
> To stop monitoring this topic visit:
> https://sourceforge.net/projects/doxygen/forums/forum/130996/topic/5304468/unmonitor
> To stop monitoring this forum visit:
> https://sourceforge.net/projects/doxygen/forums/forum/130996/unmonitor

Re: [Doxygen-develop] can xmlgen output both the declaration and definition ?

[Negreanu M. <gr...@gm...>]

On Tue, May 15, 2012 at 2:18 PM, Negreanu Marius <gr...@gm...> wrote:
> Hi,
>
> I'm using the xml files generated by doxygen, to implement a backend
> for mozilla's dxr indexing tool.
> While doing that, I noticed that only one of the two
> (declaration/definition) is written to the XML.
> So far I can't find any config value that controls that.
>
> Thus, the question: can xmlgen output both the declaration and definition ?
>
>
> Thanks

I managed to get the declaration emitted along the definitions by
going around the code
that merges the two (doxygen.cpp:buildFunctionlist)

One question I have is if I should make this behaviour configurable ?
(something like
EMIT_DECLARATIONS, in the XML section)

-- 
Regards!
http://groleo.wordpress.com

[Doxygen-develop] can xmlgen output both the declaration and definition ?

[Negreanu M. <gr...@gm...>]

Hi,

I'm using the xml files generated by doxygen, to implement a backend
for mozilla's dxr indexing tool.
While doing that, I noticed that only one of the two
(declaration/definition) is written to the XML.
So far I can't find any config value that controls that.

Thus, the question: can xmlgen output both the declaration and definition ?


Thanks

[Doxygen-develop] update Doxygen generated perl module

[Cunningham, J. <Jef...@am...>]

Initial guess - maybe statements in generated DoxyStructure.pm are conflicting with @param command in comments in source files. Not sure how to test this without further analysis.
Starting at Line 16 of DoxyStructure.pm file.

                                    parameters =>
                                      [ "list", $prefix . "Params",
                                                [ "hash", $prefix . "Param",
                                                  {
                                                    declaration_name => [ "string", $prefix . "ParamName" ],
                                                    type => [ "string", $prefix . "ParamType" ],
                                                  },
                                                ],
                                      ],
                                    detailed =>
                                      [ "hash", $prefix . "Detailed",
                                                {
                                                  doc => [ "doc", $prefix . "DetailedDoc" ],
                                                  return => [ "doc", $prefix . "Return" ],
                                                  see => [ "doc", $prefix . "See" ],
                                                  params =>
                                                    [ "list", $prefix . "PDBlocks",
                                                      [ "hash", $prefix . "PDBlock",
                                                                {
                                                                  parameters =>
                                                                    [ "list", $prefix . "PDParams",
                                                                      [ "hash", $prefix . "PDParam",

Jeff Cunningham

From: Cunningham, Jeffery
Sent: Monday, May 14, 2012 1:52 PM
To: 'dox...@li...'
Subject: Doxygen generated perl module

I have tested the perl module generated output and followed instructions. Issued command "make pdf" and processing halts on my source files (.hpp and .h files) that contain @param command in commented blocks. Don't know if this applies to other doxygen commands. When I remove files that contain this format or remove @param command from comments, then processing is done and pdf is created when I enter "make pdf".

For example, comments with doxygen commands @param or \param  as shown below:

/**
* Creates a relay object
* @param relayPin the pin to use for this relay object
*
*/

Jeff Cunningham

[Doxygen-develop] Doxygen generated perl module

[Cunningham, J. <Jef...@am...>]

I have tested the perl module generated output and followed instructions. Issued command "make pdf" and processing halts on my source files (.hpp and .h files) that contain @param command in commented blocks. Don't know if this applies to other doxygen commands. When I remove files that contain this format or remove @param command from comments, then processing is done and pdf is created when I enter "make pdf".

For example, comments with doxygen commands @param or \param  as shown below:

/**
* Creates a relay object
* @param relayPin the pin to use for this relay object
*
*/

Jeff Cunningham

[Doxygen-develop] Xml Schema

[Mansour Al A. <man...@gm...>]

Hello,
Is there any plans to support xml schema documentation ?
I was not able to find a true (fully) open source solution for XSDs.

Here's what I found so far:
http://www.filigris.com/products/docflex_xml/xsddoc

http://xframe.sourceforge.net/xsddoc/index.html for open source
projects only. It's backed by
http://www.buldocs.com/xnsdoc/index.html, but not updated since 2005.

http://xml.fiforms.org/xs3p/  (doesn't generate the nice format like
javadoc or doxygen).


Thank you.

[Doxygen-develop] Latex default fonts

[Alexis P. <ale...@fr...>]

Hi,

I have posted on the user mailing list asking how to configure doxygen
for using latex's default fonts (computer modern).
While waiting an answer, I made a patch adding an option about the
fonts in the configuration file (see attached file).

The output looks correct in my small documentation but tell me if
there is any mistakes ( it is my first patch :p ).

I plan to use it so it would be nice to have it in the mainline.

[Doxygen-develop] parse a string with doxygen

[Marcel H. <ke...@co...>]

hello everyone,

I'm a developer of Kdevelop and use doxygen for commenting. Aymk KDE 
itself uses qt and doxygen comment style.
Kdevelop has a feature that, if you hover a method/function/class, it 
displays its comments. But you will see \brief and \class and everything.
Is there a possibilty to tell doxygen that he only parses a string? So 
if you start it with a text as paramter he will print out html text.
If not, could you implement it or tell me an adequate method?

Regards,

Marcel Hellwig

[Doxygen-develop] "using" instead of "typedef"

[Marcel H. <ke...@co...>]

hello everyone,

with c++11 a "new" using declartion was introduced.
http://en.wikipedia.org/wiki/C%2B%2B11#Alias_templates

Something like this:
using HandlerPtr = std::shared_ptr<Handler>;
     instead of
typedef std::shared_ptr<Handler> HandlerPtr;

However, Doxygen does not support this and I want to ask if you may 
implement this.

Regards,

Marcel Hellwig

Re: [Doxygen-develop] [PATCH] VHDL Component Instantiation Fixes

[Robert A. <ab...@un...>]

Hi Martin,


On 2012/04/01 09:28, mkk1 wrote:
> The patch for generating this documentation. Patch is against the current
> trunk.
> I added some code from your patch.
> http://old.nabble.com/file/p33544964/svn_patch.patch svn_patch.patch 
I'm not sure how your patch prevents the multiple instances all being
generated for the inheritance tree... Whenever I allowed multiple
instances to be added to the instFiles list, it would create multiple
"inheritances" in the tree... I haven't tried your path though, will try
in the coming days.

Regards

Robert

Re: [Doxygen-develop] [PATCH] VHDL Component Instantiation Fixes

[mkk1 <mk...@gm...>]

mkk1 wrote:
> 
> I modified doxygen and generated the html documention for your
> DoxygenTestProject example.
> see http://www.2shared.com/file/hneieq4a/DoxygenTestProject.html
> Can you verify the generated html documentation.If the documentation is
> correct, I can post you a patch.
> 
> Martin
> 
The patch for generating this documentation. Patch is against the current
trunk.
I added some code from your patch.
http://old.nabble.com/file/p33544964/svn_patch.patch svn_patch.patch 

Martin
-- 
View this message in context: http://old.nabble.com/-PATCH--VHDL-Component-Instantiation-Fixes-tp33521670p33544964.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

Re: [Doxygen-develop] [PATCH] VHDL Component Instantiation Fixes

[Robert A. <ab...@un...>]

Hi Martin,

On 24.03.2012 22:37, mkk1 wrote:
> I modified doxygen and generated the html documention for your
> DoxygenTestProject example.
> see http://www.2shared.com/file/hneieq4a/DoxygenTestProject.html
> Can you verify the generated html documentation.
I'm not sure what you did, but it seems correct. However, your instances
are kind of out-of-order.
> If the documentation is
> correct, I can post you a patch.
Care to explain what you did differently than what was done in my patch?
Did you keep the list and re-added instances later somewhere?

Regards

Robert

Re: [Doxygen-develop] [PATCH] VHDL Component Instantiation Fixes

[mkk1 <mk...@gm...>]

I modified doxygen and generated the html documention for your
DoxygenTestProject example.
see http://www.2shared.com/file/hneieq4a/DoxygenTestProject.html
Can you verify the generated html documentation.If the documentation is
correct, I can post you a patch.

Martin
-- 
View this message in context: http://old.nabble.com/-PATCH--VHDL-Component-Instantiation-Fixes-tp33521670p33544694.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

Re: [Doxygen-develop] [PATCH] VHDL Component Instantiation Fixes

[mkk1 <mk...@gm...>]

Robert Abel wrote:
> 
> On 19.03.2012 20:27, Dimitri Van Heesch wrote:
>> Can you send me an example that I can use to test your patch?
> 
> Yes, please find an example here
> <https://sites.google.com/site/rawbdagslair/DoxygenTestProject.7z?attredirects=0&d=1>.
> My example includes the VHDL instantiation bug/graph creation bug and
> the XML tag file bug I posted more recently to the list.
> 
> You will have to run
> 
> old-doxygen DoxyfileB
> old-doxygen DoxyfileA
> 
> new-doxygen DoxyfileB
> new-doxygen DoxyfileA_Fix
> 
> srcA contains all a DFF (sub_component), a senseless inverted DFF
> (sub_sub_component) and a top level entity. Instantiating
> sub_sub_component in toplevel will hide sub_component in toplevel
> completely depending on the order the instantiations are processed by
> the parser. So you will see different results on each parse when you
> switch the locations of dffA, dffNotA and dffB.
> 
> On a side note, I just noticed that detail descriptions on
> instantiations don't work for some reason...
> 
> srcB is only for showcasing the XML tag file bug. It creates two groups
> with "special characters" (though they aren's /that/ special...). When
> you look inside docA, you will find them to be gibberish.
> 
>> I assume your maxlevel hack is used to see is a class is a direct
>> base class or sub class, right?
> Yes. It could be altered to be a boolean, either only direct
> "inheritance" or inheritance over all levels. That what would be needed
> for VHDL at least. However, I thought it might come in handy to have
> control over the depth of the recursion so the abort() can be avoided by
> other language parsers etc.
> 
> Regards,
> 
> Robert
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> 
> 

-- 
View this message in context: http://old.nabble.com/-PATCH--VHDL-Component-Instantiation-Fixes-tp33521670p33544693.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

Re: [Doxygen-develop] [BUG] Tag File Parsing Issue

[Dimitri V. H. <do...@gm...>]

Hi Robert,

On Mar 18, 2012, at 2:10 , Robert Abel wrote:

> Hi,
> 
> I'm currently using tag files to stitch multiple documentation files (for multiple programming languages) together.
> 
> There seem to be two bugs related to tag/xml files:
> 	• Tag files are statically produced with encoding='ISO-8859-1' (doxygen.cpp ll.10604).
> Yet there is not one instance of a conversion function used that I could find that would actually convert any tag file output from the source input file encoding given using INPUT_ENCODING. That doesn't seem right!

Indeed, all internal strings inside doxygen are UTF-8 encoded, so the tag files as well. I'll correct this.

> 	• There is a bug in tagreader.cpp. Basically, QXmlSimpleReader (qxml.cpp) will read any XML input file according to its encoding stated in each file. However, the TagFileParser handler in tagreader.cpp will store all incoming QString (16bit) strings inside m_curString which is a QCString (8bit) inside bool characters (tagreader.cpp ll. 789).
> This effectively annihilates the correctly parsed XML source encoding when curString is assigned to different information entities, e.g. when assigning group titles in ll. 664. While I'm not 100% sure what happens at this implicit conversion, I reckon the QString will be using the thread locale to convert the QCString back to 16bit, thus resulting in gibberish when thread locale and XML encoding mismatch.
> As a quick fix for 2.), I changed the declaration of m_curString to QString so no conversions take place (but there may be memory overhead wrt explicit/implicit sharing I read?). I didn't notice any immediate problems with this hack.

I plan to remove to implicit conversion from QString to QCString and use an explicit .utf8() everywhere.

> 
> As a fix for 1.) I propose to either actually convert to ISO-8859-1 from the INPUT_ENCODING, or just declare the XML file to be encoded using INPUT_ENCODING. The latter would be simplest and cleanest, IMHO.
> Also, please notice that 2.) cannot just be fixed by fixing 1.), since tag files might be produced by "3rd party" software using       any encoding they wish.

No, I would state that doxygen requires tag files to be UTF-8 encoded, rather than supporting arbitrary encodings or
depending on INPUT_ENCODING. Tag file are files to link different projects, which could have different INPUT_ENCODING settings.

> The quick and dirty fix for 2.) I did would probably need some revisitation by someone who knows about the memory overhead/sharing capabilities involved and can decide on a proper course of action. (Which is why I'm hesitant to post a [one-line] patch...)

Will do. I try to get rid of QString as much as possible.

Regards,
  Dimitri