Dagstuhl Reports

You may wonder why algorithms appear as vector graphics in the HTML version of many documents instead of being an integral part of the HTML output. The reason is the following:

Algorithms combine graphics-like output and text in a way that an accurate HTML-conversion is difficult to obtain in the general case. In particular, we observed major layout issues regarding nested structures (e.g., loops, conditionals, ...) and noticed that the line numbers of the LaTeXML output often do not match the line numbers in the PDF (an inaccuracy which we consider not acceptable).

Whenever necessary by the above reasons, we prefer to embed algorithms as vector graphics (more precisely, as SVG) to guarantee in particular that line breaks and line numbering are consistent between the two document versions (PDF/HTML).

Our LaTeX-to-HTML conversion is based on the open-source tool LaTeXML, as is the case with arXiv.

Since not all LaTeX packages are supported by LaTeXML and many authors use custom macros or LaTeX hacks, it may frequently happen that the direct LaTeXML output contains unacceptable display errors. In severe cases, HTML generation fails completely.

As arXiv also points out, the quality of the HTML output depends largely on best practices in LaTeX use (see arXiv: Submit LaTeX Best Practices).

We collect suggestions for authors on how to create LaTeX that is as suitable as possible for HTML generation in the following FAQ:

• How can authors improve the HTML output of their publications?

Based on feedback from authors, we document the most common problems there and try to gradually expand coverage.

In order to improve the resulting HTML and increase coverage, and to meet our high quality standards as well as those of our authors and readers, Dagstuhl Publishing - unlike arXiv - relies on a semi-automatic transformation process: First, we attempt to resolve incompatibilities manually (at the LaTeX level) in order to enable or improve the conversion. Subsequently, a visual check is performed to identify and correct remaining inconsistencies. This significant additional effort is very promising but also cost-intensive.

Of the over 1000 documents processed so far, 90% have been successfully converted into HTML suitable for publication. However, the significant additional costs are currently not covered by the APC, which already barely covers costs. HTML conversion is therefore currently being run as an experimental project. Only after a thorough evaluation of the project after a minimum period of one year, a decision will be made on whether to continue HTML support.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF remains the primary output format at Dagstuhl Publishing. However, starting in 2025, we will also offer HTML, as HTML content is significantly more accessible on screen readers, screen magnifiers, and mobile devices. While PDFs were developed primarily for true-to-print display, HTML allows for flexible adaptation to users with different needs (e.g. enlarged text, high-contrast display or linear reading aloud by screen readers).

By providing HTML, we want to break down barriers and improve access to our publications.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

HTML (or XML) currently offers the most reliable way to make document content accessible:

• Support from assistive technologies: Screen readers and magnification software can interpret HTML content much better than PDF.
• Structured presentation: HTML allows clear semantic markup (headings, lists, tables, formulas), which is crucial for barrier-free use.
• Flexible use: Content adapts to different devices and screen sizes – a clear advantage for mobile use.

ArXiv also refers to HTML as the most promising way to make scientific content accessible (see arXiv HTML as an accessible format for papers).

See also the related FAQ "Why are we not (yet) using PDF/UA as an accessible format?"

The quality of the HTML output depends heavily on how consistent and standard-compliant a LaTeX document is structured. Some packages or self-defined macros can make conversion difficult or impossible. The following tips are based on arXiv's best practices:

1. Use standard LaTeX
   • Use the document classes and packages Dagstuhl Publishing provides whenever possible.
   • Avoid unnecessary LaTeX hacks or workarounds that are not documented.
2. Maintain semantic structure
   • Mark headings with \section, \subsection, etc. – not just with manual formatting (\textbf, \large).
   • Do not set numbering manually, but use the designated LaTeX commands (enumerate environments).
3. Set mathematical expressions and formulas correctly
   • Always write mathematical expressions in $...$ (inline) or \[...\] / equation environments.
   • Define your own macros sparingly and comprehensibly.
4. Mark tables and figures appropriately
   • Create tables with the tabular environment and, if possible, without exotic extensions.
   • For figures, use \includegraphics in a figure environment and – if possible – add \caption.
   • Specify alt text for figures: \includegraphics[alt={plain-text description of image}]{example-image-a}
5. Avoid incompatible packages
   • Some packages that deeply interfere with the layout (e.g. certain table or math packages) are problematic with LaTeXML.
   • If possible, don’t use additional packages or switch to generally supported packages.
   • See FAQ: Which packages cause problems with LaTeXML?

In short: The cleaner the structure of a LaTeX document, the more likely it is that the HTML conversion will be successful and of high quality.

There are various reasons why an HTML version of a document may not have been published (yet).

If the article (the PDF) was published only recently (up to 3 months ago), it is very likely that HTML production for the volume has not been completed. Once the HTML version has been published, all authors will be informed accordingly.

If your article (the PDF) was published after 1 January 2025 (and not within the last 3 months), the conversion of the article to HTML was probably unsuccessful. There may be various reasons for this. Please read the FAQs for more information:

• How can authors improve the HTML output of their publications?
• Which packages cause problems for LaTeXML?

Of course, you can also contact the publisher at any time.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF/UA (Universal Accessibility) is the ISO standard for accessible PDF documents. Since 2021, our publications have been published in PDF/A (Archivable) format, which is optimised for long-term archiving. In theory, it is possible to create a document that is both PDF/A and PDF/UA compliant. In practice, however, this is currently hardly feasible with LaTeX, as the necessary tools and workflows are not yet mature.

The current status of the LaTeX project for creating Tagged PDF (the basis for PDF/UA) is still experimental (see LaTeX tagging project). A stable version does not yet exist. Before widespread use, extensive compatibility tests would also have to be carried out with the numerous LaTeX packages that our authors use in addition to the classes provided.

We evaluate developments regularly, but currently see no practical way of reliably generating PDF/UA with our LaTeX-based publication process.

LaTeXML already supports a large number of LaTeX packages, but not all of them. Please see this website for the list of packages currently supported by LaTeXML. As a general rule:

• All packages included in the document classes/styles offered by Dagstuhl Publishing are currently compatible with LaTeXML and are supported.
• Problems may arise if authors include additional packages that are not (yet) covered by LaTeXML.

In such cases, we recommend:

1. Checking whether the package is really necessary or whether there is an alternative that is already supported.
2. Contribute to the community: LaTeXML is public domain software and open to contributions from third parties.
   • Open issues and problems can be reported directly in the LaTeXML issue tracker on GitHub.
   • Information on collaboration can be found on the following websites: LaTeXML documentation, Porting LaTeX packages for LaTeXML, and How to Contribute.

In short: All packages provided by Dagstuhl Publishing as standard are safe. For additional packages, authors themselves or together with the LaTeXML community can contribute to improving support.

Here we collect packages that are currently incompatible, along with possible alternatives and workarounds:

• apxproof: Causes LaTeXml to fail. - Do not use, if possible. In particular, remove the package if no appendix is given. If it is only rarely used, try to move the proofs manually to the appendix.
• Proof-at-the-end: same as apxproof.
• kotex: Causes LaTeXml to fail. – Do not use unless strictly necessary.
• siunitx: Not supported by LaTeXml, leaves error messages in the produced HTML. – Do not use unless strictly necessary.
• derivative: Not supported by LaTeXml, leaves error messages in the produced HTML. – Try to use \frac and \partial instead, like \frac{\partial f}{\partial t}
• forest: Not supported by LaTeXml, can be externalized (see note below).
• kbordermatrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• mathpartir (inferrules): Not supported by LaTeXml, leaves error messages in the produced HTML. In very simple cases, use ordinary fractions instead. – externalization possible (see note below).
• minted: Try to avoid mintinline if possible unless strictly necessary. If you use it, try to avoid unicode symbols.
• nicematrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• prooftree: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• syntax: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• xy: Not supported by LaTeXml, leaves error messages in the produced HTML. - can be externalized (see note below).
• knowledge: Collect knowledge definitions in the LaTeX header (and add a blank line below).

NOTE: Problems with various packages used to generate diagrams, images or similar can be resolved by first externalising the results of these packages as standalone PDFs using the document class standalone and then embedding the PDFs as images instead of the code used to generate them. See also the FAQ How do I use the standalone class to create separate images?

With the standalone class, any TeX code, e.g. for generating a graphic or diagram, can be converted into a separate PDF. This image can then be easily integrated into the main document as usual using \includegraphics command.

1. Create a TeX file using the standalone class, e.g. with the following basic structure:

   \documentclass{standalone}
   \usepackage{xyz}
   
   \begin{document}
   \begin{somepicture}
   \somedrawingcommands
   \end{somepicture}
   \end{document}
   

2. Save and compile this TeX file, e.g. as sample.tex (with the compile result sample.pdf)
3. Open the TeX file of your main document and include the resulting pdf, e.g. \includegraphics{sample.pdf}.

It is also possible to generate several images with one standalone file. To do this, you only need to define a corresponding environment in the documentclass option, e.g. \documentclass[multi=newFigure]{standalone}, and wrap the code for each of the separate images with this environment, so \begin{newFigure}…\end{newFigure}. To include the images into the main document, please use then the page option of the grahics command, e.g. \includegraphics[page=1]{sample.pdf}.

For more detailed instructions, please see the package document on CTAN. However, please don't use the commands provided by standalone package within the main document to include the separated code, e.g. \includestandalone[...]{sample.tex} as this is currently not yet supported by our LaTeX processing workflow. Instead please include the pre-compiled, resulting PDF.

You may wonder why algorithms appear as vector graphics in the HTML version of many documents instead of being an integral part of the HTML output. The reason is the following:

Algorithms combine graphics-like output and text in a way that an accurate HTML-conversion is difficult to obtain in the general case. In particular, we observed major layout issues regarding nested structures (e.g., loops, conditionals, ...) and noticed that the line numbers of the LaTeXML output often do not match the line numbers in the PDF (an inaccuracy which we consider not acceptable).

Whenever necessary by the above reasons, we prefer to embed algorithms as vector graphics (more precisely, as SVG) to guarantee in particular that line breaks and line numbering are consistent between the two document versions (PDF/HTML).

Our LaTeX-to-HTML conversion is based on the open-source tool LaTeXML, as is the case with arXiv.

Since not all LaTeX packages are supported by LaTeXML and many authors use custom macros or LaTeX hacks, it may frequently happen that the direct LaTeXML output contains unacceptable display errors. In severe cases, HTML generation fails completely.

As arXiv also points out, the quality of the HTML output depends largely on best practices in LaTeX use (see arXiv: Submit LaTeX Best Practices).

We collect suggestions for authors on how to create LaTeX that is as suitable as possible for HTML generation in the following FAQ:

• How can authors improve the HTML output of their publications?

Based on feedback from authors, we document the most common problems there and try to gradually expand coverage.

In order to improve the resulting HTML and increase coverage, and to meet our high quality standards as well as those of our authors and readers, Dagstuhl Publishing - unlike arXiv - relies on a semi-automatic transformation process: First, we attempt to resolve incompatibilities manually (at the LaTeX level) in order to enable or improve the conversion. Subsequently, a visual check is performed to identify and correct remaining inconsistencies. This significant additional effort is very promising but also cost-intensive.

Of the over 1000 documents processed so far, 90% have been successfully converted into HTML suitable for publication. However, the significant additional costs are currently not covered by the APC, which already barely covers costs. HTML conversion is therefore currently being run as an experimental project. Only after a thorough evaluation of the project after a minimum period of one year, a decision will be made on whether to continue HTML support.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF remains the primary output format at Dagstuhl Publishing. However, starting in 2025, we will also offer HTML, as HTML content is significantly more accessible on screen readers, screen magnifiers, and mobile devices. While PDFs were developed primarily for true-to-print display, HTML allows for flexible adaptation to users with different needs (e.g. enlarged text, high-contrast display or linear reading aloud by screen readers).

By providing HTML, we want to break down barriers and improve access to our publications.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

HTML (or XML) currently offers the most reliable way to make document content accessible:

• Support from assistive technologies: Screen readers and magnification software can interpret HTML content much better than PDF.
• Structured presentation: HTML allows clear semantic markup (headings, lists, tables, formulas), which is crucial for barrier-free use.
• Flexible use: Content adapts to different devices and screen sizes – a clear advantage for mobile use.

ArXiv also refers to HTML as the most promising way to make scientific content accessible (see arXiv HTML as an accessible format for papers).

See also the related FAQ "Why are we not (yet) using PDF/UA as an accessible format?"

The quality of the HTML output depends heavily on how consistent and standard-compliant a LaTeX document is structured. Some packages or self-defined macros can make conversion difficult or impossible. The following tips are based on arXiv's best practices:

1. Use standard LaTeX
   • Use the document classes and packages Dagstuhl Publishing provides whenever possible.
   • Avoid unnecessary LaTeX hacks or workarounds that are not documented.
2. Maintain semantic structure
   • Mark headings with \section, \subsection, etc. – not just with manual formatting (\textbf, \large).
   • Do not set numbering manually, but use the designated LaTeX commands (enumerate environments).
3. Set mathematical expressions and formulas correctly
   • Always write mathematical expressions in $...$ (inline) or \[...\] / equation environments.
   • Define your own macros sparingly and comprehensibly.
4. Mark tables and figures appropriately
   • Create tables with the tabular environment and, if possible, without exotic extensions.
   • For figures, use \includegraphics in a figure environment and – if possible – add \caption.
   • Specify alt text for figures: \includegraphics[alt={plain-text description of image}]{example-image-a}
5. Avoid incompatible packages
   • Some packages that deeply interfere with the layout (e.g. certain table or math packages) are problematic with LaTeXML.
   • If possible, don’t use additional packages or switch to generally supported packages.
   • See FAQ: Which packages cause problems with LaTeXML?

In short: The cleaner the structure of a LaTeX document, the more likely it is that the HTML conversion will be successful and of high quality.

There are various reasons why an HTML version of a document may not have been published (yet).

If the article (the PDF) was published only recently (up to 3 months ago), it is very likely that HTML production for the volume has not been completed. Once the HTML version has been published, all authors will be informed accordingly.

If your article (the PDF) was published after 1 January 2025 (and not within the last 3 months), the conversion of the article to HTML was probably unsuccessful. There may be various reasons for this. Please read the FAQs for more information:

• How can authors improve the HTML output of their publications?
• Which packages cause problems for LaTeXML?

Of course, you can also contact the publisher at any time.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF/UA (Universal Accessibility) is the ISO standard for accessible PDF documents. Since 2021, our publications have been published in PDF/A (Archivable) format, which is optimised for long-term archiving. In theory, it is possible to create a document that is both PDF/A and PDF/UA compliant. In practice, however, this is currently hardly feasible with LaTeX, as the necessary tools and workflows are not yet mature.

The current status of the LaTeX project for creating Tagged PDF (the basis for PDF/UA) is still experimental (see LaTeX tagging project). A stable version does not yet exist. Before widespread use, extensive compatibility tests would also have to be carried out with the numerous LaTeX packages that our authors use in addition to the classes provided.

We evaluate developments regularly, but currently see no practical way of reliably generating PDF/UA with our LaTeX-based publication process.

LaTeXML already supports a large number of LaTeX packages, but not all of them. Please see this website for the list of packages currently supported by LaTeXML. As a general rule:

• All packages included in the document classes/styles offered by Dagstuhl Publishing are currently compatible with LaTeXML and are supported.
• Problems may arise if authors include additional packages that are not (yet) covered by LaTeXML.

In such cases, we recommend:

1. Checking whether the package is really necessary or whether there is an alternative that is already supported.
2. Contribute to the community: LaTeXML is public domain software and open to contributions from third parties.
   • Open issues and problems can be reported directly in the LaTeXML issue tracker on GitHub.
   • Information on collaboration can be found on the following websites: LaTeXML documentation, Porting LaTeX packages for LaTeXML, and How to Contribute.

In short: All packages provided by Dagstuhl Publishing as standard are safe. For additional packages, authors themselves or together with the LaTeXML community can contribute to improving support.

Here we collect packages that are currently incompatible, along with possible alternatives and workarounds:

• apxproof: Causes LaTeXml to fail. - Do not use, if possible. In particular, remove the package if no appendix is given. If it is only rarely used, try to move the proofs manually to the appendix.
• Proof-at-the-end: same as apxproof.
• kotex: Causes LaTeXml to fail. – Do not use unless strictly necessary.
• siunitx: Not supported by LaTeXml, leaves error messages in the produced HTML. – Do not use unless strictly necessary.
• derivative: Not supported by LaTeXml, leaves error messages in the produced HTML. – Try to use \frac and \partial instead, like \frac{\partial f}{\partial t}
• forest: Not supported by LaTeXml, can be externalized (see note below).
• kbordermatrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• mathpartir (inferrules): Not supported by LaTeXml, leaves error messages in the produced HTML. In very simple cases, use ordinary fractions instead. – externalization possible (see note below).
• minted: Try to avoid mintinline if possible unless strictly necessary. If you use it, try to avoid unicode symbols.
• nicematrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• prooftree: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• syntax: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• xy: Not supported by LaTeXml, leaves error messages in the produced HTML. - can be externalized (see note below).
• knowledge: Collect knowledge definitions in the LaTeX header (and add a blank line below).

NOTE: Problems with various packages used to generate diagrams, images or similar can be resolved by first externalising the results of these packages as standalone PDFs using the document class standalone and then embedding the PDFs as images instead of the code used to generate them. See also the FAQ How do I use the standalone class to create separate images?

With the standalone class, any TeX code, e.g. for generating a graphic or diagram, can be converted into a separate PDF. This image can then be easily integrated into the main document as usual using \includegraphics command.

1. Create a TeX file using the standalone class, e.g. with the following basic structure:

   \documentclass{standalone}
   \usepackage{xyz}
   
   \begin{document}
   \begin{somepicture}
   \somedrawingcommands
   \end{somepicture}
   \end{document}
   

2. Save and compile this TeX file, e.g. as sample.tex (with the compile result sample.pdf)
3. Open the TeX file of your main document and include the resulting pdf, e.g. \includegraphics{sample.pdf}.

It is also possible to generate several images with one standalone file. To do this, you only need to define a corresponding environment in the documentclass option, e.g. \documentclass[multi=newFigure]{standalone}, and wrap the code for each of the separate images with this environment, so \begin{newFigure}…\end{newFigure}. To include the images into the main document, please use then the page option of the grahics command, e.g. \includegraphics[page=1]{sample.pdf}.

For more detailed instructions, please see the package document on CTAN. However, please don't use the commands provided by standalone package within the main document to include the separated code, e.g. \includestandalone[...]{sample.tex} as this is currently not yet supported by our LaTeX processing workflow. Instead please include the pre-compiled, resulting PDF.

The list of editors is restricted to the organisers of the seminar. The collector is mentioned as editorial assistant directly on the front page of the report (i.e., "Edited in cooperation with ..."). Furthermore, the collector receives a fair compensation for his efforts after the report is published.

Dagstuhl Publishing and the scientific director of Schloss Dagstuhl decided several years ago to unify the format of the seminar documentation and to publish these documentations as so called Dagstuhl Reports. It was decided that only the official organizers of the seminar are listed as editors of the respective report.

Yes, we expect our Perspective Workshops to prepare a Dagstuhl Report and a Dagstuhl Manifesto.

The Dagstuhl Reports series aims at documenting a seminar/workshop; the report is not reviewed. See http://www.dagstuhl.de/dagrep.
(We expect the submission of the report 3 months after the workshop/seminar.)

A Dagstuhl Manifesto aims at describing the state of the art of the field and proposing visions and perspectives. The manifesto is reviewed by the scientific directorate of Dagstuhl. The manifesto targets both the scientific community and "political" stakeholders (such as funding agencies, EU departments, ...). See http://www.dagstuhl.de/dagman.
(We expect the submission of the manifesto ~6 months after the seminar.)