GNOME Bugzilla – Bug 352420
use of \doxyref is wrong
Last modified: 2006-11-10 19:38:40 UTC
Please describe the problem: doxygen 1.4.7 produces bad LaTeX code in some cases. the patch below fixes the LaTeX output for that special case. for reference, here is the LaTeX output of doxygen 1.4.6 and 1.4.7 (it was produced from some customer source code and I'm not used to C++, so I can't provide a full example, sorry): --------------------- 1.4.6 ------------------------- Erneute Implementation in {\bf CPlausi\-Kurve} {\rm (S.\,\pageref{dc/dd8/class_c_plausi_kurve_f0aae9a74656a669700fdbec06c8b47b})}. Definiert in Zeile 610 der Datei plausi.cpp.\index{CPlausi@{CPlausi}!create@{create}} --------------------- 1.4.7 ------------------------- Erneute Implementation in \bf{CPlausi\-Kurve} \doxyref{S.}{dd/d49/class_c_plausi_kurve_283d5859c846d7a61efec66e7ac942e8}. Definiert in Zeile 610 der Datei plausi.cpp. ----------------------------------------------------- note the missing 1st argument for \doxyref and the wrong usage of \bf . with this patch I can generate a 250+ page LaTeX doc from said source code: --- doxygen-1.4.7/src/latexgen.cpp~ 2006-05-07 20:02:31.000000000 +0200 +++ doxygen-1.4.7/src/latexgen.cpp 2006-08-22 17:40:22.000000000 +0200 @@ -999,7 +999,7 @@ } else { - t << "\\bf{"; + t << "\\textbf{"; // or: "{\\bf " docify(text); t << "}"; } @@ -1007,7 +1007,7 @@ void LatexGenerator::startPageRef() { - t << " \\doxyref{"; + t << " \\doxyref{}{"; } void LatexGenerator::endPageRef(const char *clname, const char *anchor) Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Thanks. I'll include the patch in the next CVS update.
Created attachment 73451 [details] [review] handle case of !ref.isEmpty ==> external references
Missed the space after {\bf, and also external links were broken. This is my first try hacking the doxygen code, so I'm not sure if this handles every case, but most of this is taken from the HTML generator.
This bug was marked "assigned" by me some time ago, which means it should be fixed in version 1.5.0 and is hereby marked as such. I would kindly request you to check if this version indeed fixes the problem and reopen the bug report should you still see the same problem.
I had pulled the sources from CVS, and it looked like the patch was already applied when I pulled them almost one month after your first comment. So my patch would be needed in addition. I'm sorry about it not being in unified diff format -- I almost exclusively use subversion and it does unified diff by default. I can confirm that the things I patched are still a problem in CVS. I will repost my patch in unified diff format.
Created attachment 75040 [details] [review] doxygen_external_href.patch in unified diff format can't reopen the bug since I'm not the original reporter
(In reply to comment #6) > Created an attachment (id=75040) [edit] > doxygen_external_href.patch in unified diff format > > can't reopen the bug since I'm not the original reporter but I can, so I've tested doxygen-1.5.0 (release tarball) and here we go with the bug open again... ;-) my test code only shows the problem of the missing space after {\bf in latexgen.cpp (see Ben's patch of latexgen.cpp). with that single fix, the 244 pages output seem to be ok. Ben, your first patch hunk for latexdocvisitor.cpp ("\bf{" vs. "{\bf ") seems to be included in 1.5.0 already, but your change to LatexDocVisitor::startLink is not included in 1.5.0. I can't comment on that last change, it looks like my test case doesn't depend on that one.
Harald: I've missed a space indeed. I'll add it. Ben: I don't understand the changes you made to LatexDocVisitor::startLink, in particular this part: + else + { + QCString *dest; + m_t << "\\href{"; + if ((dest=Doxygen::tagDestinationDict[ref])) m_t << *dest << "/"; + if (!file.isEmpty()) m_t << file << Doxygen::htmlFileExtension; + if (!anchor.isEmpty()) m_t << "#" << anchor; + m_t << "}{"; + } I don't think this will work, as it will link to a HTML file!
It does generate links to external HTML files. My understanding is that ref.isEmpty() for all internal links, so this should only happen for TAGFILES = library.doxytag=http://host/subdir I also believe that the previous implementation had no support for TAGFILES in the pdf output so I'm not breaking anything, am I? I'm using it to sprinkle links to external websites through my documentation, where the URL of the external site is not known in advance, but specified using a doxytag file, but I think it works equally well for referencing library documentation hosted externally on the web, or on a Windows or NFS share. I guess since the hyperlink latex package supports pdf->pdf links, the behavior should be different when TAGFILES specifies a PDF file. This then should affect generated HTML pages as well. It could be useful to link into CHM documentation as well, but I can't see any point in trying to link to generated manpages, xml, or perldoc. I guess that would ultimately require adding a destination doc type member to the Doxygen::tagDestinationDict dictionary. I'm willing to settle for all external links going to HTML, as my patch currently assumes.
Ah I see. I completely overlooked the option to link from PDF to HTML files. It all makes sense now, and I'll add your patch.
*** Bug 364381 has been marked as a duplicate of this bug. ***
*** Bug 365335 has been marked as a duplicate of this bug. ***
quick update: doxygen 1.5.1 works. please add this small patch, just in case someone might uncomment that code (or remove it -- at your choice;-) ------------------------------------------------------------------------------- diff -ur orig.016524/doxygen-1.5.1/src/latexgen.cpp doxygen-1.5.1/src/latexgen.cpp --- orig.016524/doxygen-1.5.1/src/latexgen.cpp 2006-10-20 19:23:08.000000000 +0200 +++ doxygen-1.5.1/src/latexgen.cpp 2006-11-09 11:18:57.000000000 +0100 @@ -962,7 +962,7 @@ //void LatexGenerator::writeClassLink(const char *,const char *, // const char *,const char *name) //{ -// t << "{\\bf"; +// t << "{\\bf "; // docify(name); // t << "}"; //} ------------------------------------------------------------------------------- thanks!
I'll add the patch, but since it has no impact I'm closing this bug report.