PDF math tagging and TeX4ht

[michal-h21]

Brief outline of the bug

I've tried the new development version of LaTeX with the support for tagging of math. It seems that it clashes with math redefinitions of TeX4ht. I've got bunch of errors, and the resulting HTML doesn't display math correctly.

If I remove the math key, the result is correct, but it still produces an error:

! Package tagpdf Error: The number of automatic begin (7) and end (6)
(tagpdf)                text-unit para hooks differ!

Minimal example showing the bug

\RequirePackage{latexbug}
\DocumentMetadata{testphase={phase-III,math}}
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\section{Does section work?}

\[
  a = \frac{b^2}{\sqrt{c}}
\]

\end{document}

To compile with latex-dev, we can use this build file:

Make:htlatex {htlatex = "latex-dev"}

Compile using:

 $ make4ht -a debug -e build.lua mathbug.tex

Log file (required) and possibly PDF file

mathbug.log

This is the resulting HTML (notice missing fraction):

[FrankMittelbach]

That is not really surprising, is it (at this stage at least)?

I'm not quite sure what you expect, but make4ht alters the way how various commands are defined, e.g., \section becomes \rdef:sec {section} and that is by no means "eventually" running the original code, but it runs some other code to support the ht conversion. As a result it misses out what is necessary for tagging, while other parts of the document (in particular the changes back and to hmode) still add tagging structures. As a result structures are opened but not closed or not opened when that is necessary.

With respect to the math tagging, this loads amsmath as part of the setup, but somehow your additional code manages to move in before that so that the primitive \over expected by amsmath nis no longer the primitive but

\over=macro:
->\ifx \EndPicture \:UnDef \expandafter \n:over: \else \expandafter \o:over: \fi .

As a result the saved version \@@overis never defined and the rest is history ... I haven't looked closely what has happened but it most certainly explains why the \frac fails. That particular problem vanishes (I think) if the document explicitly (also) loads amsmath in the preamble, because I guess that is seen by tex4ht. However it then fails again because it overwrites all kind of math environments and they are also generically altered for tagging support to always grab the environment body (including cases like \[ ... \] and that then after the redefinitions).

As I said in the announcement and in ltnews37, this is a prototype that is expected to work with basic documents conforming to what is described in Lamport's manual ... anything else is a plus, but adding packages that overwrite internals are most likely not going to work at all (unless they account for the new setup (which obviously they can't at this stage). And clearly, that is what happens as part of make4ht.

So this is not a bug of the prototype and I'm going to move this over to discussions for now.

[michal-h21]

Thanks for the answer, Frank. I am surprised mainly because it works better than I expected. I feared the compilation would end with a fatal error, so the result is undoubtedly better. I just wanted to provide a test case and spark some discussion.

Now there are two possible solutions for TeX4ht:

• prevent PDF management from loading altogether, which would be easy, but I am not sure if it will not cause issues in the future.
• create .4ht files for PDF management libraries, which would be useful if the PDF management will be loaded by default in the future. The problem at the moment is that TeX4ht is loaded before \documentclass, so anything used in the TeX file before the document class is not tracked and cannot be patched by TeX4ht. I hope this should be fixable on our side.

So I guess that my current question is: will be PDF management enabled by default in the future, even in the DVI mode?

[u-fischer]

The PDF management is enabled if you use only \DocumentMetadata{} and there should normally be no problem with make4ht (your example works fine) as it basically only adds some pdf related tools and xmp metadata.

The interesting stuff begins if you load additional/new code with the testphase key (or if this code moves later into the kernel). This new code does basically two things:

• it redefines various commands to improve them and prepare them for the tagging and adds code via hooks (like the para-hooks)
• it activates the tagging.

It is easy to deactivate tagging (or not activate it) if tex4ht is detected and that would avoid your error, but it is also possible that tex4ht can actually make use of the tagging commands. After all the \tagstructbegin and \tagstructend are probably often inserted in the same place where tex4ht wants to inject its code.

A larger problem are the redefinitions: the changes here ranges from (currently) small changes which only adding some tagging commands to complete rewrites, e.g lists have been reimplemented with xtemplate. These changes are not only for tagging but also add new functionality, extend the optional arguments, or add better support for hyperlinks.

It would naturally be possible for tex4ht to suppress all these redefinitions and to stick to "legacy" LaTeX, but imho in the long run users will want to use the improved interfaces with tex4ht too, so it would be better if tex4ht would work with the new definitions too.