11

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.

xebtl
  • 632
  • 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. – Heiko Oberdiek Jun 10 '15 at 13:58
  • Any reason not to close this as duplicate? – Heiko Oberdiek Jun 10 '15 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 . – xebtl Jun 10 '15 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. – Heiko Oberdiek Jun 10 '15 at 15:36
  • @HeikoOberdiek: I see what you mean. Yet the second question is marked as a duplicate of the first. So the answer (to my question) is simply that there is no (“good”) solution? – xebtl Jun 10 '15 at 15:51
  • 1
    @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 ... – Heiko Oberdiek Jun 10 '15 at 16:51
  • @HeikoOberdiek All right. For now, other edits in my document have made the problem disappear. If it comes back, I may try some more to construct an MWE. Or would it help if I posted the output or the log file? Anyway, thanks for the answers (or, technically, comments ...) – xebtl Jun 11 '15 at 08:27
  • @xebtl Ok, then I can close as duplicate (but the question can still be edited and reopened). Best would be a good MWE, something that reproduces the error for analyzing and studying and that is as small as possible. – Heiko Oberdiek Jun 11 '15 at 08:34
  • @HeikoOberdiek I hit the problem again, and after a lot of fiddling I was able to narrow it down to the MWE above. Therefore I voted to reopen. – xebtl Jun 11 '15 at 10:31

3 Answers3

14

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
      \showboxbreadth=\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@additionalboxlevel
\setcounter{additionalboxlevel}{0}
\newcount\c@maxboxlevel
\setcounter{maxboxlevel}{1}
\patchcmd\@combinedblfloats{\box\@outputbox}{%
  \stepcounter{additionalboxlevel}%
  \box\@outputbox
}{}{\errmessage{\noexpand\@combinedblfloats could not be patched}}

\AtBeginShipout{%
  \ifnum\value{additionalboxlevel}>\value{maxboxlevel}%
    \typeout{Warning: maxboxlevel might be too small, increase to %
      \the\value{additionalboxlevel}%
    }%
  \fi 
  \@whilenum\value{additionalboxlevel}<\value{maxboxlevel}\do{%
    \typeout{* Additional boxing of page `\thepage'}%
    \setbox\AtBeginShipoutBox=\hbox{\copy\AtBeginShipoutBox}%
    \stepcounter{additionalboxlevel}%
  }%
  \setcounter{additionalboxlevel}{0}%
}
\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
Heiko Oberdiek
  • 271,626
1

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}
xebtl
  • 632
1

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

jjmerelo
  • 210