hyperref with bookmarks=true and tikzexternalize clashes in edge cases
#1127
Comments
|
hyperref messes with PDF objects. When you include a file that has the same xrefs as the original file they will clash. You will have to find out which commands generate the problematic xrefs and then use \tikzexternalize[optimize=true,optimize command away=\ProblematicHyperrefCommand] |
|
While I will certainly read up on this, it's unclear to me how this relates to the fact that the MWE can be "fixed" by removing the whitespace between The error message for the tikzexternalized figure under the MWE is indicating that something with the bookmarks written to The "broken" bookmarks written to whereas the bookmarks yielded by removing the whitespaces (& where compilation suceeds) are How exactly does this relate to your proposed fix (sorry I am very unfamiliar with latex internals such as xref) ? I can also not find any common typesetting errors/formatting errors of the first Best, |
|
It seems like I misunderstood your problem. I thought the problem was that the reference inside the plot is not clickable, but you are now telling me that there is a |
Weird as the docker image also uses latest TL2021. Could you try to reproduce with the provided docker image/command ? I have attached failing twice on |
|
I'm also not able to reproduce the Of course I have to run this twice to get the cross-references right. |
|
I think there's a typo in the command. Try using lualatex rather than pdflatex. Here's a complete log (with system packages rather than docker, though): https://github.com/JasonGross/test-latex-errors/runs/4817894720?check_suite_focus=true |
|
I can reproduce the error. The tikz picture contains a reference and so tikz reschedules the compilation in the This rescheduled compilation also reads in auxiliary files. That is ok for the aux-file which has already been closed, but can be a problem for other auxiliary files. Not everyone is explicitly closed, often packages simply let the end of the compilation automatically close a file. Here it now breaks for the hyperref could probably do something like but this wouldn't resolve similar problems with other packages. Btw my test file is |
|
I can reproduce the problem locally on a latest texlive 2021 (installed on macOS), but with a condition contrast to what reported in borisveytsman/acmart#436 (comment)
In my case,
I can see that when the second system call halts, the \BOOKMARK [1][-]{section.7}{\376\377\0007\000\040\000X\000X\000X\000X\000X\000X\000\040\000X\000X\000X\000X}{
% in the form of
% \BOOKMARK[1][-]{...}{...and when the compilation ends, it completes to \BOOKMARK [1][-]{section.7}{\376\377\0007\000\040\000X\000X\000X\000X\000X\000X\000\040\000X\000X\000X\000X}{}% 21
% in the form of
% \BOOKMARK[1][-]{...}{...}{} % 21 |
So, would using the |
I don't think so. The problem is the same: files from the main compilations can still be open. If you look at the code in latex.ltx then you can see that the three hooks are more or less at the same place: |
|
According to tex.se, there doesn't seem to be a way to flush files without closing them. Would it make sense to add primitives to (lua)(pdf)(la)tex to flush files, and to ensure that bookmark writing is flushed, at least at these sort of hook boundaries? |
|
As a workaround specific for this use case, one can restrict the \tikzset{external/system call={%
pdflatex \tikzexternalcheckshellescape -halt-on-error-interaction=batchmode -jobname "\image"
"\string\PassOptionsToPackage{bookmarks=false}{hyperref}\texsource"}}It seems to work as far as the externalized tikzpicture envs have have nothing to do with the bookmarks. |
According to this source the workaround would fail if |
|
I am facing the same issue again for the Any ideas for a potential work-around/a generic solution ? Edit: |
Brief outline of the bug
Apparently, there are some edge-cases where
hyperrefwithbookmarks=trueandtikzexternalizeclash, leading to failed resolution ofrefsMinimal working example (MWE)
Consider the following MWE (thanks @JasonGross for producing this).
Compiling the above document with
docker run --rm -it --volume "`pwd`:/workdir" -w "/workdir" --user `id -u`:`id -g` registry.gitlab.com/islandoftex/images/texlive:TL2021-2022-01-09-04-05 pdflatex -shell-escape test.texfails, and the ref used inside the tikzpicture is never resolved.However, when providing
\PassOptionsToPackage{bookmarks=false}{hyperref}, and thereby disabling the bookmarks functionality, the code compiles just fine and the ref is resolved properly.Note that I also found the same clash to happen with
\documentclass{IEEEtran}, which is why I guess that it's an interaction related betweentikzandhyperref, rather than a problem with\documentclass{acmart}. Related package versions are,and full reproducibility should be given by the docker image.
Since I don't know the exact interactions which cause the issue and how to best resolve them, I have also crossposted the Issue to hyperref.
Best,
ORippler
The text was updated successfully, but these errors were encountered: