- use `\cgalPckAuthor` in case of one author
- use of `\cgalPckAuthors` in case of multiple authors
- using in case of multiple authors always `, and `
- in the 1.9.6 `BaseDoxyfile.in` let the `\cgalPckAuthors` point to `\cgalPckAuthor` to get consistent output (not done for other versions as in the past the `ALIASES` could not call one another).
Implemented:
- no extra "Refines" page
- Refines on one line
- Refines always in code style
- `2 arguments` -> `two arguments` (for consistency
- added also the `\qualifier`
Implemented in Kernel_23/doc/Kernel_23/Concepts/FunctionObjectConcepts.h
Results a.o.
- doc_output/Kernel_23/classKernel_1_1Circle__2.html
- doc_output/Kernel_23/classKernel_1_1BoundedSide__3.html
Note: due to the fact that this is a test implementation pages outside the scope of Kernel_23/doc/Kernel_23/Concepts/FunctionObjectConcepts.h might not be correct (in respect to code appearance of refines and multiple refines)
In doxygen the setting `HTML_COLORSTYLE` has been introduced with as default `AUTO_LIGHT` but due to the current strategy of CGAL in respect to HTML stylesheets the divider between the treeview and the text is not properly visible anymore. Due to the same strategy the setting to `AUTO_LIGHT` does not make sense for CGAL.
When setting `HTML_COLORSTYLE=LIGHT` the divider is properly visible again.
Based on the problems with the line numbers in some warnings, see review of https://github.com/CGAL/cgal/pull/6688 one of the problems was the `ALIASES` for figures, here we have the code `\latexonly ^^ \endlatexonly` though the code in the `\latexonly` part should be LaTeX commands. Here the "attempted" newline is not necessary at all so the `^^` can be removed leaving an empty `\latexonly` part that can be removed as well.
There are a number of other numbering problems found in https://github.com/CGAL/cgal/pull/6688 but they are on the doxygen side as a proposed pull request https://github.com/doxygen/doxygen/pull/9465 has been submitted.
Update of documentation in respect of code fragments
- making code fragments work in footnotes
- placing some words in in code tags
- completing some words to code tags
- removing some `#` as they are not necessary
- don't show obfuscation code in email
In the BGL package we get a warning like:
```
/home/cgal-testsuite/cgal_doc_build/CGAL-5.4-Ic-33/doc/BGL/PackageDescription.txt:29: warning: ignoring \dot command because HAVE_DOT is not set
```
The BGL package uses the `\dot` and has now to use the setting `HAVE_DOT=YES` to see the dot image.
Till now this went OK as the `\dot` command didn't look at the setting of the `HAVE_DOT` setting in the Doxyfile, though by the issue https://github.com/doxygen/doxygen/issues/7273 and the pull request https://github.com/doxygen/doxygen/pull/8663 it is now required that `HAVE_DOT` is set.
The idea of setting `HAVE_DOT` for the BGL project removed the warning (and shows the figure again) though has also as side effect that the inheritance graphs are shown. Until now CGAL shows for the inheritance just the text version.
Doxygen now has for the `CLASS_GRAPH` setting the possibility `TEXT` that does exactly what is required.
Due to the general setting of `HAVE_DOT` also the not needed `graph_legend` was generated and some `INCLUDE_GRAPH`s, by setting this to `NO ` these are no suppressed as well.
```
warning: Tag 'LATEX_SOURCE_CODE' at line 1971 of file '.../doc_dxy/BaseDoxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'RTF_SOURCE_CODE' at line 2061 of file '.../doc_dxy/BaseDoxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'DOCBOOK_PROGRAMLISTING' at line 2166 of file '.../BaseDoxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
```
these tags have been declared obsolete (in the current master version), so they should be removed..
CGAL doesn't use the involved formats so this has no influence on the CGAL documentation processing.
Laurent Rineau
albert-github
Mael Rouxel-Labbé
Sébastien Loriot