Figures appear at the end of the document

[timbastin]

Hello, first, thank you so much for this project! We are using it to generate PDF documents from markdown files. Since the PDFs need to be accessible and therefore have to have tags, we decided to give the test phase 3 a try.

Everything works fine, nevertheless, it appears that all our figures are placed at the very end of the document tags. They do appear in the correct place in the pdf itself, but not in the tag hierachy. Is this is a known issue?

Here is some example code:

\DocumentMetadata{testphase=phase-III,testphase=math}
\documentclass{article}
\usepackage{graphicx}
\usepackage{lipsum}
\usepackage{caption}
\begin{document}

\tableofcontents 

\section{Grafik}
\lipsum[5]

\begin{figure}
\includegraphics{assets/test.png}
\caption{Test-Grafik}
\end{figure}

\section{section}
\subsection{Subsection}%

some text with a \footnote{a footnote}

\begin{enumerate}
\item a list
 \begin{itemize}
  \item more list
 \end{itemize}
\end{enumerate}

\begin{verbatim}
some verbatim
some verbatim
\end{verbatim}

inline math

display math
\begin{equation}
x=y
\end{equation}

\lipsum

\end{document}

This leads to this Tag-Structure:

We are using lualatex-dev Version 1.17.0 (TeX Live 2023) (tl-20231213)

[u-fischer]

This is not an issue but a design decision. Floats are not part of the normal text flow, instead a reader consults when they see e.g. a reference. They are normally placed in special regions (top, bottom or margin) of a page, in some document design they are even implemented as "endfloats". This means that placing them in structure in the middle of the text flow is normally wrong and so we decided to implement an "endfloat" structure tree.

This is not the final state. We know that there are cases, e.g. if the float is a "non-floating-H" float without a caption, where it would be better to leave it at the position where it appears in the source, or perhaps to move it only to the end of the current section. We will refine this later.

[josephwright]

Not just me then :)

[FrankMittelbach]

I marked it as "enhancement" because as Ulrike said we intend to offer some configuration possibilities at a later stage.

[timbastin]

Thank you so much for your explanation and the fast response!

[seb-kw]

👍 sounds great! Thanks for your effort in this project!

[car222222]

@timbastin , @seb-kw , @josephwright : Do you have any ideas concerning where we might locate such “floating material” in the structure tree?

[timbastin]

For me, this is perfectly fine. I just did not know, that screen reader actually work that way. I was tasked to generate PDF-UA compliant PDFs using LaTeX, the explanation was enough to understand that everything works fine already.

[u-fischer]

@timbastin But as I wrote: this is not the final state, we will adapt it based on experience and feed back. Btw: another thing where the structure tree differs from the visual document is the caption: PDF requires Caption to be the first substructure of its parent and so the code will always move it up.

[timbastin]

@u-fischer Thanks! Inside one of your papers, I read that the Adobe Acrobat has a bug considering the use of Lbl tags as section headings. Can you elaborate a bit on that? Is there any source which I can refer to, to prove, that indeed this is an issue with the acrobat test and not the pdf itself?

[FrankMittelbach]

@timbastin please note that it is not the best place to ask such general questions as part of an unrelated issue (and in fact it is not good to ask them as part of any issue at all :-) ). Instead, perhaps a better place is under discussions.

[timbastin]

@FrankMittelbach I agree. For anyone who is interested, I think this is a good source for the use of LBL tags, which proves, that indeed there is a bug with the Adobe Acrobat: https://pdfa.org/wp-content/uploads/2019/06/TaggedPDFBestPracticeGuideSyntax.pdf#page=26