# ‘\pdfendlink ended up in different nesting level than \pdfstartlink’ error with current version of hyperref

I am experiencing the hyperref split-link issue described in previous questions. I tried to update the hyperref package as recommended as well as the oberdiek package which also seems to have some hyperref-related files.

My hyperref.sty is now at v6.83m, hobsub-hyperref.sty at v1.13. The MWE in @Michael's question compiles without problems, but my document still generates the same error. My documentclass is elsarticle (version 1.2.0).

The following suffices to produce the problem:

\documentclass[5p]{elsarticle}

\usepackage{kantlipsum}
\usepackage{hyperref}

\begin{document}

\begin{frontmatter}
\end{frontmatter}

\kant*[1-4]
\kant[5]
\href{http://tex.stackexchange.com}{This is a very very
very very very very very very very very very very very very very
very very very very very very very very long link.}
\end{document}


Both the 5p option and frontmatter seem to be required, though the latter may be empty.

• The heuristics for detecting the correct link, which are broken across pages fails sometimes in pdfTeX. A warning would be nicer than an error message. Workaround is to avoid the page break inside the link. Jun 10, 2015 at 13:58
• Any reason not to close this as duplicate? Jun 10, 2015 at 14:01
• @HeikoOberdiek I tried to explain in the question why editing to avoid the page break is not the solution I am looking for: essentially, because it happens in the references which are generate automatically by biblatex. I also tried to explain why I think this is not a duplicate of the linked questions: there, updating hyperref is presented as the solution, but that did not work for me. If I am being unclear, please tell me . Jun 10, 2015 at 15:05
• @xebtl Only the second question with the MWE could be solved by updating, but not the first question. Also a good MWE is missing. For the common case, the first question is good enough. At least it contains some workaround hints in the answers. Jun 10, 2015 at 15:36
• @xebtl More or less yes. Another workaround would be to add some box levels around the output page of some pages to change the "nesting levels", but this is also only a workaround that require experiments and a good simple MWE to show the procedure. Also the real cause for the error in your case is quite unclear because of the missing MWE. There might be a different box level in the first and second page caused by hyperref, but AFAIK not between the following pages. There are also other packages, which might change this level ... Jun 10, 2015 at 16:51

The MWE is a good starting point. From there I could simplify it further. frontmatter sets the title in the optional argument of \twocolumn. Thus \twocolumn[] is sufficient. The text can be replaced by vertical spaces. The class can be replaced by the standard article class.

MWE:

\documentclass{article}

\usepackage{hyperref}

\begin{document}
\twocolumn[]

\null\vfill\newpage
\null\kern.95\textheight

\href{http://tex.stackexchange.com}{This is a very very
very very very very very very very very very very very very very
very very very very very very very very long link.}
\end{document}


If \twocolumn is called with the optional argument, then macro \@topnewpage is called, which puts the stuff of the optional argument in a double column float object for the top of the page. Thus also the following triggers the problem instead of \twocolumn[]:

\twocolumn
\begin{figure*}\end{figure*}


At some later time in the output routine, macro \@combinedblfloats combines the top double float object with the normal page contents:

\setbox\@outputbox \vbox to\textheight{%
\unvbox\@tempboxa
\vskip-\dblfloatsep
\ifnum \@dbltopnum>\m@ne
\dblfigrule
\fi
\vskip \dbltextfloatsep
\box\@outputbox
}%


As can be seen, \@outputbox is boxed again in an additional \vbox. Thus the box level of the first part of the link is higher by one in comparison to the second page without the double float object.

The following workaround increases the boxing level except for the first page:

\documentclass{article}

\usepackage{hyperref}

\AtBeginShipout{%
\ifnum\value{page}>1 %
\typeout{* Additional boxing of page \thepage'}%
\setbox\AtBeginShipoutBox=\hbox{\copy\AtBeginShipoutBox}%
\fi
}

\begin{document}
\twocolumn[]

\null\vfill\newpage
\null\kern.95\textheight

\href{http://tex.stackexchange.com}{This is a very very
very very very very very very very very very very very very very
very very very very very very very very long link.}
\end{document}


The workaround also works with the original MWE of the question. In real documents, it is not trivial to know, which pages would need how many additional box levels.

A manual way would be using the following snippet, the first two lines quite early, even before \documentclass, the remaining part should be executed late, here via \AtBeginDocument.

\RequirePackage{atbegshi}
\AtBeginShipoutInit

\AtBeginDocument{%
\AtBeginShipout{%
\begingroup
\showboxdepth=\maxdimen
\tracingonline=1 %
\edef\restoreinteractionmode{\interactionmode=\the\interactionmode}%
\nonstopmode
\showbox\AtBeginShipoutBox
\restoreinteractionmode
\endgroup
}%
}


Then the box listings of the output pages can be analyzed to identify the start part of the link and the end part on the next page. Then the number of dots at the line starts need to be compared.

The next example tries a more automatic solution:

\documentclass[5p]{elsarticle}

\usepackage{kantlipsum}
\usepackage{hyperref}

\usepackage{etoolbox}
\makeatletter
\newcount\c@maxboxlevel
\setcounter{maxboxlevel}{1}
\patchcmd\@combinedblfloats{\box\@outputbox}{%
\box\@outputbox
}{}{\errmessage{\noexpand\@combinedblfloats could not be patched}}

\AtBeginShipout{%
\typeout{Warning: maxboxlevel might be too small, increase to %
}%
\fi
\typeout{* Additional boxing of page \thepage'}%
\setbox\AtBeginShipoutBox=\hbox{\copy\AtBeginShipoutBox}%
}%
}
\makeatother

\begin{document}

\begin{frontmatter}
\end{frontmatter}

\kant*[1-4]
\kant[5]
\href{http://tex.stackexchange.com}{This is a very very
very very very very very very very very very very very very very
very very very very very very very very long link.}
\end{document}


Maybe this issue could also be fixed by replacing \box\@outputbox by \unvbox\@outputbox in macro \@combinedblfloats (maybe the vertical glue assignments might change):

\usepackage{etoolbox}
\makeatletter
\patchcmd\@combinedblfloats{\box\@outputbox}{\unvbox\@outputbox}{}{%
\errmessage{\noexpand\@combinedblfloats could not be patched}%
}%
\makeatother


This is really more a response to @HeikoOberdiek's knowledgeable answer, but it is unsuited for a comment.

First, I tried two of your proposed workarounds, the "more automatic solution" and the redefinition of \@combinedblfloats. The former did not work for me (I got a couple of * Additional boxing messages, but the error still happened), but the latter did. So thank you again!

Second, in the mean time I made a change in my document that made the error go away. I have some floats that used to have a [!hbt] placement modifier which I removed. Now they are being placed on float pages, and it seems that links after these pages are not affected. Here is a MWE for that:

\documentclass[5p]{elsarticle}

\usepackage{hyperref}

\begin{document}

\begin{frontmatter}
\end{frontmatter}

\null\vfill\newpage
\null\kern.95\textheight

\begin{figure*}[p]
\rule{1pt}{.9\textheight}
\caption{A figure.}
\end{figure*}

\null\vfill\newpage
\null\kern.95\textheight

\href{http://tex.stackexchange.com}{This is a very very
very very very very very very very very very very very very very
very very very very very very very very long link.}

\end{document}

• Removing the [tb] from all algorithm environments solved the problem for me too. Jan 17, 2021 at 20:48

As indicated in this old post, you have to indicate hyperref it can break links:  \usepackage[breaklinks=true]{hyperref}  This works in the latest version of hyperref, 6.83m and also fixes the problem of not including \refs or giving errors every second running of pdflatex

• This has no effect for me at least. May 9, 2017 at 17:27