compability with future latex versions

[u-fischer]

in connection with the project "Tagged PDF" we are extending the support for pdf related commands in the LaTeX kernel.

The new code is in part already in the kernel (in l3pdf and l3kernel) and in part in a temporary testphase package pdfmanagement-testphase.

Most importantly: with the new code we want to replace a few primitives which write to central dictionaries and resources in the pdf by a new managed command to prevent clashes between packages and kernel code. This means that packages which use one of \pdfinfo, \pdfcatalog, \pdfpageattr, \pdfpagesattr or \pdfpageresources (and analog commands of the other engines) will be incompatible with the new pdfmanagement.

This affects ocg.sty which is in the asymptote package on ctan. It uses \pdfpageresources and \pdfcatalog.

[johncbowman]

Please let us know the new proposed names for \pdfpageresources and \pdfcatalog and also how to detect which version (old or new) should be used.

Why not provide a backwards-compatible wrapper?

[u-fischer]

The new command to add something to the page resources and the catalog

   \pdfmanagement_add:nnn{Page/Resources/ExtGState}{key}{value}    
   \pdfmanagement_add:nnn{Catalog}{key}{value}    

To add something to the /Properties resource you should use a BDC-mark with eg. \pdf_bdc:nn (this is needed to stay compatible with dvips).

Documentation is in l3pdfmanagement.pdf. I can also give you explicit code and a test if you need it. But in your case I think you should consider if you really want to continue to use ocg.sty. The newer ocgx2 (https://ctan.org/pkg/ocgx2) has more functions, supports more engines and backends and is already compatible.

Why not provide a backwards-compatible wrapper?

Well the new command is such wrapper. But it won't work if people bypass the new wrapper and continue to use the primitives. We can't redefine the primitives to use the new wrapper: at first that wouldn't work for other engines and backends like lualatex or xelatex or dvips, and at second the argument of the primitives are arbitrary token lists, and people have used them in various ways, one can't parse that in a reliable way, so we could only issue an error or make the primitive a no-op, and that would then break ocg.sty too.

[johncbowman]

Unfortunately the ocgx2 package is not a drop-in replacement for ocg. The example asy -V -f pdf examples/layers.asy shows misalignment of the layers, probably due to spurious spaces in ocgx2.sty (perhaps the same spurious spaces that I removed on 2009/06/01 from ocg.sty?).

For now, I have simply upgraded from ocg.sty to ocgx.sty. Hopefully ocgx.sty will continue to be supported (otherwise, ocgx2.sty will need to be fixed).

[u-fischer]

ocgx.sty is a small extension of ocg-p.sty. ocg-p.sty has the same problem as ocg.sty. (That is unavoilable, if you want to add optional content you have to write to the catalog and the pageresouces, and without the new pdfmanagement that can only be done by using the primitives).

I wrote also to the maintainer of ocg-p, but didn't get an answer (and I don't know if they are still active).

The only package in this area which is actively maintained and so supports the new pdfmanagement is ocgx2. And if you found a bug or incompability there then it would be good to open an issue at https://gitlab.com/agrahn/ocgx2. I'm quite confident that Alexander is willing to repair this.

[johncbowman]

Reported here: https://gitlab.com/agrahn/ocgx2/-/issues/18

[u-fischer]

Hm, I tried your example with the option -k. In the layer_tex, there seems to be a spurious space after the ocg-enviroments

\begin{ocg}{A}{1}{1}
{\catcode`"=12%
\includegraphics{layers_1}%
}%
\kern -155.452187pt%
\end{ocg}   %<----------------------------here
{\catcode`"=12%
\includegraphics{layers_2}%
}%

If I hide this space with a % the layers align.

[johncbowman]

Thank you, Ulrike for isolating this; I didn't have time to check.

I have closed https://gitlab.com/agrahn/ocgx2/-/issues/18 and upgraded asy from ocgx to ocgx2. All is well again.