Xe(La)TeX and \pdfobj

[ByronAhn]

Describe the bug
Compiling any document with Xe(La)TeX and accessibility.sty leads to an error in compiling; something like:

./accessibility.sty:81: Undefined control sequence.
<recently read> \pdfobj 
                        
l.81 \pdfobj
             reserveobjnum%

./accessibility.sty:81: LaTeX Error: Missing \begin{document}.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.81 \pdfobj r
              eserveobjnum%
./accessibility.sty:82: Undefined control sequence.
<argument> ... c@StructTree\endcsname \pdflastobj 
                                                  \relax 
l.82 \setcounter{StructTree}{\pdflastobj}

It seems to me this is because \pdfobj is not a defined under the XeTeX engine (see this thread on tug.org).

To Reproduce
Steps to reproduce the behavior:

1. Write a MWE that works under pdfTeX, e.g.:

\documentclass{article}
\usepackage{accessibility}
\begin{document}
This is a test.
\end{document}

2. Try compiling that same .tex document using XeLaTeX, get errors.
3. The compiled PDF looks like this:

reserveobjnum
=0=6
reserveobjnumThis is a test.

Expected behavior
It should compile, but it does not.

Version

• Device: MacBook Air (M1, 2020)
• OS: macOS 13.5.1
• accessibility.sty Version: [2023/01/18 v. 2.1.0]
• TeX Version: TeXLive 2021

[AndyClifton]

Thanks @ByronAhn for reporting this.

As you noted, the accessibility package was not designed to work with Xe(La)Tex, so I think it's unlikely this will be fixed by a simple tweak to the accessibility package.

The use of the \pdfobj is fairly central to the package, but the link you provided to TUG does imply that it might be possible to detect the compiler and choose the right construct. For various reasons though (chiefly, not enough hours in the day) I will not be pushing this. You are welcome to try!

You may be aware that the LaTeX team has a project ongoing to bake accessibility in to the PDF generation process as a core function of LaTeX, i.e. in the kernel. This is described e.g. here and you can see a more complete list of related publications here.

@FrankMittelbach is there anything you would like to add about how the ongoing project and potential kernel changes will impact Xe(La)TeX? This may be obvious for some, but not for all.

[Reissner]

I use lualatex which is I think more mainstream.
Also it is easy to reach PDF/A and now I am in a dilemma,... I want tagging also but I want to stay with my compiler....
for many reasons.. It is by the way the recommended one.

I am aware that tagging will be integrated into the kernel via \DocumentMetadata{tagging=on},
but there are particular elements i am in a struggle.... listings and images among others.
Therefore I would try the accessibility package.

[FrankMittelbach]

I am aware that tagging will be integrated into the kernel via \DocumentMetadata{tagging=on},
but there are particular elements i am in a struggle.... listings and images among others.
Therefore I would try the accessibility package.

forget trying to use the accessibility package, it was a very early attempt and never worked and there is no chance that it ever will as it doesn't use a sustainable approach. You should have no issues with using the official solution from the LaTeX team when it comes to images. listings as with the listings page, say, are still a problem but those will also get solved over time. So far more than 600 packages are already fully compatible and more will follow. If you haven't done so already, check out https://latex3.github.io/tagging-project/

@AndyClifton One should really consider to move the accessibility package to obsolete on CTAN as it will only result in people spending time on something that doesn't work for them and because of its name it is a natural to spend many frustrating hours on it before finding out that it is hopeless.