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

Re: [Doxygen-develop] Superscript does not work anymore since 1.8.7

[Marcin K. <ma...@ko...>]

Hello Andreas,

Please follow instructions on the following page for reporting bugs:
http://www.stack.nl/~dimitri/doxygen/manual/trouble.html

Thank You,
Marcin

On Oct 23, 2014, at 7:36 AM, Andreas Tscharner <an...@vi...> wrote:

> The subject says all: Superscript does not work any longer since at 
> least 1.8.7.
> 
> It does not matter if I use
> x^2
> x<SUP>2</SUP>
> &sup2;
> 
> They all result in "x^2" in the HTML output.
> 
> Best regards
> 	Andreas
> -- 
>       ("`-''-/").___..--''"`-._
>        `o_ o  )   `-.  (     ).`-.__.`)
>        (_Y_.)'  ._   )  `._ `. ``-..-'
>      _..`--'_..-_/  /--'_.' .'
>     (il).-''  (li).'  ((!.-'
> 
> Andreas Tscharner   an...@vi...   ICQ-No. 14356454
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Superscript does not work anymore since 1.8.7

[Andreas T. <an...@vi...>]

The subject says all: Superscript does not work any longer since at 
least 1.8.7.

It does not matter if I use
x^2
x<SUP>2</SUP>
&sup2;

They all result in "x^2" in the HTML output.

Best regards
	Andreas
-- 
       ("`-''-/").___..--''"`-._
        `o_ o  )   `-.  (     ).`-.__.`)
        (_Y_.)'  ._   )  `._ `. ``-..-'
      _..`--'_..-_/  /--'_.' .'
     (il).-''  (li).'  ((!.-'

Andreas Tscharner   an...@vi...   ICQ-No. 14356454

[Doxygen-develop] Config: Special Commands Indicator

[Hans Z <za...@gm...>]

Hello,

Is it possible either in the current release or possibly in a future
release, to configure what the special commands indicator?  Very often
documentation contains at-signs or backslashes and while I know of the
workarounds to escape them, in some cases this becomes very tedious.

Would it be possible to add a configuration directive that allows
setting what the special commands indicator would be?  For example:

SPECIAL_CMD_INDICATOR = @@

Thank you,

---
Hans Zaunere / Managing Member / Stackware, LLC
              stackware.com   /   cnvyr.io

Re: [Doxygen-develop] Possible bug while producing documentation of java method which uses generics

[Moreno <mo...@gm...>]

Thank you for the suggestion. Anyway it doesn't work.


Moreno

2014-09-08 22:02 GMT+02:00 Doxygen <do...@gm...>:

>
>
> On 4 sep. 2014, at 17:33, Moreno <mo...@gm...> wrote:
>
> Hi all,
> we are trying to produce Doxygen documentation from Javadoc placed in code.
> We noticed that Doxygen 1.8.8 has fixed a similar bug about Java generics
> used by a class (
> http://github.com/doxygen/doxygen/commit/c3ddf3331239fb3f41e502a8337eee786ceaad06),
> but we are facing with a method that uses generics:
>
> ...
>
> */***
> * * This is a brief comment.*
> * * *
> * * @param handler your handler implementation*
> * */*
> * public <E extends BaseEvent, L extends BaseListener<E>> void
> addHandler(BaseHandler<E, L> handler) {*
> * // do something*
> * }*
>
> ...
>
>
> Seems that Doxygen completely ignores the code annotations from that
> method to the end of same class.
> The log doesn't say anything about that and the method is not reported on
> the produced html.
>
> Has anyone had the same problem?
>
>
> Not that I know, does it help if you put a space between the >>'s?
>
> Regards,
>   Dimitri
>

Re: [Doxygen-develop] Possible bug while producing documentation of java method which uses generics

[Doxygen <do...@gm...>]

> On 4 sep. 2014, at 17:33, Moreno <mo...@gm...> wrote:
> 
> Hi all,
> we are trying to produce Doxygen documentation from Javadoc placed in code.
> We noticed that Doxygen 1.8.8 has fixed a similar bug about Java generics used by a class (http://github.com/doxygen/doxygen/commit/c3ddf3331239fb3f41e502a8337eee786ceaad06), but we are facing with a method that uses generics:
> 
> 	...
> 	
> 	/**
> 	 * This is a brief comment.
> 	 * 
> 	 * @param handler your handler implementation
> 	 */
> 	public <E extends BaseEvent, L extends BaseListener<E>> void addHandler(BaseHandler<E, L> handler) {
> 		// do something
> 	}
> 	 
> 	...
> 	
> 
> Seems that Doxygen completely ignores the code annotations from that method to the end of same class.
> The log doesn't say anything about that and the method is not reported on the produced html.
> 
> Has anyone had the same problem?

Not that I know, does it help if you put a space between the >>'s?

Regards,
  Dimitri

[Doxygen-develop] Java pre and code tags are ignored

[Moreno <mo...@gm...>]

Hi all,
there is a way to produce a code snippet without losing indented code in
Eclipse?

We tried to use *<pre><code>* tag but these are ignored.
Using the spacing or the ~ in a row seems to work, but the help showed by
Eclipse is basically unreadable.

Has anyone had the same problem?

Thank you

--
Moreno

[Doxygen-develop] Possible bug while producing documentation of java method which uses generics

[Moreno <mo...@gm...>]

Hi all,
we are trying to produce Doxygen documentation from Javadoc placed in code.
We noticed that Doxygen 1.8.8 has fixed a similar bug about Java generics
used by a class (
http://github.com/doxygen/doxygen/commit/c3ddf3331239fb3f41e502a8337eee786ceaad06),
but we are facing with a method that uses generics:

...

*/***
* * This is a brief comment.*
* * *
* * @param handler your handler implementation*
* */*
* public <E extends BaseEvent, L extends BaseListener<E>> void
addHandler(BaseHandler<E, L> handler) {*
* // do something*
* }*

...


Seems that Doxygen completely ignores the code annotations from that method
to the end of same class.
The log doesn't say anything about that and the method is not reported on
the produced html.

Has anyone had the same problem?

Thank you

--
Moreno

[Doxygen-develop] Language-specific tags

[Vadim Z. <vz-...@ze...>]

 Hello,

 I'm working on generating documentation for the languages other than C++
from Doxygen comments in C++ code using SWIG (http://www.swig.org/). This
works by taking comments in C++ sources, optionally translating them to the
target language format (JavaDoc, reST/Sphinx, ...) and attaching them to
the classes/functions wrapping their C++ equivalents. Finally, either
Doxygen itself (if no translation has been done) or javadoc/sphinx (if the
comments were translated) can be used to produce the documentation for the
API in the other language.

 Perhaps surprisingly, this process seems to work rather well and such
auto-translated documentation is genuinely useful. However, there still are
some problems, notably some C++ comments don't make any sense in the target
language context and have to be fixed manually.

 The only way to do it I see is to add special Doxygen commands allowing to
indicate that some parts of the comments are for C++ documentation only.
And probably also, if only for symmetry, other commands that would on the
contrary only output something when generating documentation for the other
language and not C++, e.g.

	/**
		Some comment.

		General description.

		@forcpponly
		C++-specific part.
		@endforcpponly

		@forpythononly
		Python-specific part.
		@endforpythononly
	*/


 Nothing is required to support this at Doxygen level as these commands
could just be defined as aliases using @if to determine whether they should
output something or not. But I'd like to ask if anybody here has already
done anything like this, even if manually, without involving SWIG, and
maybe has some hints to share?

 And, also, just to avoid or at least reduce the risk of conflict with some
standard Doxygen command in the future, what should we call these commands?
I initially wanted to use just @pythononly/@endpythononly, for consistency
with the existing @docbookonly and such, but then decided that it would be
better to use something similar, but different, to emphasize that Python is
a programming language and not an output format. Would you have any advice
about this?

 TIA for any thoughts!
VZ

[Doxygen-develop] \deprecated and \todo in \enum description not in corresponding todo/deprecated list

[Andreas T. <an...@vi...>]

Hello World,

If I have a \deprecated or \todo in an \enum description (in a IDL 
file), these entries do not show up in the deprecated or todo list. 
\deprecated und \todo entries in method or interface descriptions are 
listed. The actual description of \enum is correct (\todo and 
\deprecated are shown).

Example:


   /** \enum MyEnum
     * \brief Brief description of my enum
     *
     * Longer description of my enum
     *
     * \todo A TODO for my enum which does not show up
     *
     *
     * \typedef MyEnum TheEnum
     *
     * Rename enumeration to a better name
     */
   [ uuid(9CAF43A5-75A0-42E5-B43C-D0BF92C3A773), version(1.0) ]
   typedef enum MyEnum
   {
     FirstEnum = 0x0001, //!< Description of first enum
     ...
     ...
     LastEnum = 0xFFFF  //<! Description of last enum
   } TheEnum;


The \todo does not show up in the list. It shows up, if it is moved 
below \typdef (but of course, it is then a TODO for the typedef, not the 
enum)

I noticed the exact same behavior for \deprecated.

Platform:
Windows 7 Professional, SP1, all patches applied (Microsoft Windows 
[Version 6.1.7601])
doxygen Version 1.8.7

Is this intended behavior or a bug?

Best regards
	Andreas
-- 
       ("`-''-/").___..--''"`-._
        `o_ o  )   `-.  (     ).`-.__.`)
        (_Y_.)'  ._   )  `._ `. ``-..-'
      _..`--'_..-_/  /--'_.' .'
     (il).-''  (li).'  ((!.-'

Andreas Tscharner   an...@vi...   ICQ-No. 14356454

Re: [Doxygen-develop] OS X doxywizard build

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

Hi Chris,

On 24 Jul 2014, at 14:17 , Chris Krycho <ch...@kr...> wrote:
>  
> I’m running Doxygen on OS X, and am interested in updating the Qt build so
> that the various GUI tools (which are super handy) render correctly on "retina"
> devices on OS X. This should be pretty straightforward -- it's just a tweak to
> the `.plist` file. I can probably do it in a weekend. Before I jump in, though,
> I wanted to make sure I was heading the right direction, so a few questions:
> 
>  1. At present, it looks like you’re using the unmodified Qt settings to
>     generate all the OS X files -- i.e. you are *not* supplying them via the
>     `QMAKE_INFO_PLIST` build variable. Is that correct?

I'm running './configure --with-doxywizard' in the root of the distribution
followed by 'make' from the command line to build doxygen and the wizard.

>  2. It appears all the relevant source for the GUI tools are in the `addon`
>     directory -- is that correct?

Yes.

>  3. Building the Qt components failed with clang on OS X. I have standard GCC
>     as well, so this isn’t a problem for me but I wanted to check that you
>     knew this to be the case and see if you’re interested in getting clang
>     build support.

I've used Qt that came with MacPorts, but also built my own version for
combined 32-bit and 64-bit architectures using:

./configure -release -arch x86 -arch x86_64 -qt-libtiff -qt-libpng -qt-libjpeg -qt-libmng -fast --prefix=/usr

My compiler:
g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)

> 
> Finally, I assume I should just send a pull request on GitHub with the changes
> when I’m done?

Yes, please.

Regards,
  Dimitri

[Doxygen-develop] OS X doxywizard build

[Chris K. <ch...@kr...>]

 
I’m running Doxygen on OS X, and am interested in updating the Qt build so
that the various GUI tools (which are super handy) render correctly on "retina"
devices on OS X. This should be pretty straightforward -- it's just a tweak to
the `.plist` file. I can probably do it in a weekend. Before I jump in, though,
I wanted to make sure I was heading the right direction, so a few questions:

 1. At present, it looks like you’re using the unmodified Qt settings to
    generate all the OS X files -- i.e. you are *not* supplying them via the
    `QMAKE_INFO_PLIST` build variable. Is that correct?
 2. It appears all the relevant source for the GUI tools are in the `addon`
    directory -- is that correct?
 3. Building the Qt components failed with clang on OS X. I have standard GCC
    as well, so this isn’t a problem for me but I wanted to check that you
    knew this to be the case and see if you’re interested in getting clang
    build support.

Finally, I assume I should just send a pull request on GitHub with the changes
when I’m done?

Regards,
Chris Krycho

[Doxygen-develop] Finding of no documentation (@nodoc) API usage

[AMSTryst5iVe <tim...@bo...>]

Hi, is it possible to set a property/flag about a class or method (in c++)
that is @nodoc, and then having a css class on the generated html, so that
you style it differently?  We code for a major CAD application that some of
the API are risky to use.  They come with no documentation and can be remove
without notice.  For each of our applications we would want to document the
usages of these API.  In the CAD development .h files each occurrence of
@nodoc identifies the class or method that is marked as no documentation
(This depicts an Internal Resource. Its usage is prohibited.).

*Example:*
/**
 * @nodoc
 */
   CATNotification * GetRadBModifyNotification() const;

Thanks!



--
View this message in context: http://doxygen.10944.n7.nabble.com/Finding-of-no-documentation-nodoc-API-usage-tp6699.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

[Doxygen-develop] [dot] Inconsistent default margins for png vs. pdf

[Fredrik O. <for...@gm...>]

There seem to be an issue with inconsistent default margins when using dot
to generate "png" vs. "pdf" output. The "png" target appears to have narrow
margins as default (margin=0), where as the "pdf" target has significantly
larger default margins. I'm using Doxygen 1.8.7 and Graphviz 2.38 on
Windows 7.

The wide pdf margins are causing problems with figures taking up
unnecessary much space when using doxygen with dot to generate latex/pdf
documentation.

Could it be possible modify Doxygen to either add a "margin=0;" line to all
generated dot-files, or to provide a "-Fmargin=0" command-line argument to
dot, so that pdf figures becomes as compact as png figures?

Thanks in advance,
Fredrik Orderud

[Doxygen-develop] Displaying hyperlinks in Doxygen HTML content

[Dawson, M. <md...@da...>]

I have been using Doxygen to generate HTML reference content, based on comment text drawn from comments in C# header files.

I have been including a hyperlink to a PDF document in many of these comments, drawn from a public web site. The text I include with the comment describing the PDF document appears fine, but the HTML files that Doxygen generates never show the associated hyperlink.  The HREF reference statement is simply ignored.

Any ideas why this is happening?

I am using Doxygen version 1.5.2. Is that the problem?

[Doxygen-develop] Class dependency graph with doxygen

[Mikhail M. <mik...@gm...>]

Here is the sample code:

class Used {
public:
  void bar();
};

class Base { };

class Derived : public Base {
public:
  void foo(Used*);  // Dependency on class Used
};

Here is the collaboration diagram generated by doxygen:

[image: enter image description here]

Nice, but Derived depends on Used through the method foo, and I want to see
this on the diagram, like this:

[image: enter image description here]
Unfortunately, doxygen generates such dependency only if Used is aggregated
with Derived (used as a class member). Is there a way to show other kinds
of dependencies between classes?

-----
Best regards, Mikhail Matrosov

[Doxygen-develop] [Doxygen] [Tag Files] Latex documentation

[<Jit...@if...>]

Hello All,

I am trying to build the documentation in the Latex format. For this, I 
have multiple modules out of which only a few would change at a time. 
Hence, I was exploring the possibility of using the Tag files to generate 
and keep the documentation of all the modules and build only the changed 
modules before combining all the documentation together. In this, I can 
generate the tag files for each module, but am having issues when I am 
trying to combine the documentation for all the modules together. The code 
structure is -

base folder
        --> mod_1
                --> src
                --> include
                --> docs
        --> mod_2
                --> src
                --> include
                --> docs
        ....
        --> mod_n
                --> src
                --> include
                --> docs

The docs folder contains the tag files and the latex directory with the 
documentation. Hence, in my top level target, I set the following 
variables -
TAGFILES =      ../mod_1/docs/mod_1.tag=../mod_1/docs/latex \
                ../mod_2/docs/mod_2.tag=../mod_2/docs/latex \
                ......
                ../mod_n/docs/mod_n.tag=../mod_n/docs/latex

When I run doxygen, I do not see the documentation of the modules either 
embedded or a link to it in the main document. Please could you help me in 
figuring out what is the issue. One thing which I see is that whenever tag 
files are mentioned, I see only HTML type of documentation, but find no 
explicit (at least in the documents that I have seen) mention of tag files 
working only with HTML.

Thanks,
Jitesh Butala
Team Lead (Applications) - Sr. Design Engineer
ifm engineering pvt. ltd.  
www.ifm.com
CIN No. U29213PN2010FTC136766

[Doxygen-develop] unsubscribe

[<dav...@l-...>]

Re: [Doxygen-develop] Tcl parsing problem

[Roland V. <rv...@br...>]

Will do that. Thank you Albert.

From: Albert [mailto:alb...@gm...]
Sent: maandag 28 april 2014 20:05
To: Roland Vossen
Cc: dox...@li...; ser...@gm...; di...@st...
Subject: Re: Tcl parsing problem

Hi Roland,
I'm not familiar with the tclscanner and also not really familiar with the tcl language (changes that I made hadn't anything really to do with tcl but more with some general implementation stuff). I had a quick look but could not figure out the problem / the design philosophy behind the requirement of the space.
What I do see is that an error is emitted saying:
Error 1184 .../some_notok.tcl() at line 2! expected word separator:
A quick test disabling the error message (setting the internal variable myWhite to 0) did have the effect that the foo function is shown, but as I don't know the background of the space requirement I cannot change it.
Best is to file a bug in bugzilla.
Albert

On Mon, Apr 28, 2014 at 10:14 AM, Roland Vossen <rv...@br...<mailto:rv...@br...>> wrote:
Hello Albert,

When parsing a certain Tcl file, I noted that the majority of Tcl procs did not show up in Doxygens html output. I did some experiments and could drill it down to the following:

<some_file.tcl>
proc foo {} {
#       if { ($classifier_state == {{bphy} } ) } { OK
        if { ($classifier_state == {{bphy} }) } { ;# NOK
                puts "this proc is always shown in html output"
        }
}

proc bar {} {
        puts "this proc is not shown in html output in NOK case"
}

Note the subtle difference between the two 'if' statements: there is an extra space character between a '}' and the ')'.

Is this something you can look at ?

Thanks, Roland.

Re: [Doxygen-develop] Tcl parsing problem

[Albert <alb...@gm...>]

Hi Roland,

I'm not familiar with the tclscanner and also not really familiar with the
tcl language (changes that I made hadn't anything really to do with tcl but
more with some general implementation stuff). I had a quick look but could
not figure out the problem / the design philosophy behind the requirement
of the space.
What I do see is that an error is emitted saying:
Error 1184 .../some_notok.tcl() at line 2! expected word separator:
A quick test disabling the error message (setting the internal variable
myWhite to 0) did have the effect that the foo function is shown, but as I
don't know the background of the space requirement I cannot change it.

Best is to file a bug in bugzilla.

Albert


On Mon, Apr 28, 2014 at 10:14 AM, Roland Vossen <rv...@br...>wrote:

> Hello Albert,
>
> When parsing a certain Tcl file, I noted that the majority of Tcl procs
> did not show up in Doxygens html output. I did some experiments and could
> drill it down to the following:
>
> <some_file.tcl>
> proc foo {} {
> #       if { ($classifier_state == {{bphy} } ) } { OK
>         if { ($classifier_state == {{bphy} }) } { ;# NOK
>                 puts "this proc is always shown in html output"
>         }
> }
>
> proc bar {} {
>         puts "this proc is not shown in html output in NOK case"
> }
>
> Note the subtle difference between the two 'if' statements: there is an
> extra space character between a '}' and the ')'.
>
> Is this something you can look at ?
>
> Thanks, Roland.
>
>
>

[Doxygen-develop] Tcl parsing problem

[Roland V. <rv...@br...>]

Hello Albert,

When parsing a certain Tcl file, I noted that the majority of Tcl procs did not show up in Doxygens html output. I did some experiments and could drill it down to the following:

<some_file.tcl>
proc foo {} {
#	if { ($classifier_state == {{bphy} } ) } { OK
	if { ($classifier_state == {{bphy} }) } { ;# NOK
		puts "this proc is always shown in html output"
	}
}

proc bar {} {
	puts "this proc is not shown in html output in NOK case"
}

Note the subtle difference between the two 'if' statements: there is an extra space character between a '}' and the ')'.

Is this something you can look at ?

Thanks, Roland.

[Doxygen-develop] Doxygen development/debug IDE under OSX

[Marcin K. <ma...@ko...>]

Hi All,

Does anyone on this list do any development/debugging of Doxygen under OSX?

Do you have any suggestion for best IDE to use under OSX for this work?

If you have one, would you be willing to share your IDE project setup file for Doxygen?

Thank You,
Marcin Komorowski

Re: [Doxygen-develop] Some meta tags are not properly closed.

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

Hi Phil,

I've included your change in this commit
https://github.com/doxygen/doxygen/commit/4ccfb9efa8382de50dfc5b176cb147fd1b05870c

Regards,
  Dimitri

On 09 Apr 2014, at 16:07 , Phil Mason <phi...@br...> wrote:

> Hi,
>  
> When I run doxygen built from git head on some of my source the resulting html has meta tags that are not properly closed (and fail to pass the w3c validator as a result). The following is a sample of the html output (from html/search/all_0.html):
>  
> <html><head><title></title>
> <meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
> <meta name="generator" content="Doxygen 1.8.6">
>  
> Note that the second meta tag is not properly closed (and as the doctype of this file is XHTML it needs to be).
>  
> This trivial patch resolves this issue:
>  
> diff --git a/src/searchindex.cpp b/src/searchindex.cpp
> index 7aa8216..a550eb1 100644
> --- a/src/searchindex.cpp
> +++ b/src/searchindex.cpp
> @@ -1027,7 +1027,7 @@ void writeJavascriptSearchIndex()
>              " \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">" << endl;
>            t << "<html><head><title></title>" << endl;
>            t << "<meta http-equiv=\"Content-Type\" content=\"text/xhtml;charset=UTF-8\"/>" << endl;
> -          t << "<meta name=\"generator\" content=\"Doxygen " << versionString << "\">" << endl;
> +          t << "<meta name=\"generator\" content=\"Doxygen " << versionString << "\"/>" << endl;
>            t << "<link rel=\"stylesheet\" type=\"text/css\" href=\"search.css\"/>" << endl;
>            t << "<script type=\"text/javascript\" src=\"" << baseName << ".js\"></script>" << endl;
>            t << "<script type=\"text/javascript\" src=\"search.js\"></script>" << endl;
>  
> Hope this is useful
>  
> Regards
>  
> Phil
>  
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] Double dash within <tt> or <code> is again (or still?) broken

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

Hi Markus,

A recent change (independent of Markdown) was to treat -- as ndash and --- as mdash.

When MARKDOWN_SUPPORT is enabled you can already do what you want using `--prefix` (i.e. using backticks)
Without markdown support enabled the only way to prevent interpretation is to use \verbatim..\endverbatim,
so this is not very convenient for inline fragments.

I just committed a change to also allow escaping of -- and --- via \-- and \--- so you can also write
<tt>\--prefix</tt>.

Regards,
  Dimitri

On 12 Apr 2014, at 18:49 , Markus Geimer <mg...@we...> wrote:

> Hi,
> 
> This issue has already been reported ten years ago in bugreport
> https://bugzilla.gnome.org/show_bug.cgi?id=133418 and was marked
> as resolved, however, I see this issue again/still with current
> sources from git (just sync'ed my local copy).
> 
> Simply try something like
> 	<tt>--prefix</tt>
> or
> 	<code>--prefix</code>
> and you will get '&ndash;' in the HTML output and '--' in LaTeX
> (should be '-\/-' to prevent getting the en-dash). Same applies
> to the em-dash, though I assume that this is used less often in
> <tt>/<code> environments.
> 
> On the other hand, the LaTeX output contains an unnecessary italic
> correction for dashes between words. For example, 'so-called' is
> typeset as 'so-\/called'.
> 
> Unfortunately, I couldn't yet figure out where things go wrong.
> The output of '-d commentscan' already reports '--' or '&ndash;'
> depending on the MARKDOWN_SUPPORT setting, however, the final
> output is identical in both cases. Some hint where to start would
> be very welcome.
> 
> Thanks,
> Markus
> 
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Double dash within <tt> or <code> is again (or still?) broken

[Markus G. <mg...@we...>]

Hi,

This issue has already been reported ten years ago in bugreport
https://bugzilla.gnome.org/show_bug.cgi?id=133418 and was marked
as resolved, however, I see this issue again/still with current
sources from git (just sync'ed my local copy).

Simply try something like
	<tt>--prefix</tt>
or
	<code>--prefix</code>
and you will get '&ndash;' in the HTML output and '--' in LaTeX
(should be '-\/-' to prevent getting the en-dash). Same applies
to the em-dash, though I assume that this is used less often in
<tt>/<code> environments.

On the other hand, the LaTeX output contains an unnecessary italic
correction for dashes between words. For example, 'so-called' is
typeset as 'so-\/called'.

Unfortunately, I couldn't yet figure out where things go wrong.
The output of '-d commentscan' already reports '--' or '&ndash;'
depending on the MARKDOWN_SUPPORT setting, however, the final
output is identical in both cases. Some hint where to start would
be very welcome.

Thanks,
Markus

Re: [Doxygen-develop] [PATCH] Fix broken links to subpages in LaTeX output

[Markus G. <mg...@we...>]

Sorry, something went wrong when taring up the minimal example.
Here is the second try...

Markus

On 04/09/2014 07:34 PM, Markus Geimer wrote:
> Hi,
> 
> The attached patch fixes a bug in generating references to subpages (and
> potentially also other items) in the LaTeX output when PDF_HYPERLINKS is
> set to NO. I also included a minimal example.
> 
> Cheers,
> Markus