Release-1.2.8-20010715

11 files changed, 477 insertions, 92 deletions

diff --git a/doc/config.doc b/doc/config.doc
index 8a4a2f3..bf5bac2 100644
--- a/doc/config.doc
+++ b/doc/config.doc
@@ -18,13 +18,12 @@
 
 \subsection config_format Format
 
-A configuration file is a free-form ASCII text file with a structure that
-is similar to that of a Makefile. It is parsed by \c doxygen.
-The file may contain tabs and newlines for formatting purposes.
-The statements in the file are case-sensitive.
+A configuration file is a free-form ASCII text file with a structure
+that is similar to that of a Makefile, default name \c Doxyfile. It is
+parsed by \c doxygen.  The file may contain tabs and newlines for
+formatting purposes.  The statements in the file are case-sensitive.
 Comments may be placed anywhere within the file (except within quotes).
-Comments begin with the \# character and end at the end of the 
-line.
+Comments begin with the \# character and end at the end of the line.
 
 The file essentially consists of a list of assignment statements.
 Each statement consists of a \c TAG_NAME written in capitals,
@@ -905,9 +904,17 @@ EXTRA_PACKAGES = times
  If the \c PDF_HYPERLINKS tag is set to \c YES, the \f$\mbox{\LaTeX}\f$ that 
  is generated is prepared for conversion to PDF (using ps2pdf). 
  The PDF file will
- contain links (just like the HTML output) instead of page references
+ contain links (just like the HTML output) instead of page references.
  This makes the output suitable for online browsing using a PDF viewer.
 
+\anchor cfg_latex_pdflatex
+<dt>\c USE_PDFLATEX <dd>
+ \addindex LATEX_PDFLATEX
+
+ If the \c LATEX_PDFLATEX tag is set to \c YES, doxygen will use
+ pdflatex to generate the PDF file directly from the \f$\mbox{\LaTeX}\f$
+ files.
+
 \anchor cfg_latex_batchmode
 <dt>\c LATEX_BATCHMODE <dd>
  \addindex LATEX_BATCHMODE
@@ -1000,7 +1007,7 @@ EXTRA_PACKAGES = times
 
 \anchor cfg_man_links
 <dt>\c MAN_LINKS <dd> 
- \addindex MAN_LINKS
+ \addindex MAN_LINKs
  If the \c MAN_LINKS tag is set to \c YES and doxygen generates man output, 
  then it will generate one additional man file for each entity documented in 
  the real man page(s). These additional files only source the real man page, 
@@ -1054,7 +1061,7 @@ EXTRA_PACKAGES = times
  are defined before the preprocessor is started (similar to the -D option of
  gcc). The argument of the tag is a list of macros of the form:
  <code>name</code> or <code>name=definition</code> (no spaces). 
- If the definition and the = are omitted =1 is assumed.
+ If the definition and the "=" are omitted,  "=1" is assumed.
 
 \anchor cfg_expand_as_defined
 <dt>\c EXPAND_AS_DEFINED <dd>
@@ -1125,7 +1132,7 @@ TAGFILES = file1=loc1 "file2 = loc2" ... </pre>
  \addindex HAVE_DOT
  If you set the \c HAVE_DOT tag to \c YES then doxygen will assume the dot tool is
  available from the path. This tool is part of 
- <a href="http://www.research.att.com/sw/tools/graphviz/">Graphviz</a>, a graph 
+ <a href="http://www.graphviz.org/">Graphviz</a>, a graph 
  visualization toolkit from AT&T and Lucent Bell Labs. The other options in 
  this section have no effect if this option is set to \c NO (the default)
  
@@ -1198,6 +1205,12 @@ TAGFILES = file1=loc1 "file2 = loc2" ... </pre>
  generate a legend page explaining the meaning of the various boxes and
  arrows in the dot generated graphs.
 
+\anchor cfg_dot_cleanup
+<dt>\c DOT_CLEANUP <dd>
+ \addindex DOT_CLEANUP
+ This tag can be used to ?? cleanup any mess DOT left behind?
+ If left blank, "NO" is assumed.
+
 </dl>
 \subsection config_search Search engine options
 \anchor cfg_searchengine
@@ -1333,7 +1346,7 @@ INCLUDE_PATH         = $(QTDIR)/include
 RECURSIVE            = YES
 \endverbatim
 
-For the Qt-2.1 sources I recommand to use the following settings:
+For the Qt-2.1 sources I recommend to use the following settings:
 \verbatim
 PROJECT_NAME          = Qt
 PROJECT_NUMBER        = 2.1
diff --git a/doc/diagrams.doc b/doc/diagrams.doc
index a89b878..d283ed2 100644
--- a/doc/diagrams.doc
+++ b/doc/diagrams.doc
@@ -16,13 +16,13 @@
  */
 /*! \page diagrams Graphs and diagrams
 
-  Doxygen has build-in support to generate inheritance diagrams for C++
+  Doxygen has built-in support to generate inheritance diagrams for C++
   classes. 
 
   Doxygen can use the "dot" tool from graphviz 1.5 to generate
   more advanced diagrams & graphs. Graphviz is an open-sourced, 
   cross-platform graph drawing toolkit from AT&T and Lucent Bell Labs and
-  can be found at http://www.research.att.com/sw/tools/graphviz/
+  can be found at http://www.graphviz.org/
 
   If you have the "dot" tool available in the path, you can set
   \ref cfg_have_dot "HAVE_DOT" to \c YES in the configuration file to 
@@ -39,7 +39,7 @@
   <li>if \ref cfg_class_graph "CLASS_GRAPH" is set to \c YES,
       a graph will be generated for each documented class showing the 
       direct and indirect inheritance relations. This disables the
-      generation of the build-in class inheritance diagrams.
+      generation of the built-in class inheritance diagrams.
   <li>if \ref cfg_include_graph "INCLUDE_GRAPH" is set to \c YES, an include 
       dependency graph is generated for each documented file that includes at 
       least one other file. This feature is currently supported for HTML and RTF 
diff --git a/doc/faq.doc b/doc/faq.doc
index f20dfc0..4fb9a63 100644
--- a/doc/faq.doc
+++ b/doc/faq.doc
@@ -197,6 +197,22 @@ converted it into an empty file (with >16K of newlines). Another case
 where this might happen is if you have lines in your code with more than
 16K characters.
 
+<li><b>How did doxygen get it's name?</b>
+
+Doxygen got its name from playing with the words 
+documentation and generator.
+
+\verbatim
+documentation -> docs -> dox
+generator -> gen
+\endverbatim
+
+At the time I was looking into lex and yacc, where a lot of things start with
+"yy", so the "y" slipped in and made things pronouncable.
+
+I realized later that doxygen could also be read as Dimitri's oxygen,
+which could be seen as something I need to live :-)
+
 </ol>
 
 \htmlonly
diff --git a/doc/install.doc b/doc/install.doc
index 2d0de5f..557df69 100644
--- a/doc/install.doc
+++ b/doc/install.doc
@@ -18,8 +18,8 @@
 
 \addindex installation
 First go to the 
-<a href="http://www.stack.nl/~dimitri/doxygen/download.html">download</a> page
-\latexonly({\tt http://www.stack.nl/$\sim$dimitri/doxygen/download.html})\endlatexonly
+<a href="http://www.doxygen.org/download.html">download</a> page
+\latexonly({\tt http://www.doxygen.org/download.html})\endlatexonly
 to get the latest distribution, if you did not have it already.
 
 This section is divided into the following subsections:
@@ -37,14 +37,14 @@ This section is divided into the following subsections:
 If you downloaded the source distribution, you need at least the 
 following to build the executable:
 <ul>
-<li>The <a href="ftp://prep.ai.mit.edu/pub/gnu">GNU</a> tools 
+<li>The <a href="ftp://prep.ai.mit.edu/pub/gnu/">GNU</a> tools 
     flex, bison and make
     \addindex flex
     \addindex bison
     \addindex make
 <li>In order to generate a Makefile for your platform, you need 
-    <a href="http://www.perl.com>perl</a>
-    \latexonly(see {\tt http://www.perl.com})\endlatexonly.
+    <a href="http://www.perl.com/>perl</a>
+    \latexonly(see {\tt http://www.perl.com/})\endlatexonly.
     \addindex perl
 </ul>
 
@@ -58,10 +58,12 @@ tools should be installed.
     \addindex Qt
     This is needed to build the GUI front-end. 
 <li>A \f$\mbox{\LaTeX}\f$ distribution: for instance
-    <a href="http://www.tug.org">teTeX 1.0</a>.<br>
+    <a href="http://www.tug.org/">teTeX 1.0</a>.<br>
+    \latexonly(see {\tt http://www.tug.org/})\endlatexonly.
     This is needed for generating LaTeX, Postscript, and PDF output.
-<li><a href="http://www.research.att.com/sw/tools/graphviz/">
+<li><a href="http://www.graphviz.org/">
     the Graph visualization toolkit version 1.5</a><br>
+    \latexonly(see {\tt http://www.graphviz.org/})\endlatexonly.
     Needed for the include dependency graphs, 
     the graphical inheritance graphs, and the collaboration graphs.
 <li>The ghostscript interpreter.
@@ -231,7 +233,7 @@ If you are compiling for HP-UX with aCC and you get this error:
 \endverbatim
 
   If that does not help, try removing <code>ce_parse.cpp</code> and let 
-  bison rebuilt it (this worked for me).
+  bison rebuild it (this worked for me).
 
 If you are compiling for Digital Unix, the same problem can be solved
 (according to Barnard Schmallhof) by replacing the following in 
@@ -239,7 +241,8 @@ ce_parse.cpp:
    
 \verbatim
     #else /* not GNU C.  */
-    #if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || defined (__sparc) || defined (__sgi)
+    #if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) \
+        || defined (__sparc) || defined (__sgi)
     #include <alloca.h>
 \endverbatim
 
@@ -247,7 +250,8 @@ ce_parse.cpp:
 
 \verbatim
     #else /* not GNU C.  */
-    #if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || defined (__sparc) || defined (__sgi) || defined (__osf__)
+    #if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) \
+        || defined (__sparc) || defined (__sgi) || defined (__osf__)
     #include <alloca.h>
 \endverbatim
 
@@ -261,8 +265,10 @@ ce_parse.cpp:
  #ifdef __GNUC__
  #define alloca __builtin_alloca
  #else /* not GNU C.  */
--#if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || defined (__sparc) || defined (__sgi)
-+#if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || defined (__sparc) || defined (__sgi) || defined (__alpha)
+-#if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) \
+     || defined (__sparc) || defined (__sgi)
++#if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) \
+     || defined (__sparc) || defined (__sgi) || defined (__alpha)
  #include <alloca.h>
  #else /* not sparc */
  #if defined (MSDOS) && !defined (__TURBOC__)
@@ -283,8 +289,10 @@ Compiling the \c doxygen binary went ok, but while linking <code>doxytag</code>
 lot of link errors, like these:
 
 \verbatim
-QList<PageInfo>::__vtbl   /home/dimitri/doxygen/objects/SunWS_cache/CC_obj_6/6c3eO4IogMT2vrlGCQUQ.o
-[Hint: try checking whether the first non-inlined, non-pure virtual function of class QList<PageInfo> is defined]
+QList<PageInfo>::__vtbl   /home/dimitri/doxygen/
+objects/SunWS_cache/CC_obj_6/6c3eO4IogMT2vrlGCQUQ.o
+[Hint: try checking whether the first non-inlined, non-pure 
+virtual function of class QList<PageInfo> is defined]
 \endverbatim
 
 These are generated because the compiler is confused about the object sharing
@@ -326,6 +334,11 @@ the compiler will fail to compile some of the translator_xx.h files.
 A workaround, if you are planning to use the English translation only, 
 is to configure doxygen with the <code>--english-only</code> option.  
 
+On some platforms (such as OpenBSD) using some versions of gcc with
+-O2 can lead to eating all memory during the compilation of files 
+such as config.cpp. As a workaround use --debug as a configure option 
+or omit the -O2 for the particular files in the Makefile.
+
 \subsection install_src_windows Compiling from source on Windows
 
 Currently, I have only compiled doxygen for Windows using Microsoft's 
@@ -353,7 +366,7 @@ Here is what is required:
     variables (if you did not select to do this automatically during 
     installation). 
 
-    Borland C++ or MINGW (see http://www.mingw.org) are also supported. 
+    Borland C++ or MINGW (see http://www.mingw.org/) are also supported. 
 
 <li>Perl 5.0 or higher for Windows. This can be downloaded from:
     http://www.ActiveState.com/Products/ActivePerl/
@@ -439,7 +452,7 @@ Here is what is required:
     <code>objects</code> and <code>bin</code> manually in the root of the 
     distribution before compiling.
 
-<li><a href="http://www.research.att.com/sw/tools/graphviz/">
+<li><a href="http://www.graphviz.org/">
     the Graph visualization toolkit version 1.5</a><br>
     Needed for the include dependency graphs, the graphical inheritance graphs,
     and the collaboration graphs.
diff --git a/doc/language.doc b/doc/language.doc
index 2ddb450..d97ed69 100644
--- a/doc/language.doc
+++ b/doc/language.doc
@@ -21,9 +21,9 @@
 
 <h3>Support for multiple languages</h3>
 
-Doxygen has support for multiple languages. This means 
-that the text fragments that doxygen generates can changed into languages 
-other than English (the default) at configuration time.
+Doxygen has built-in support for multiple languages. This means 
+that the text fragments that doxygen generates can be produced in
+languages other than English (the default) at configuration time.
 <p>
 Currently (version unknown), 23 languages 
 are supported (sorted alphabetically): 
@@ -34,7 +34,7 @@ Polish, Portuguese, Romanian, Russian, Slovak,
 Slovene, Spanish, and Swedish.
 
 The table of information related to the supported languages follows.
-It is sorted by language alphabetically.  The <B>Status</B> column
+It is sorted by language alphabetically.  The <b>Status</b> column
 was generated from sources and shows approximately the last version
 when the translator was updated.
 <p>
@@ -103,7 +103,7 @@ when the translator was updated.
       <TD>French</TD>  
       <TD>Xavier Outhier</TD>
       <TD>xavier.outhier@NOSPAM.anfdata.cz</TD>
-      <TD>1.2.0</TD>
+      <TD>up-to-date</TD>
   </TR>
   <TR BGCOLOR="#ffffff">
       <TD>German</TD>  
@@ -167,7 +167,7 @@ when the translator was updated.
   </TR>
   <TR BGCOLOR="#ffffff">
       <TD>Slovak</TD>  
-      <TD>Stanislav Kudlac</TD>
+      <TD>Stanislav Kudl&aacute;&#x010d;</TD>
       <TD>qwerty1@NOSPAM.pobox.sk</TD>
       <TD>1.2.7</TD>
   </TR>
@@ -217,7 +217,7 @@ when the translator was updated.
   \hline
   Finnish & Olli Korhonen & {\tt Olli.Korhonen@ccc.fi} & 1.0.0 \\
   \hline
-  French & Xavier Outhier & {\tt xavier.outhier@anfdata.cz} & 1.2.0 \\
+  French & Xavier Outhier & {\tt xavier.outhier@anfdata.cz} & up-to-date \\
   \hline
   German & Jens Seidel & {\tt jensseidel@users.sourceforge.net} & up-to-date \\
    & Jens Breitenstein & {\tt Jens.Breitenstein@tlc.de} &  \\
@@ -241,7 +241,7 @@ when the translator was updated.
   \hline
   Russian & Alexandr Chelpanov & {\tt cav@cryptopro.ru} & up-to-date \\
   \hline
-  Slovak & Stanislav Kudlac & {\tt qwerty1@pobox.sk} & 1.2.7 \\
+  Slovak & Stanislav Kudl\'{a}\v{c} & {\tt qwerty1@pobox.sk} & 1.2.7 \\
   \hline
   Slovene & Matjaz Ostroversnik & {\tt matjaz.ostroversnik@zrs-tk.si} & 1.1.5 \\
   \hline
@@ -274,7 +274,7 @@ Just follow these steps:
     is already working on support for that language, you will be 
     assigned as the maintainer for the language. 
 <li>Create a copy of translator_en.h and name it 
-    translator_<your_2_letter_counter_code>.h
+    translator_<your_2_letter_country_code>.h
     I'll use xx in the rest of this document.
 <li>Edit language.cpp:
     Add a 
@@ -298,7 +298,8 @@ Just follow these steps:
    <li>In the member <code>idLanguage()</code> change "english" into the 
      name of the your language (use lower case characters only). Depending
      on the language you may also wish to change the member functions 
-     latexLanguageSupportCommand() and idLanguageCharset().
+     latexLanguageSupportCommand(), idLanguageCharset() and others
+     (you will recognize them when you start the work).
    <li>Edit all the strings that are returned by the member functions that 
      start with tr. 
      Try to match punctuation and capitals!
@@ -306,7 +307,7 @@ Just follow these steps:
      <ul>
      <li>  Enter them directly if your keyboard supports that and you are 
            using a Latin-1 font.
-           Doxygen will translate the characters to proper Latex and
+           Doxygen will translate the characters to proper LateX and
            leave the Html and man output for what it is (which is fine, if
            idLanguageCharset() is set correctly).
      <li>  Use html codes like \&auml; for an a with an umlaut (i.e. &auml;).
@@ -318,34 +319,202 @@ Just follow these steps:
 <li>Now you can use <code>OUTPUT_LANGUAGE = your_language_name</code> 
     in the config file to generate output in your language.
 <li>Send <code>translator_xx.h</code> to me so I can add it to doxygen.
+    Send also your name and e-mail address to be included in the
+    \c maintainers.txt list.
 </ol>
 
+
 <h3>Maintaining a language</h3>
 
-As new versions of doxygen appear, new sentences will be
-added to the Translator interface class. Of course these need to be translated
-as well (otherwise doxygen wouldn't even compile!). 
+As new versions of doxygen appear, new sentences (\c trXxxx()
+methods) will be added to the \c Translator interface class.  Of
+course, these need to be translated as well (otherwise doxygen
+wouldn't even compile!).  Waiting until all language maintainers
+have translated the new sentences and sent the results would not
+be very practical. The following text describes the usage of
+translator adapters to solve the problem.
+
+<b>The role of Translator Adapters.</b> 
+Whenever the \c Translator class interface changes in the new
+release, the new class \c TranslatorAdapter_x_y_z is added to the \c
+translator_adapter.h file (here x, y, and z are numbers that
+correspond to the current version of doxygen). All translators that
+previously derived from the \c Translator class now derive from this
+adapter class.
+
+The \c TranslatorAdapter_x_y_z class implements the new, required
+methods.  If the new method replaces some similar but obsolete
+method(s) (e.g. if the number of arguments changed and/or the
+functionality of the older method was changed or enriched), the \c
+TranslatorAdapter_x_y_z class may use the obsolete method to get the
+result which is as close as possible to the older result in the
+target language.  If it is not possible, the result (the default
+translation) is obtained using the English translator, which is (by
+definition) always up to date.  
+
+<b>For example,</b> when the new \c trFile() method with
+parameters (to determine the capitalization of the first letter and
+the singular/plural form) was introduced to replace the older method
+\c trFiles() without arguments, the following code appeared in one
+of the translator adapter classes:
+
+\verbatim
+    /*! This is the default implementation of the obsolete method
+     * used in the documentation of a group before the list of
+     * links to documented files.  This is possibly localized.
+     */
+    virtual QCString trFiles()
+    { return "Files"; }
+
+    /*! This is the localized implementation of newer equivalent
+     * using the obsolete method trFiles().
+     */
+    virtual QCString trFile(bool first_capital, bool singular)
+    {
+      if (first_capital && !singular)
+        return trFiles();  // possibly localized, obsolete method
+      else
+        return english.trFile(first_capital, singular);
+    }
+\endverbatim
+
+The \c trFiles() is not present in the \c TranslatorEnglish class,
+because it was removed as obsolete.  However, it was used until now
+and its call was replaced by 
+
+\verbatim
+    trFile(true, false)
+\endverbatim
+
+in the doxygen source files.  Probably, many language translators
+implemented the obsolete method, so it perfectly makes sense to use
+the same language dependent result in those cases. The \c
+TranslatorEnglish does not implement the old method.  It derives
+from the abstract \c Translator class.  On the other hand, the old
+translator for a different language does not implement the new \c
+trFile() method.  Because of that it is derived from another base
+class -- \c TranslatorAdapter_x_y_z. The \c TranslatorAdapter_x_y_z
+class have to implement the new, required \c trFile() method.
+However, the translator adapter would not be compiled if the \c
+trFiles() method was not implemented. This is the reason for
+implementing the old method in the translator adapter class (using
+the same code, that was removed from the TranslatorEnglish).
+
+The simplest way would be to pass the arguments to the English
+translator and to return its result.  Instead, the adapter uses the
+old \c trFiles() in one special case -- when the new
+<code>trFile(true,&nbsp;false)</code> is called.  This is the
+mostly used case at the time of introducing the new method -- see
+above.  While this may look too complicated, the technique allows
+the developers of the core sources to change the Translator
+interface, while the users may not even notice the change.  Of
+course, when the new \c trFile() is used with different arguments,
+the English result is returned and it will be noticed by non English
+users.  Here the maintainer of the language translator should
+implement at least that one particular method.
+
+<b>What says the base class of a language translator?</b>
+If the language translator class inherits from any adapter class the
+maintenance is needed.  In such case, the language translator is not
+considered up-to-date.  On the other hand, if the language
+translator derives directly from the abstract class \c Translator, the
+language translator is up-to-date.
+
+The translator adapter classes are chained so that the older
+translator adapter class uses the one-step-newer translator adapter
+as the base class.  The newer adapter does less \e adapting work
+than the older one.  The oldest adapter class derives (indirectly)
+from all of the adapter classes.  The newest adapter class derives
+directly from the abstract class \c Translator.  
+
+The name of the adapter class was chosen so that its suffix is
+derived from the previous version of doxygen.  This way, one can say
+approximately, when the language translator class was last updated
+-- see details below.  The newest adapter translator for CVS release
+(i.e. non official) is named \c TranslatorAdapterCVS.  As it derives
+only from the \c Translator class, it can be used only for language
+translator classes that were up-to-date in the time of the last
+release.
+
+Status of the translators that derive from the \c
+TranslatorAdapterCVS is named as <em>almost up-to-date</em>.
+Its code is moved into the new \c Translator_x_y_z when new version
+of doxygen is officially released.
+
+Once the oldest adapter class is not used by any of the language
+translators, it can be removed from the doxygen project.  This also
+means, that there probably still is some language which uses the
+oldest adapter.  The maintainers should try to reach the state with
+the minimal number of translator adapter classes.
+
+
+<b>To simplify the maintenance of the language translator classes</b>
+for the supported languages, the \c translator.pl perl
+script was developed (located in \c doxygen/doc directory). 
+It is able to extract the important information about obsolete and
+new methods from the source files for each of the languages -- see
+the reference to the <em>translator report</em> ASCII file below 
+the table of supported languages shown earlier. Looking at the base
+class of the language translator, the script guesses also the status
+of the translator -- see the last column of the mentioned table.  
+The \c translator.pl is called automatically when the doxygen
+documentation is generated.  You can also run the script manualy
+whenever you feel that it can help you.  Of course, you are not
+forced to use the results of the script.  You can find the same
+information by looking at the adapter class and its base classes.
+
+<b>How should I update my language translator?</b> Firstly, you
+should be the language maintainer, or you should let him/her know
+about the changes.  The following text was written for the language
+maintainers as the primary audience.
+
+There are several approaches to be taken when updating your
+language.  If you are not extremely busy, you should always chose
+the most radical one.  When the update takes much more time than you
+expected, you can always decide use some suitable translator adapter to
+finish the changes later and still make your translator working.
+
+<b>The most radical way of updating the language translator</b> is
+to make your translator class derive directly 
+from the abstract class \c Translator and provide translations for the
+methods that are required to be implemented -- the compiler will
+tell you if you forgot to implement some of them.  If you are in
+doubt, have a look at the \c TranslatorEnglish class to recognize the
+purpose of the implemented method.  Looking at the previously used
+adapter class may help you sometimes, but it can also be misleading
+because the adapter classes do implement also the obsolete methods
+(see the previous \c trFiles() example).
 
-Waiting until all language maintainers have translated these new sentences
-and sent the results would not be very practical for me.
+In other words, the up-to-date language translators do not need the
+\c TranslatorAdapter_x_y_z classes at all, and you do not need to
+implement anything else than the methods required by the Translator
+class (i.e. the pure virtual methods of the \c Translator -- they 
+end with <code>=0;</code>).
 
-Instead, a new class TranslatorAdapter_x_y_z will be added to 
-translator_adapter.h (here x,y, and z correspond to the current
-version of doxygen). And all translators that previous derived from 
-Translator will now derive from this adapter class.
+If everything compiles fine, try to run \c translator.pl, and have a
+look at the translator report (ASCII file) at the \c doxygen/doc
+directory.  Even if your translator is marked as up-to-date, there
+still may be some remarks related to your souce code.  Namely, the
+obsolete methods--that are not used at all--may be listed in the
+section for your language.  Simply, remove their code (and run the
+\c translator.pl again).
 
-The Adapter class contains the new sentences with
-default translations using the English translator (which is always up to date). 
-Instead of deriving your TranslatorXX class directly from Translator it will 
-derive from the intermediate class TranslatorAdapter_x_y_z. 
+<b>If you do not have time to finish all the updates</b> you should
+still start with <em>the most radical approach</em> as described
+above.  You can always change the base class to the translator
+adapter class that implements all of the not-yet-implemented methods.
 
-Thus, if a translator class inherits from a adapter class 
-maintenance is needed. By looking at the adapter class itself (and its base
-classes) you can easily see which methods need to be updated.
+<b>If you prefer to update your translator gradually</b>, look
+at the <em>translator report</em> generated by the \c translator.pl script
+and choose one of the missing method that is implemented by the
+translator adapter, that is used as your base class. When there is
+not such a method in your translator adapter base class, you probably
+can change the translator adapter base to the newer one.
 
-To update a language simply make your translator class derive from
-the abstract class Translator and provide translations for the methods that
-were previously provided by the adapter class (and its base classes).
+Do not blindly implement all methods that are implemented by your
+translator adapter base class.  The reason is that the adapter
+classes implement also obsolete methods.  Another reason is that
+some of the methods could become obsolete later.
 
 */
 
diff --git a/doc/language.tpl b/doc/language.tpl
index 18c0b40..d81c213 100644
--- a/doc/language.tpl
+++ b/doc/language.tpl
@@ -19,16 +19,16 @@
 
 <h3>Support for multiple languages</h3>
 
-Doxygen has support for multiple languages. This means 
-that the text fragments that doxygen generates can changed into languages 
-other than English (the default) at configuration time.
+Doxygen has built-in support for multiple languages. This means 
+that the text fragments that doxygen generates can be produced in
+languages other than English (the default) at configuration time.
 <p>
 Currently (version $version), $numlang languages 
 are supported (sorted alphabetically): 
 $languages.
 
 The table of information related to the supported languages follows.
-It is sorted by language alphabetically.  The <B>Status</B> column
+It is sorted by language alphabetically.  The <b>Status</b> column
 was generated from sources and shows approximately the last version
 when the translator was updated.
 <p>
@@ -53,7 +53,7 @@ Just follow these steps:
     is already working on support for that language, you will be 
     assigned as the maintainer for the language. 
 <li>Create a copy of translator_en.h and name it 
-    translator_<your_2_letter_counter_code>.h
+    translator_<your_2_letter_country_code>.h
     I'll use xx in the rest of this document.
 <li>Edit language.cpp:
     Add a 
@@ -77,7 +77,8 @@ Just follow these steps:
    <li>In the member <code>idLanguage()</code> change "english" into the 
      name of the your language (use lower case characters only). Depending
      on the language you may also wish to change the member functions 
-     latexLanguageSupportCommand() and idLanguageCharset().
+     latexLanguageSupportCommand(), idLanguageCharset() and others
+     (you will recognize them when you start the work).
    <li>Edit all the strings that are returned by the member functions that 
      start with tr. 
      Try to match punctuation and capitals!
@@ -85,7 +86,7 @@ Just follow these steps:
      <ul>
      <li>  Enter them directly if your keyboard supports that and you are 
            using a Latin-1 font.
-           Doxygen will translate the characters to proper Latex and
+           Doxygen will translate the characters to proper LateX and
            leave the Html and man output for what it is (which is fine, if
            idLanguageCharset() is set correctly).
      <li>  Use html codes like \&auml; for an a with an umlaut (i.e. &auml;).
@@ -97,34 +98,202 @@ Just follow these steps:
 <li>Now you can use <code>OUTPUT_LANGUAGE = your_language_name</code> 
     in the config file to generate output in your language.
 <li>Send <code>translator_xx.h</code> to me so I can add it to doxygen.
+    Send also your name and e-mail address to be included in the
+    \c maintainers.txt list.
 </ol>
 
+
 <h3>Maintaining a language</h3>
 
-As new versions of doxygen appear, new sentences will be
-added to the Translator interface class. Of course these need to be translated
-as well (otherwise doxygen wouldn't even compile!). 
+As new versions of doxygen appear, new sentences (\c trXxxx()
+methods) will be added to the \c Translator interface class.  Of
+course, these need to be translated as well (otherwise doxygen
+wouldn't even compile!).  Waiting until all language maintainers
+have translated the new sentences and sent the results would not
+be very practical. The following text describes the usage of
+translator adapters to solve the problem.
+
+<b>The role of Translator Adapters.</b> 
+Whenever the \c Translator class interface changes in the new
+release, the new class \c TranslatorAdapter_x_y_z is added to the \c
+translator_adapter.h file (here x, y, and z are numbers that
+correspond to the current version of doxygen). All translators that
+previously derived from the \c Translator class now derive from this
+adapter class.
+
+The \c TranslatorAdapter_x_y_z class implements the new, required
+methods.  If the new method replaces some similar but obsolete
+method(s) (e.g. if the number of arguments changed and/or the
+functionality of the older method was changed or enriched), the \c
+TranslatorAdapter_x_y_z class may use the obsolete method to get the
+result which is as close as possible to the older result in the
+target language.  If it is not possible, the result (the default
+translation) is obtained using the English translator, which is (by
+definition) always up to date.  
+
+<b>For example,</b> when the new \c trFile() method with
+parameters (to determine the capitalization of the first letter and
+the singular/plural form) was introduced to replace the older method
+\c trFiles() without arguments, the following code appeared in one
+of the translator adapter classes:
+
+\verbatim
+    /*! This is the default implementation of the obsolete method
+     * used in the documentation of a group before the list of
+     * links to documented files.  This is possibly localized.
+     */
+    virtual QCString trFiles()
+    { return "Files"; }
+
+    /*! This is the localized implementation of newer equivalent
+     * using the obsolete method trFiles().
+     */
+    virtual QCString trFile(bool first_capital, bool singular)
+    {
+      if (first_capital && !singular)
+        return trFiles();  // possibly localized, obsolete method
+      else
+        return english.trFile(first_capital, singular);
+    }
+\endverbatim
+
+The \c trFiles() is not present in the \c TranslatorEnglish class,
+because it was removed as obsolete.  However, it was used until now
+and its call was replaced by 
+
+\verbatim
+    trFile(true, false)
+\endverbatim
+
+in the doxygen source files.  Probably, many language translators
+implemented the obsolete method, so it perfectly makes sense to use
+the same language dependent result in those cases. The \c
+TranslatorEnglish does not implement the old method.  It derives
+from the abstract \c Translator class.  On the other hand, the old
+translator for a different language does not implement the new \c
+trFile() method.  Because of that it is derived from another base
+class -- \c TranslatorAdapter_x_y_z. The \c TranslatorAdapter_x_y_z
+class have to implement the new, required \c trFile() method.
+However, the translator adapter would not be compiled if the \c
+trFiles() method was not implemented. This is the reason for
+implementing the old method in the translator adapter class (using
+the same code, that was removed from the TranslatorEnglish).
+
+The simplest way would be to pass the arguments to the English
+translator and to return its result.  Instead, the adapter uses the
+old \c trFiles() in one special case -- when the new
+<code>trFile(true,&nbsp;false)</code> is called.  This is the
+mostly used case at the time of introducing the new method -- see
+above.  While this may look too complicated, the technique allows
+the developers of the core sources to change the Translator
+interface, while the users may not even notice the change.  Of
+course, when the new \c trFile() is used with different arguments,
+the English result is returned and it will be noticed by non English
+users.  Here the maintainer of the language translator should
+implement at least that one particular method.
+
+<b>What says the base class of a language translator?</b>
+If the language translator class inherits from any adapter class the
+maintenance is needed.  In such case, the language translator is not
+considered up-to-date.  On the other hand, if the language
+translator derives directly from the abstract class \c Translator, the
+language translator is up-to-date.
+
+The translator adapter classes are chained so that the older
+translator adapter class uses the one-step-newer translator adapter
+as the base class.  The newer adapter does less \e adapting work
+than the older one.  The oldest adapter class derives (indirectly)
+from all of the adapter classes.  The newest adapter class derives
+directly from the abstract class \c Translator.  
+
+The name of the adapter class was chosen so that its suffix is
+derived from the previous version of doxygen.  This way, one can say
+approximately, when the language translator class was last updated
+-- see details below.  The newest adapter translator for CVS release
+(i.e. non official) is named \c TranslatorAdapterCVS.  As it derives
+only from the \c Translator class, it can be used only for language
+translator classes that were up-to-date in the time of the last
+release.
+
+Status of the translators that derive from the \c
+TranslatorAdapterCVS is named as <em>almost up-to-date</em>.
+Its code is moved into the new \c Translator_x_y_z when new version
+of doxygen is officially released.
+
+Once the oldest adapter class is not used by any of the language
+translators, it can be removed from the doxygen project.  This also
+means, that there probably still is some language which uses the
+oldest adapter.  The maintainers should try to reach the state with
+the minimal number of translator adapter classes.
+
+
+<b>To simplify the maintenance of the language translator classes</b>
+for the supported languages, the \c translator.pl perl
+script was developed (located in \c doxygen/doc directory). 
+It is able to extract the important information about obsolete and
+new methods from the source files for each of the languages -- see
+the reference to the <em>translator report</em> ASCII file below 
+the table of supported languages shown earlier. Looking at the base
+class of the language translator, the script guesses also the status
+of the translator -- see the last column of the mentioned table.  
+The \c translator.pl is called automatically when the doxygen
+documentation is generated.  You can also run the script manualy
+whenever you feel that it can help you.  Of course, you are not
+forced to use the results of the script.  You can find the same
+information by looking at the adapter class and its base classes.
+
+<b>How should I update my language translator?</b> Firstly, you
+should be the language maintainer, or you should let him/her know
+about the changes.  The following text was written for the language
+maintainers as the primary audience.
+
+There are several approaches to be taken when updating your
+language.  If you are not extremely busy, you should always chose
+the most radical one.  When the update takes much more time than you
+expected, you can always decide use some suitable translator adapter to
+finish the changes later and still make your translator working.
+
+<b>The most radical way of updating the language translator</b> is
+to make your translator class derive directly 
+from the abstract class \c Translator and provide translations for the
+methods that are required to be implemented -- the compiler will
+tell you if you forgot to implement some of them.  If you are in
+doubt, have a look at the \c TranslatorEnglish class to recognize the
+purpose of the implemented method.  Looking at the previously used
+adapter class may help you sometimes, but it can also be misleading
+because the adapter classes do implement also the obsolete methods
+(see the previous \c trFiles() example).
 
-Waiting until all language maintainers have translated these new sentences
-and sent the results would not be very practical for me.
+In other words, the up-to-date language translators do not need the
+\c TranslatorAdapter_x_y_z classes at all, and you do not need to
+implement anything else than the methods required by the Translator
+class (i.e. the pure virtual methods of the \c Translator -- they 
+end with <code>=0;</code>).
 
-Instead, a new class TranslatorAdapter_x_y_z will be added to 
-translator_adapter.h (here x,y, and z correspond to the current
-version of doxygen). And all translators that previous derived from 
-Translator will now derive from this adapter class.
+If everything compiles fine, try to run \c translator.pl, and have a
+look at the translator report (ASCII file) at the \c doxygen/doc
+directory.  Even if your translator is marked as up-to-date, there
+still may be some remarks related to your souce code.  Namely, the
+obsolete methods--that are not used at all--may be listed in the
+section for your language.  Simply, remove their code (and run the
+\c translator.pl again).
 
-The Adapter class contains the new sentences with
-default translations using the English translator (which is always up to date). 
-Instead of deriving your TranslatorXX class directly from Translator it will 
-derive from the intermediate class TranslatorAdapter_x_y_z. 
+<b>If you do not have time to finish all the updates</b> you should
+still start with <em>the most radical approach</em> as described
+above.  You can always change the base class to the translator
+adapter class that implements all of the not-yet-implemented methods.
 
-Thus, if a translator class inherits from a adapter class 
-maintenance is needed. By looking at the adapter class itself (and its base
-classes) you can easily see which methods need to be updated.
+<b>If you prefer to update your translator gradually</b>, look
+at the <em>translator report</em> generated by the \c translator.pl script
+and choose one of the missing method that is implemented by the
+translator adapter, that is used as your base class. When there is
+not such a method in your translator adapter base class, you probably
+can change the translator adapter base to the newer one.
 
-To update a language simply make your translator class derive from
-the abstract class Translator and provide translations for the methods that
-were previously provided by the adapter class (and its base classes).
+Do not blindly implement all methods that are implemented by your
+translator adapter base class.  The reason is that the adapter
+classes implement also obsolete methods.  Another reason is that
+some of the methods could become obsolete later.
 
 */
 
diff --git a/doc/lists.doc b/doc/lists.doc
index eaf8616..c7e275c 100644
--- a/doc/lists.doc
+++ b/doc/lists.doc
@@ -69,13 +69,13 @@ Here is the above example with HTML commands:
    */
 \endverbatim
 
-\note The the indent here is not important.
+\note The indentation here is not important.
 
 <b>Using \\arg or \@li</b>
 
 For compatibility with the Troll Tech's internal documentation tool and
 with KDoc, doxygen has two commands that can be used to create simple
-not nested lists. 
+unnested lists. 
 
 See \ref cmdarg "\arg" and \ref cmdli "\li" for more info.
 
diff --git a/doc/maintainers.txt b/doc/maintainers.txt
index 1386a9b..c476fb5 100644
--- a/doc/maintainers.txt
+++ b/doc/maintainers.txt
@@ -62,7 +62,7 @@ Russian
 Alexandr Chelpanov: cav@cryptopro.ru
 
 Slovak
-Stanislav Kudlac: qwerty1@pobox.sk
+Stanislav Kudl&aacute;&ccaron;: qwerty1@pobox.sk
 
 Slovene
 Matjaz Ostroversnik: matjaz.ostroversnik@zrs-tk.si
diff --git a/doc/preprocessing.doc b/doc/preprocessing.doc
index 3a97d87..19f730d 100644
--- a/doc/preprocessing.doc
+++ b/doc/preprocessing.doc
@@ -17,7 +17,7 @@
 /*! \page preprocessing Preprocessing
 
 Source files that are used as input to doxygen can be parsed by doxygen's
-build-in C-preprocessor.
+built-in C-preprocessor.
 
 By default doxygen does only partial preprocessing. That is, it 
 evaluates conditional compilation statements (like \#if) and 
diff --git a/doc/starting.doc b/doc/starting.doc
index b307788..402a765 100644
--- a/doc/starting.doc
+++ b/doc/starting.doc
@@ -125,7 +125,7 @@ a browser that supports cascading style sheets (CSS) should be used
 \addindex LaTeX
 
 The generated \f$\mbox{\LaTeX}\f$ documentation must first be compiled by 
-a \f$\mbox{\LaTeX}\f$ compiler. (I use teTeX distribution version 0.9
+a \f$\mbox{\LaTeX}\f$ compiler (I use teTeX distribution version 0.9
 that contains \f$\mbox{\TeX}\f$ version 3.14159). To simplify the process 
 of compiling the generated
 documentation, \c doxygen writes a \c Makefile into the \c latex directory. 
diff --git a/doc/translator.pl b/doc/translator.pl
index b0bb9e3..9d44686 100644
--- a/doc/translator.pl
+++ b/doc/translator.pl
@@ -38,6 +38,9 @@
 #    argument list does not contain argument identifiers 
 #    (i.e., when it contains type information only).
 #
+# 2001/06/11
+#  - Character entity &ccaron; recognized in maintainers.txt.
+#
 ################################################################
 
 require 5.005;
@@ -566,13 +569,15 @@ xxxTABLE_FOOTxxx
     $tableLATEX .= $latexTableFoot;
 
     $tableHTML =~ s{@}{\@NOSPAM.}sg; 
+    $tableHTML =~ s{&ccaron;}{&#x010d;}sg; 
     $tableHTML =~ s{&rcaron;}{&#x0159;}sg; 
     
-    $tableLATEX =~ s/&rcaron;/\\v{r}/sg;
     $tableLATEX =~ s/&aacute;/\\'{a}/sg;
     $tableLATEX =~ s/&auml;/\\"{a}/sg;
     $tableLATEX =~ s/&ouml;/\\"{o}/sg;
     $tableLATEX =~ s/&oslash;/\\o{}/sg;
+    $tableLATEX =~ s/&ccaron;/\\v{c}/sg;
+    $tableLATEX =~ s/&rcaron;/\\v{r}/sg;
     $tableLATEX =~ s/_/\\_/sg;
     
     my $notice = "\nHave a look at <a href=\"../doc/$ftranslatortxt\"\n>"