Enabling PDF tagging causes `[noitemsep]` to have no effect

[Witiko]

Consider the following example LaTeX document:

\documentclass{article}
\usepackage{enumitem}
\begin{document}
\begin{itemize}[noitemsep]
\item foo
\item bar
\item baz
\end{itemize}
\end{document}

Compiling the document using TeX Live 2022 with all packages updated today produces the following output:

This output is as expected.

However, when I enable PDF tagging by adding the line \DocumentMetadata{testphase=phase-III} before \documentclass{article}, the following output is produced:

As you can see, the option noitemsep seems to have no effect now, which is not as expected. The same output is produced with LuaLaTeX and pdfLaTeX.

[FrankMittelbach]

If you look into https://latex3.github.io/tagging-project/tagging-status/ you will see the following entry for enumitem:

partially-compatible

The package itself can’t be loaded right now. However, the tagging code supports (most of) the document-level syntax of enumitem, so that one can use, for example, \begin{itemize}[...] out of the box. See [1]

The reason is that the tagging code reimplements the underlying list environments and that is incompatible with loading enumitem. It does however emulate parts of enumitem, so that keys can be used without loading the package. But again that isn't finished work so several keys do not work yet.

[Witiko]

Thank you for the helpful explanation. I knew the package enumitem was partially-compatible but I did not realize how far the tagging code goes in preventing packages from being loaded / emulating parts of them. I assumed that loading the package enumitem might break tagging, not that LaTeX would prevent the package from being loaded without a peep.

[FrankMittelbach]

I wasn't saying that we do that (preventing enumitem from loading ... perhaps we should - with or without peep).

I'm saying that the tagging code provides a list implementation that is very different from enumitem but emulates a lot of it already (without loading it). If you load enumitem in addition then some parts of it get overwritten by the tagging code -- as for now it is partly done in the hook begindocument/before and some parts of enumitem survive ... and that leads to chaos.

But the core issue in your case is that the emulation do not contain a noitemsep key (yet)

The reason why we add the new list implementation very late (for now) is that this helps a lot in many cases, e.g, when classes define things like "quotation" or make minor mods to the 2e list implementation. If \DocumentMetadata would already make those definitions then such classes would overwrite it again. Of course this isn't quite how it will be in the end.

Try

\DocumentMetadata{testphase=phase-III}
\documentclass{article}

\usepackage{enumitem}
\ShowEnvironment{itemize}  % <-- enum def

\ShowHook{begindocument/before}

\begin{document}
\ShowEnvironment{itemize}  % <-- tagging def

to see that enumitem is loaded but only survives in parts.

[Witiko]

tagging code [...] leads to chaos

I may (mis)quote you on this. 🙂

[Witiko]

If you load enumitem in addition then some parts of it get overwritten [...] that leads to chaos.

Currently, we load enumitem in the Markdown package to provide default definitions for Markdown lists. From what you write, it seems to me that it would make more sense to not load enumitem when PDF tagging is enabled and just use the built-in extended syntax of \begin{itemize}[...] for the default definitions.

[Witiko]

However, if loading enumitem is considered benign and the package is going to be compatible eventually, I'd prefer not to maintain this extra logic in the Markdown package, especially since there does not seem to be a straightforward way of detecting whether PDF tagging is enabled besides checking that the prop \g__pdfmanagement_documentproperties_prop exists and contains some key document/testphase/phase-*.

Any advice is appreciated. Currently, it seems to me that loading enumitem is benign, and I would be in favor of keeping to load it in the Markdown package, regardless of whether PDF tagging is enabled. However, I am happy to be persuaded.

[FrankMittelbach]

@u-fischer any comments?

[u-fischer]

@FrankMittelbach I do not think that it makes sense to use enumitem together with the new block code -- even without tagging something will break due to the code mix. I would suggest that we substitute it (with a loud warning) in the block code by e.g. enumitem-ltx.sty and start to fill that with replacements for the enumitem commands.