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

[Doxygen-develop] [PATCH] ftv icons made lynx/accessible-compatible

[Vassilii K. <vas...@ta...>]

(I admit that my choice of the alt text to display the ftv nodes
may be a bit ugly, but it is much better anyway on my lynx than
what was there before. Anybody with better design inclinations
is welcome to tweak the text in the image_info[] initializer.)

Also, this patch inserts width/height for the icons (so that
the icons are rendered faster in graphical browsers that are
going to load/reload the icons).

Last thing, it abstracts the filenames management - right now
it is sufficient to rename the file in just the image_info[]
initializer and the new macros will take care of it in the
rest of the code.

Here it comes...

Index: ftvhelp.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/ftvhelp.cpp,v
retrieving revision 1.18
diff -u -p -r1.18 ftvhelp.cpp
--- ftvhelp.cpp	2003/04/30 19:40:08	1.18
+++ ftvhelp.cpp	2003/05/02 17:51:41
@@ -38,7 +38,6 @@ unsigned char ftv2blank_png[] = {
   0x32, 0xcb, 0x72, 0x8f, 0x7c, 0x12, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45,
   0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2blank_png_len = 174;

 unsigned char ftv2doc_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -64,7 +63,6 @@ unsigned char ftv2doc_png[] = {
   0x83, 0x47, 0xbd, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4e, 0x44, 0xae,
   0x42, 0x60, 0x82
 };
-unsigned int ftv2doc_png_len = 255;

 unsigned char ftv2folderclosed_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -90,7 +88,6 @@ unsigned char ftv2folderclosed_png[] = {
   0x13, 0x15, 0x98, 0x60, 0xbd, 0x81, 0x0b, 0x00, 0x00, 0x00, 0x00, 0x49,
   0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2folderclosed_png_len = 259;

 unsigned char ftv2folderopen_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -116,7 +113,6 @@ unsigned char ftv2folderopen_png[] = {
   0x0d, 0xa4, 0x29, 0x14, 0xcb, 0xda, 0x47, 0xac, 0x44, 0x00, 0x00, 0x00,
   0x00, 0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2folderopen_png_len = 261;

 unsigned char ftv2lastnode_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -140,7 +136,6 @@ unsigned char ftv2lastnode_png[] = {
   0x88, 0x10, 0xca, 0x33, 0x3d, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4e,
   0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2lastnode_png_len = 233;

 unsigned char ftv2link_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -174,7 +169,6 @@ unsigned char ftv2link_png[] = {
   0xcf, 0x07, 0x71, 0x95, 0x2b, 0xa1, 0x10, 0x78, 0xd0, 0xff, 0x00, 0x00,
   0x00, 0x00, 0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2link_png_len = 358;

 unsigned char ftv2mlastnode_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -192,7 +186,6 @@ unsigned char ftv2mlastnode_png[] = {
   0xc0, 0xdc, 0x69, 0xc8, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4e, 0x44,
   0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2mlastnode_png_len = 160;

 unsigned char ftv2mnode_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -213,7 +206,6 @@ unsigned char ftv2mnode_png[] = {
   0x96, 0x03, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4e, 0x44, 0xae, 0x42,
   0x60, 0x82
 };
-unsigned int ftv2mnode_png_len = 194;

 unsigned char ftv2node_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -237,7 +229,6 @@ unsigned char ftv2node_png[] = {
   0x52, 0x00, 0xe2, 0xfa, 0x45, 0x3a, 0xe1, 0x00, 0x00, 0x00, 0x00, 0x49,
   0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2node_png_len = 235;

 unsigned char ftv2plastnode_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -255,7 +246,6 @@ unsigned char ftv2plastnode_png[] = {
   0x00, 0x6e, 0xc1, 0x02, 0xc2, 0xe5, 0xed, 0x75, 0xa7, 0x00, 0x00, 0x00,
   0x00, 0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2plastnode_png_len = 165;

 unsigned char ftv2pnode_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -276,7 +266,6 @@ unsigned char ftv2pnode_png[] = {
   0xba, 0x6b, 0x07, 0x2f, 0xaa, 0xcb, 0x1f, 0x6f, 0x00, 0x00, 0x00, 0x00,
   0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
 };
-unsigned int ftv2pnode_png_len = 200;

 unsigned char ftv2vertline_png[] = {
   0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
@@ -300,31 +289,68 @@ unsigned char ftv2vertline_png[] = {
   0x3a, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60,
   0x82
 };
-unsigned int ftv2vertline_png_len = 229;


 struct ImageInfo
 {
+  const char *alt;
   const char *name;
-  unsigned char *data;
+  const unsigned char *data;
   unsigned int len;
+  unsigned short width, height;
 } image_info[] =
 {
-  { "ftv2blank.png",ftv2blank_png,ftv2blank_png_len },
-  { "ftv2doc.png",ftv2doc_png,ftv2doc_png_len },
-  { "ftv2folderclosed.png",ftv2folderclosed_png,ftv2folderclosed_png_len },
-  { "ftv2folderopen.png",ftv2folderopen_png,ftv2folderopen_png_len },
-  { "ftv2lastnode.png",ftv2lastnode_png,ftv2lastnode_png_len },
-  { "ftv2link.png",ftv2link_png,ftv2link_png_len },
-  { "ftv2mlastnode.png",ftv2mlastnode_png,ftv2mlastnode_png_len },
-  { "ftv2mnode.png",ftv2mnode_png,ftv2mnode_png_len },
-  { "ftv2node.png",ftv2node_png,ftv2node_png_len },
-  { "ftv2plastnode.png",ftv2plastnode_png,ftv2plastnode_png_len },
-  { "ftv2pnode.png",ftv2pnode_png,ftv2pnode_png_len },
-  { "ftv2vertline.png",ftv2vertline_png,ftv2vertline_png_len },
-  { 0,0,0 }
+  { " ", "ftv2blank.png",ftv2blank_png,174,16,22 },
+#define FTVIMG_blank 0
+
+  { "*", "ftv2doc.png",ftv2doc_png,255,24,22 },
+#define FTVIMG_doc 1
+
+  { "+", "ftv2folderclosed.png",ftv2folderclosed_png,259,24,22 },
+#define FTVIMG_folderclosed 2
+
+  { "-", "ftv2folderopen.png",ftv2folderopen_png,261,24,22 },
+#define FTVIMG_folderopen 3
+
+  { "\\", "ftv2lastnode.png",ftv2lastnode_png,233,16,22 },
+#define FTVIMG_lastnode 4
+
+  { "-", "ftv2link.png",ftv2link_png,358,24,22 },
+#define FTVIMG_link 5
+
+  { "\\", "ftv2mlastnode.png",ftv2mlastnode_png,160,16,22 },
+#define FTVIMG_mlastnode 6
+
+  { "o", "ftv2mnode.png",ftv2mnode_png,194,16,22 },
+#define FTVIMG_mnode 7
+
+  { "o", "ftv2node.png",ftv2node_png,235,16,22 },
+#define FTVIMG_node 8
+
+  { "\\", "ftv2plastnode.png",ftv2plastnode_png,165,16,22 },
+#define FTVIMG_plastnode 9
+
+  { "o", "ftv2pnode.png",ftv2pnode_png,200,16,22 },
+#define FTVIMG_pnode 10
+
+  { "|", "ftv2vertline.png",ftv2vertline_png,229,16,22 },
+#define FTVIMG_vertline 11
+
+  { 0,0,0,0,0,0 }
+#define FTVIMG_UNUSED 12
 };

+#define _S(nym) #nym
+#define FTV_ICON_FILE(nym) "ftv2" _S(nym) ".png"
+
+#define FTVIMG_INDEX(nym) FTVIMG_ ## nym
+#define _INFO(nym) ( image_info[FTVIMG_INDEX(nym)] )
+#define IMG_PREAMBLE(nym) \
+  "<img src=\"" FTV_ICON_FILE(nym) "\" " \
+    "alt=\"" << _INFO(nym).alt << "\" " \
+    "width=" << _INFO(nym).width << " " \
+    "height=" << _INFO(nym).height << " "
+
 struct FTVNode
 {
   FTVNode(bool dir,const char *r,const char *f,const char *a,const char *n)
@@ -467,22 +493,22 @@ void FTVHelp::generateIndent(QTextStream
     {
       if (n->isDir)
       {
-        t << "<img src=\"ftv2plastnode.png\" onclick=\"toggleFolder('folder" << folderId << "', this)\"/>";
+        t << IMG_PREAMBLE(plastnode) << "onclick=\"toggleFolder('folder" << folderId << "', this)\"/>";
       }
       else
       {
-        t << "<img src=\"ftv2lastnode.png\"/>";
+        t << IMG_PREAMBLE(lastnode) << "/>";
       }
     }
     else
     {
       if (n->isDir)
       {
-        t << "<img src=\"ftv2pnode.png\" onclick=\"toggleFolder('folder" << folderId << "', this)\"/>";
+        t << IMG_PREAMBLE(pnode) << "onclick=\"toggleFolder('folder" << folderId << "', this)\"/>";
       }
       else
       {
-        t << "<img src=\"ftv2node.png\"/>";
+        t << IMG_PREAMBLE(node) << "/>";
       }
     }
   }
@@ -490,11 +516,11 @@ void FTVHelp::generateIndent(QTextStream
   {
     if (n->isLast)
     {
-      t << "<img src=\"ftv2blank.png\"/>";
+      t << IMG_PREAMBLE(blank) << "/>";
     }
     else
     {
-      t << "<img src=\"ftv2vertline.png\"/>";
+      t << IMG_PREAMBLE(vertline) << "/>";
     }
   }
 }
@@ -550,7 +576,7 @@ void FTVHelp::generateTree(QTextStream &
     generateIndent(t,n,0);
     if (n->isDir)
     {
-      t << "<img src=\"ftv2folderclosed.png\" onclick=\"toggleFolder('folder" << folderId << "', this)\"/>";
+      t << IMG_PREAMBLE(folderclosed) << "onclick=\"toggleFolder('folder" << folderId << "', this)\"/>";
       generateLink(t,n);
       t << "</p>\n";
       t << spaces << "<div id=\"folder" << folderId << "\">\n";
@@ -560,7 +586,7 @@ void FTVHelp::generateTree(QTextStream &
     }
     else
     {
-      t << "<img src=\"ftv2doc.png\"/>";
+      t << IMG_PREAMBLE(doc) << "/>";
       generateLink(t,n);
       t << "</p>\n";
     }
@@ -601,6 +627,7 @@ void FTVHelp::generateTreeView()
     t << "<frameset cols=\"" << Config_getInt("TREEVIEW_WIDTH") << ",*\">" << endl;
     t << "  <frame src=\"tree" << Doxygen::htmlFileExtension << "\" name=\"treefrm\">" << endl;
     t << "  <frame src=\"main" << Doxygen::htmlFileExtension << "\" name=\"basefrm\">" << endl;
+	/// @todo provide a <noframes> alternative before closing the frameset
     t << "</frameset>" << endl;
     t << "</html>" << endl;
     f.close();
@@ -639,6 +666,8 @@ void FTVHelp::generateTreeView()
       t << cssfi.fileName();
     }
     t << "\">" << endl;
+	/// @todo provide alt for images so that lynx shows it all right
+	/// and for disabled readers that use it via Braille or TTS
     t << "    <title>TreeView</title>\n";
     t << "    <style type=\"text/css\">\n";
     t << "    <!--\n";
@@ -680,7 +709,7 @@ void FTVHelp::generateTreeView()
     t << "    {\n";
     t << "      var folder = document.getElementById(id);\n";
     t << "      var l = 0;\n";
-    t << "      var vl = \"ftv2vertline.png\";\n";
+    t << "      var vl = \"" FTV_ICON_FILE(vertline) "\";\n";
     t << "      if (imageNode != null && imageNode.nodeName != \"IMG\") \n";
     t << "      {\n";
     t << "        imageNode = findChildNode(imageNode, \"IMG\");\n";
@@ -700,14 +729,14 @@ void FTVHelp::generateTreeView()
     t << "        if (imageNode != null) \n";
     t << "        {\n";
     t << "          l = imageNode.src.length;\n";
-    t << "          imageNode.nextSibling.src = \"ftv2folderclosed.png\";\n";
-    t << "          if (imageNode.src.substring(l-13,l) == \"ftv2mnode.png\")\n";
+    t << "          imageNode.nextSibling.src = \"" FTV_ICON_FILE(folderclosed) "\";\n";
+    t << "          if (imageNode.src.substring(l-13,l) == \"" FTV_ICON_FILE(mnode) "\")\n";
     t << "          {\n";
-    t << "            imageNode.src = \"ftv2pnode.png\";\n";
+    t << "            imageNode.src = \"" FTV_ICON_FILE(pnode) "\";\n";
     t << "          }\n";
-    t << "          else if (imageNode.src.substring(l-17,l) == \"ftv2mlastnode.png\")\n";
+    t << "          else if (imageNode.src.substring(l-17,l) == \"" FTV_ICON_FILE(mlastnode) "\")\n";
     t << "          {\n";
-    t << "            imageNode.src = \"ftv2plastnode.png\";\n";
+    t << "            imageNode.src = \"" FTV_ICON_FILE(plastnode) "\";\n";
     t << "          }\n";
     t << "        }\n";
     t << "        folder.style.display = \"none\";\n";
@@ -723,14 +752,14 @@ void FTVHelp::generateTreeView()
     t << "        if (imageNode != null) \n";
     t << "        {\n";
     t << "          l = imageNode.src.length;\n";
-    t << "          imageNode.nextSibling.src = \"ftv2folderopen.png\";\n";
-    t << "          if (imageNode.src.substring(l-13,l) == \"ftv2pnode.png\")\n";
+    t << "          imageNode.nextSibling.src = \"" FTV_ICON_FILE(folderopen) "\";\n";
+    t << "          if (imageNode.src.substring(l-13,l) == \"" FTV_ICON_FILE(pnode) "\")\n";
     t << "          {\n";
-    t << "            imageNode.src = \"ftv2mnode.png\";\n";
+    t << "            imageNode.src = \"" FTV_ICON_FILE(mnode) "\";\n";
     t << "          }\n";
-    t << "          else if (imageNode.src.substring(l-17,l) == \"ftv2plastnode.png\")\n";
+    t << "          else if (imageNode.src.substring(l-17,l) == \"" FTV_ICON_FILE(plastnode) "\")\n";
     t << "          {\n";
-    t << "            imageNode.src = \"ftv2mlastnode.png\";\n";
+    t << "            imageNode.src = \"" FTV_ICON_FILE(mlastnode) "\";\n";
     t << "          }\n";
     t << "        }\n";
     t << "        folder.style.display = \"block\";\n";

[Doxygen-develop] another tiny patch for formula/HTML

[Vassilii K. <vas...@ta...>]

This one removes the space after an inline formula's <img> tag.
This allows to write things like
	\f$\mbox{\LaTeX}\f$'s
in your dox and not to have the apostrophy float away.

If somebody relied on the old behaviour, it's always possible to
ride on the inline formula img css property sheet to mandate a trailing
space there (although I doubt anyone would actually want that).

Index: htmldocvisitor.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/htmldocvisitor.cpp,v
retrieving revision 1.18
diff -u -p -r1.18 htmldocvisitor.cpp
--- htmldocvisitor.cpp	2003/04/30 19:40:09	1.18
+++ htmldocvisitor.cpp	2003/05/01 21:03:42
@@ -275,8 +275,6 @@ void HtmlDocVisitor::visit(DocFormula *f
   m_t << " src=\"" << f->name() << ".png\">";
   if (bDisplay)
     m_t << endl << "<p>" << endl;
-  else
-    m_t << " ";
 }

 void HtmlDocVisitor::visit(DocIndexEntry *)

[Doxygen-develop] Re: cvs build broken?

[Vassilii K. <vas...@ta...>]

You're absolutely right - I forgot to re-run configure.
Once I did that, everything builds and works all right.
Sorry about your time wasted.

OTOH, maybe the makefile should include a dependency on the
configure script, so that once the configure script gets updated,
it's re-run (so that this doesn't happen again to somebody else)?

v

Re: [Doxygen-develop] cvs build broken?

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

On Fri, May 02, 2003 at 05:04:35AM +0300, Vassilii Khachaturov wrote:
> I've just tried updating to the latest CVS snapshot (BTW,
> can you please crosspost the announcements about CVS updates
> to -develop in addition to -users?), and it doesn't build
> properly. Am I missing smth, or did you leave some of your
> local things uncommitted?

I think you are still using a previously generated makefile
(one that does not link in the new pagedef.o). Have you tried doing 
a ./configure followed by a make from the root of the distribution?

Regards,
  Dimitri

[Doxygen-develop] Brazilian Portuguese translator update.

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

Hi.

Here goes the Brazilian Portuguese translator update. Unfortunately I was unable
to test the new methods because I was unable to generate a java code that use
the new mesages. How can I see the new messages ?

See you.
FJTC
 

[Doxygen-develop] cvs build broken?

[Vassilii K. <vas...@ta...>]

I've just tried updating to the latest CVS snapshot (BTW,
can you please crosspost the announcements about CVS updates
to -develop in addition to -users?), and it doesn't build
properly. Am I missing smth, or did you leave some of your
local things uncommitted?

/usr/bin/gmake -C qtools
gmake[1]: Entering directory `/home/vassilii/doxygen/qtools'
/usr/bin/gmake -f Makefile.qtools    all
gmake[2]: Entering directory `/home/vassilii/doxygen/qtools'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/home/vassilii/doxygen/qtools'
gmake[1]: Leaving directory `/home/vassilii/doxygen/qtools'
/usr/bin/gmake -C libpng
gmake[1]: Entering directory `/home/vassilii/doxygen/libpng'
/usr/bin/gmake -f Makefile.libpng
gmake[2]: Entering directory `/home/vassilii/doxygen/libpng'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/home/vassilii/doxygen/libpng'
gmake[1]: Leaving directory `/home/vassilii/doxygen/libpng'
/usr/bin/gmake -C src
gmake[1]: Entering directory `/home/vassilii/doxygen/src'
/usr/bin/gmake -f Makefile.libdoxycfg PERL=/usr/bin/perl all
gmake[2]: Entering directory `/home/vassilii/doxygen/src'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/home/vassilii/doxygen/src'
/usr/bin/gmake -f Makefile.libdoxygen PERL=/usr/bin/perl all
gmake[2]: Entering directory `/home/vassilii/doxygen/src'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/home/vassilii/doxygen/src'
/usr/bin/gmake -f Makefile.doxygen    PERL=/usr/bin/perl all
gmake[2]: Entering directory `/home/vassilii/doxygen/src'
g++  -o ../bin/doxygen ../objects/main.o  -L../lib -ldoxygen -ldoxycfg -lqtools -lpng
../lib/libdoxygen.a(doxygen.o): In function `addListReferences(void)':
doxygen.o(.text+0xeb85): undefined reference to `PageDef::getGroupDef(void) const'
doxygen.o(.text+0xeb95): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(doxygen.o): In function `findSectionsInDocumentation(void)':
doxygen.o(.text+0x173c9): undefined reference to `PageDef::findSectionsInDocumentation(void)'
doxygen.o(.text+0x173fb): undefined reference to `PageDef::findSectionsInDocumentation(void)'
../lib/libdoxygen.a(doxygen.o): In function `findMainPage(Entry *)':
doxygen.o(.text+0x17ee8): undefined reference to `PageDef::PageDef(char const *, int, char const *, char const *, char const *)'
../lib/libdoxygen.a(doxygen.o): In function `resolveUserReferences(void)':
doxygen.o(.text+0x1844e): undefined reference to `PageDef::getGroupDef(void) const'
doxygen.o(.text+0x18464): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(doxygen.o): In function `generatePageDocs(void)':
doxygen.o(.text+0x1864e): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(doxygen.o): In function `buildExampleList(Entry *)':
doxygen.o(.text+0x18fcb): undefined reference to `PageDef::PageDef(char const *, int, char const *, char const *, char const *)'
../lib/libdoxygen.a(index.o): In function `countRelatedPages(int &, int &)':
index.o(.text+0xd351): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(index.o): In function `writePageIndex(OutputList &)':
index.o(.text+0xdabd): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(latexgen.o): In function `LatexGenerator::endIndexSection(IndexSections)':
latexgen.o(.text+0x31b5): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(rtfgen.o): In function `RTFGenerator::endIndexSection(IndexSections)':
rtfgen.o(.text+0x2fb1): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(util.o): In function `resolveLink(char const *, char const *, bool, Definition **, QCString &)':
util.o(.text+0xba01): undefined reference to `PageDef::getGroupDef(void) const'
../lib/libdoxygen.a(util.o): In function `addRelatedPage(char const *, QCString const &, QCString const &, QList<QCString> *, char const *, int, QList<ListItemInfo> const *, GroupDef *, TagInfo *)':
util.o(.text+0xf920): undefined reference to `PageDef::PageDef(char const *, int, char const *, char const *, char const *)'
util.o(.text+0xfc4e): undefined reference to `PageDef::getGroupDef(void) const'
util.o(.text+0xfc63): undefined reference to `PageDef::getGroupDef(void) const'
collect2: ld returned 1 exit status
gmake[2]: *** [../bin/doxygen] Error 1
gmake[2]: Leaving directory `/home/vassilii/doxygen/src'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/vassilii/doxygen/src'
make: *** [all] Error 2

[Doxygen-develop] Italian doxygen translator update

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

Here is the updated italian translator_it.h

Re: [Doxygen-develop] Correction of translator_fr.h

[<cy...@so...>]

Xavier Outhier wrote:

> BTW, maybe also the English translation should be method and not
> function. It's more common in java (and C++?) to use method instead
> of function.

It depends on the context. C++ litterature often calls the following foo:

	class Toto {
	   void foo();
	};

a member function.

Plain old C has no concept of method whatsoever, and IIRC doxygen does 
include provisions for C.

	-- Cyrille

[Doxygen-develop] Correction of translator_fr.h

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

Replaced Fontion with M=E9thode.

BTW, maybe also the English translation should be method and not
function. It's more common in java (and C++?) to use method instead
of function.

Cheers,

Xavier.
--
#-------------------------------------------------------#
| Artificial Anthill Project (*)                        |
|  http://aanthill.org                                  |
#-------------------------------------------------------#
| D2SET Science and Technology Association              |
|  http://d2set.free.fr                                 |
#-------------------------------------------------------#
| Group of exchange regarding imagery technics (French) |
|  http://fr.groups.yahoo.com/group/imagerie-tech/      |
#-------------------------------------------------------#
| Employement in imagery: offers and demands (French)   |
|  http://fr.groups.yahoo.com/group/imagerie-emploi/    |
#-------------------------------------------------------#

(*) We are seaking for webmasters, graphic designers,
 biologists, biochimists, translators.

[Doxygen-develop] Update of the French translator

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

What to say more?

Have a nice day,

Xavier.
--
#-------------------------------------------------------#
| Artificial Anthill Project (*)                        |
|  http://aanthill.org                                  |
#-------------------------------------------------------#
| D2SET Science and Technology Association              |
|  http://d2set.free.fr                                 |
#-------------------------------------------------------#
| Group of exchange regarding imagery technics (French) |
|  http://fr.groups.yahoo.com/group/imagerie-tech/      |
#-------------------------------------------------------#
| Employement in imagery: offers and demands (French)   |
|  http://fr.groups.yahoo.com/group/imagerie-emploi/    |
#-------------------------------------------------------#

(*) We are seaking for webmasters, graphic designers,
 biologists, biochimists, translators.

[Doxygen-develop] Note for language maintainers: 5 new methods should be implemented...

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

(sent to doxygen-develop, crossposted to doxygen-users)

Hi,=20

there are 5 new methods to be translated in the translator
classes.  They are related to Java, and they are as easy to
implement as to replace 5 short English title texts by the
equivalents in your language. =20

Do not forget to change the base class to the public Translator,=20
after implementing them.

Thanks for keeping your the translator class for your
language up-to-date.
  Petr

--=20
Petr Prikryl (pri...@sk...)=20

[Doxygen-develop] iso-latin2 vs. windows-cp1250 still needs some polishing ;-)

[JMisiurewicz <mj...@is...>]

Hi,

The problem I'd like to address is important to all people who suffer fro=
m
the duality (incompatibility) of ISO and Windows encoding, however I'd
analyze it from the Polish (_pl) point of view (i.e Latin2 vs cp1250),
which has common points with _cz _hr _hu _ro _si _sk _sr etc. problems. I=
f
we find a good solution, it may be applicable to other dualities (Japan,
KOI, ....)

I am seeking some advice, and if I collect enough I might try to prepare =
a
patch to get the things straight. The following "study" is based on
sources extracted from CVS today (it is probably a clean 1.3 version).


As we all know, the ISO and WIN encodings are not compatible -- at least
some of our national characters appear broken under other encoding.

The problem has been partially solved in the translator_xx.c files, by
applying some decode() operator to the national language texts. The
operator is applied or not, based on the boolean config-file variable
"USE_WINDOWS_ENCODING".

This solution guarantees correct documentation output in some most
popular, but not all, possible cases, namely:

1) Source: latin2, destination: HTML (latin2 encoded), LaTeX
2) Source: cp1250, destination: HTML (cp1250 encoded), RTF

I haven't analyzed other output formats, as I don't use them.

The problem with cp1250->LaTeX is in the translation of internal text
representation into encoding-independent form (e.g \.{z}, \k{a} \'{o}).
This translation (util.cpp, filterLatexString()) assumes the internal for=
m
is iso-latin2 if theTranslator defines iso-8859-2 as the
idlanguageCharset(), iso-latin1 otherwise. There are some exceptions: for
some languages (czech, russian, ukrainian) the conversion is blocked and
the national characters are left to be interpreted by LaTeX inputenc
package.

A quick way to obtain correct codes for Polish is to add Polish to the
exceptions - which I've done in my copy of sources. Anyway, this is a
quick and dirty hack (and it requires setting
latexLanguageSupportCommand() to include \usepackage[cp1250]{inputenc}
instead of [latin2] when the USE_WINDOWS_ENCODING is set).
Maybe we should think of a standard way to control fiterLatexString
behavior, instead of inserting more exceptions there?

The problem with Latin-2 -> rtf is in the LACK of translation - the RTF
supports ONLY cp1250, thus some translation is needed if the source is in
latin2.

Here, the quick hack would be a very dirty one: inserting a filter
into RTFGenerator::getMultiByte() AND forcing all the translator
texts through the filter (e.g using docify() on all references to
theTranslator strings).

Another way would be to do USE_WINDOWS_ENCODING
and pre-filter the sources from latin2 to cp1250 (using INPUT_FILTER).
There is, however, a problem that the inlined definitions of a function
body are not filtered (is it a bug or an intentional feature?).


I fee very uncomfortable with all this mess - the CLEAN solution
for these problems would be to use single internal encoding of all texts
inside doxygen and to provide input and ouput filters for all occasions,
integrated inside the program. The input filter would be modified by
config variable "INPUT_ENCODING", and the output filters would depend on
the format and sometimes on other config variables to choose output
encoding (rtf: always windows, html: two to choose, latex: latin2, cp1250=
,
independent \'{o} notation). But... this is a BIG revolution..... I'm not
sure I'd dare to do it.

I am hereby asking for an advice:
-do you see better quick hacks?
-do you see the need for the revolutionary cleaning?
-do you see a good way to clean the mess, at least a bit, without such a
revolution?
-do you think I should leave things as they are and get back to my primar=
y
work ;-) ?

Maybe the answer is to fix a bug with inline definition filtering (for
latin2->rtf using INPUT_FILTER), and clean the filterLatexString() a bit
(for cp1250->latex) ?

JM

--=20
Jacek Misiurewicz [jmi...@el...] [jmi...@ie...]
Politechnika Warszawska                    Warsaw University of Technolog=
y
Wydzia=B3 Elektroniki                        Electronics Engineering
Instytut Systemow Elektronicznych   ---    Inst. of Electronic Systems

[Doxygen-develop] Re: [PATCH] IMG ALT text for each formula, like in latex2html

[Vassilii K. <vas...@ta...>]

> Only list members can post to avoid spammers flooding the list.
OK, I've subscribed - looks like it's relatively low-volume.

> I'll include your patch in the next release.

Thanks. Meanwhile, I've got more improvements in the formula area that
I have tested here - the crude hack figuring what browser you'll be using
based on where the doxygen binary is compiled and producing the deprecated
IMG ALIGN attribute based on that is removed, along with the deprecated
CENTER netscapism. Works good with both IE5 and NS/Moz.

Instead, proper CSS styling has been introduced for display and inline
formulae.

Attached is this thing combined with my last change (hoping you haven't
started integrating my last one yet, as the cvs update doesn't indicate any news yet... 
If you did, go ahead and I will resolve the conflicts here and send you an 
incremental patch instead).

I'm also CC-ing this to the list for a test if the subscription worked.

Vassilii

[Doxygen-develop] Doxygen & Rational Rose

[<Oli...@al...>]

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi there,
<p>I'm starting using doxygen to generate documentation for my software.
The tricky point is that development is driven by UML methodology.
<br>From Rose tool (Rose 2002), UML model is entered and then C++ code
is partly generated:
<ul>
<li>
class declaration in header files</li>

<li>
skeletons for method bodies in .cc files</li>
</ul>
The point is that I would like documentation items to be entered while
I'm entering the model in Rose (for coherency reasons).&nbsp; An idea would
be to enter this information in the "Documentation" field for classes,
attributes, etc ... Then a Rose model parser would be able to retrieve
doc information from the model and generate C++ files (one file per class)
which would only contain Javadoc syntax.
<p>Doxygen would then parse C++ code generated from Rose and C++ code generated
from the parser. A bad point is that when Rose generates the headers, documentation
information is inserted within Rose tokens ... useless and this makes noise
inside the code !
<p>Does anybody here have experience such a thing ? Alternative solutions
?
<p>By the way, I read some times a go investigations where on going about
having class diagrams in UML look. This would be quite nice !!
<p>-- Olivier
<br>&nbsp;</html>

[Doxygen-develop] [PATCH] IMG ALT text for each formula, like in latex2html

[Vassilii K. <vas...@co...>]

(Please use vas...@ta... as my contact, rather
then the work email I'm submitting this from).
This is tested locally on a RH7.3 Linux system, with IE and Mozilla
as the WWW UAs.

Index: src/htmldocvisitor.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/htmldocvisitor.cpp,v
retrieving revision 1.16
diff -u -r1.16 htmldocvisitor.cpp
--- src/htmldocvisitor.cpp	2003/04/12 09:32:03	1.16
+++ src/htmldocvisitor.cpp	2003/04/16 14:44:57
@@ -272,6 +272,11 @@
   m_t << "\"middle\"";  // assume Windows users use IE or HtmlHelp which on
   // displays formulas nicely with align == "middle" 
 #endif
+  m_t << " alt=\"";
+  filterQuotedCdataAttr(f->text());
+  m_t << "\"";
+  /// @todo cache image dimensions on formula generation and give height/width
+  /// for faster preloading and better rendering of the page
   m_t << " src=\"" << f->name() << ".png\">";
   if (f->text().at(0)=='\\') 
     m_t << endl << "</center><p>" << endl;
@@ -916,6 +921,43 @@
       case '<':  m_t << "&lt;"; break;
       case '>':  m_t << "&gt;"; break;
       case '&':  m_t << "&amp;"; break;
+      default:   m_t << c;
+    }
+  }
+}
+
+/// Escape basic entities to produce a valid CDATA attribute value,
+/// assume that the outer quoting will be using the double quote &quot;
+void HtmlDocVisitor::filterQuotedCdataAttr(const char* str)
+{
+  if (str==0) return;
+  const char *p=str;
+  char c;
+  while (*p)
+  {
+    c=*p++;
+    switch(c)
+    {
+      case '&':  m_t << "&amp;"; break;
+      case '"':  m_t << "&quot;"; break;
+	// For SGML compliance, and given the SGML declaration for HTML syntax,
+	// it's enough to replace these two, provided that the declaration
+	// for the HTML version we generate (and as supported by the browser)
+	// specifies that all the other symbols used in rawVal are
+	// within the right charachter class (i.e., they're not
+	// some multinational weird charachters not in the BASESET).
+	// We assume that 1) the browser will support whatever is remaining
+	// in the formula and 2) the TeX formulae are generally governed
+	// by even stricter charachter restrictions so it should be enough.
+	//
+	// On some incompliant browsers, additional translation of
+	// '>' and '<' into "&gt;" and "&lt;", respectively, might be needed;
+	// but I'm unaware of particular modern (last 4 years) versions 
+	// with such problems, so let's not do it for performance.
+	// Also, some brousers will (wrongly) not process the entity references
+	// inside the attribute value and show the &...; form instead,
+	// so we won't create entites unless necessary to minimize clutter there.
+	// --vassilii
       default:   m_t << c;
     }
   }
Index: src/htmldocvisitor.h
===================================================================
RCS file: /u/kp3softd/cvsroot/src/htmldocvisitor.h,v
retrieving revision 1.8
diff -u -r1.8 htmldocvisitor.h
--- src/htmldocvisitor.h	2003/01/19 21:02:00	1.8
+++ src/htmldocvisitor.h	2003/04/16 14:44:57
@@ -133,6 +133,7 @@
     //--------------------------------------
     
     void filter(const char *str);
+    void filterQuotedCdataAttr(const char* str);
     void startLink(const QString &ref,const QString &file,
                    const QString &anchor);
     void endLink();

[Doxygen-develop] [Buglet] doxysearch outputs double "/"

[Ling Li <li...@ca...>]

a very small bug in the output of doxysearch. when giving the urls of
search.png and doxygen.png, it puts an extra "/" before the figure
names.

--Ling

[Doxygen-develop] RE:ada hope?

[Jeffrey C. <je...@th...>]

You might want to consider asking people at comp.lang.ada if they are =
interested in Ada support from=20
doxygen.

I am of course interested and based on some recent threads there, I =
think there are others who would be
as well.

Note that there are other similiar (although apparently less powerful) =
tools already available for
Ada so while I'd love to see doxygen support Ada, I would recommend you =
poke around
at www.adapower.com for a while to make sure there is not already some =
other tool that will do what
you need.

On the + side, if done well one could probably add Ada and VHDL support =
at the same time since
VHDL fairly close to Ada in terms of the high level syntax.

[Doxygen-develop] [Patch] Monolithic XML file output

[Douglas P. G. <gr...@cs...>]

Hello,
  The attached patch adds a new config option, MONOLITHIC_XML_FILE, to
Doxygen. When this option is set, it names an XML file that Doxygen will
generate containing all of the XML files. When this option is not set (the
default), the behavior is unchanged from before. Tested on i686 Linux
against today's CVS, and works like a charm to let me format my own C++
output with XSLT.

	Doug Gregor
	gr...@cs...

[Doxygen-develop] ada hope?

[Chris B. <chr...@wi...>]

Hi,
	I recently asked if anyone had been using, tried to use, wished
using doxygen with ada83/95 on doxygen-users@.  I am very interested in
getting ada95 support, though I'm aware it's not an overly popular language.
I am thinking of attempting to hack my own, but I was wondering how many
would be interested in such a feature, if any at all?  I see that the
doxygen todo/wishlist has the entry to support for other languages.  Where
would be the best to attack doxygen to add support for this? Has this been
discussed within the doxygen hacker circle? I am very interested and
relatively capable in c++ and qt.  Is there an irc channel or anywhere else
that an open discussion could take place to delegate tasks to
people/hackers?  I'm not sure about the structure of development for
doxygen, but I am very interested in contributing to this project and the
move to support more languages is where most of interest/emphasis lies.
Thanks in advance.

::chris

--
%  Chris Barlas                                             
%%  Software Engineer, Wintec Inc.                
%%%  Phone: (850).664.6203 ext. 203                        
%%%%  Email : mailto:chr...@wi...  
%%%%%  www  :  www.wintec-inc.com   

[Doxygen-develop] Bug in 1.3-rc3 using @ref for compounds inside a namespace

[James H. <jh...@ga...>]

Hello there,

I have found a bug in Doxygen v1.3-rc3 (introduced sometime since 1.2.18).

References generated using '@ref name' or '@ref name "text"' are not
generated correctly when 'name' is inside a namespace. Instead, a link
to the namespace is generated and '::name' is printed afterwards.

The following test program should illustrate the problem.

test_dox.cc:
----------
/// This is my namespace
namespace myNS
{
    /// This is my class
    class myClass
    {};
}

/**
@page myNotes My notes

Here is a ref @ref myNS::myClass
*/
----------

Unfortunately, I'm not familiar with the Doxygen source code so I'm
unable to submit a patch.

Regards,

James.

-- 
James Hobro
Project Geophysicist, Earth Models Development
WesternGeco, Schlumberger House, Gatwick Airport
Tel: +44 (0)1293 556119, Fax: +44 (0)1293 556800

Re: [Doxygen-develop] Doxygen use with Verilog Source Code

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

On Fri, Mar 21, 2003 at 09:15:12AM -0600, Christopher Lindahl wrote:
> Greetings, All,
> 
> I am interested in using Doxygen with Verilog source code.  I have
> searched through the mail archives and the Doxygen project site, but I
> have not seen anything like this.  Has Doxygen been extended to support
> Verilog at this point?  

Not that I'm aware of. I do not know Verilog so unless someone else 
adds support for this language, expect that it will remain unsupported.

Regards,
  Dimitri

[Doxygen-develop] Doxygen use with Verilog Source Code

[Christopher L. <li...@sg...>]

Greetings, All,

I am interested in using Doxygen with Verilog source code.  I have
searched through the mail archives and the Doxygen project site, but I
have not seen anything like this.  Has Doxygen been extended to support
Verilog at this point?  

Thanks for any information or direction that you can provide.

Thanks,
Chris Lindahl

Logic Design Engineer
Silicon Graphics, Inc.
Chippewa Falls, WI

[Doxygen-develop] Info on the status of the language translators (March 20, 2003)

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

Related to the doxygen 1.3-rc3-20030317 in CVS. Full
translator_report.txt
included in the attached zip file. Posted to doxygen-develop, copied to
doxygen-users. The previous report was from February 17, 2003.

Summary:=20
 - Three new up-to-date translators.
 - New option USE_WINDOWS_ENCODING is important for some languages.=20
 - The Hungarian and Norwegian maintainers are asked to try harder.
 - Polish and Danish maintainers are asked to polish ;) their code.
 - Finnish and Swedish are suggested to be removed from doxygen 1.3.


Hi,

Firstly, thanks to all active language maintainers. Three of the
translators
became up-to-date since the last info: Croatian, Korean, and Polish. For
Polish and Danish, please have a look at the details in the translator
report.

Thanks

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ATTENTION!=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If you are the language maintainer, this is a good time to update your
translator now because the 1.3 release looks to happen soon. Please,
think
about users who do not use sources from CVS, but only the precompiled
binaries. The 1.3 will be a bigger leap. I guess that more people would
like
to try it.

Thanks

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Dimitri included a new option USE_WINDOWS_ENCODING which makes selecting
output encoding dynamic. When the language defines different encoding
for MS
Windows and different for Unix, then the translator probably uses the
decode() or similar inline method to produce the desired output encoding
of
compiled-in strings. It ensures that strings from the translator_xx.h
source
will be converted to the desired encoding. The strings from the
processed
files are expected to use the same encoding that is suggested by the new
option.

Earlier, the decision was done in compile time: doxygen compiled under
Windows assumed that the processed files will be in Windows encoding;
doxygen compiled under Unix assumed theat the processed files will be in
Windows encoding. In other words, it was impossible to generate
correctly
encoded documentation from the processed files that were prepared using
the
other OS (in some languages).

If your language uses that approach, please check if the new option is
used
and if it used correctly in your translator_xx.h.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Current status
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The total is 28 languages: 13 of them are up-to-date, 11 of them is only
slightly behind -- max. 8 simple methods should be implemented to become
up-to-date. Two languages require more work: Hungarian and Norwegian. So
I
ask the maintainers to try a bit harder. The doxygen infrastructure
(i.e.
the translator adapter classes) could then be simplified. Look at the
translator_report.txt in the attached zip file.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Suggestion to remove Finnish and Swedish
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We still did not found new Finnish and Swedish maintainers. Their
translators became extremely obsolete, and it seems that the original
maintainers are not in touch with doxygen any more (read it
"unreachable").
 =20
The mentioned translators do not support so many methods, that it is
probably more correct to use the English translator instead. So I
suggest to
remove the the Finnish and Swedish languages support completely from
doxygen
version 1.3.

 =20
With regards,
  Petr

--=20
Petr Prikryl (pri...@sk...)

[Doxygen-develop] Re: Would it be difficult to alter doxygen to lookup a string file?

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

(Posted to doxygen-develop, copied to doxygen-users. Please, do discuss=20
the presented topic in doxygen-develop group, not in doxygen-users.)

Hi Chris and others,

"Chris Tutty" wrote...
> [...]Since the translation module now isolates these text strings
> has anyone though about moving them out to a text file to
> allow per-project modification of the fixed text?
=20
I have discussed the possibility to rewrite the translator
part of doxygen with Dimitri some months ago.  Unfortunately,
I do not have time to implement the proposal.  There is an unofficial
document called "Translators Revisited" (August 2001) written by=20
me, discussed with Dimitri. You can download it here:

  http://www.skil.cz/doxygen/TranslatorsRevisited.zip (about 25kB)

Unzip it to the aux directory and run doxygen to obtain the HTML
version.  It is rather long, but I hope the goals are realistic and=20
the described steps can be implemeted one by one, gradually.

However, Dimitri did some changes to the doxygen since then. =20
Therefore the "... Revisited" document should be revisited first. =20

  ----------------------------------------------------------------------
  Volunteers are welcome.  I am willing to discuss the details,
  but I am too busy now to implement anything. =20
  ----------------------------------------------------------------------

The main idea is to replace national translators (translator_xx.h)
by extenal text files or by strings compiled into doxygen.exe -- what is
preferable.  When fully implemented, it should not be a big problem
to introduce something like your per-project modification files.

> From a quick look the overhead would be the work required
> to identify, find and load the external file, along with changes
> to the translate modules to look for the loaded strings rather
> than using the embedded ones.  I'd assume that we just define
> the external file as a series of lines in TAG=3Dtext format, load
> them into a list and prefix each return "blah" in the translator
> module with 'if tag found return tagvalue else return "blah"'.
>
> This seems like a fairly simple set of changes for the significant
> benefit of making the fixed text user-modifiable rather than
> embedded in the executable.

This is not always that simple. Some strings are constructed based on=20
the passed arguments.  This is not always straightforward.  Simple=20
string templates cannot be used.  Some languages require different
ordering of the generated parts and even changing the wording based
on value of arguments.

Read it, think about it, discuss, implement ;-)

Petr

--=20
Petr Prikryl (pri...@sk...)

[Doxygen-develop] test -- please ignore

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

... it's realy nothing important here ;-)

--=20
Petr Prikryl (pri...@sk...)=20