# Issues

Issue #238 resolved

# tableofcontents links to the next slide

oblique
created an issue

I have this bug also in the last version of beamer. Minimal example:

\documentclass{beamer}

\begin{document}
\frame{\tableofcontents}
\section{A}
\frame{A}
\section{B}
\frame{B1}
\frame{B2}
\end{document}


If I click at 'A' it goes to 'B1' (page 3) instead of page 2. I can reproduce this bug in Evince (not in fullscreen nor in presentation mode). The reason is that pdflatex creates a XYZ pdf link with parameters left = -28.346 (minus the width of page), top = 0, zoom = null. The top = 0 makes pdf readers to move to the next page, 'top' must be 'null' (0 is not 'null' in the pdf specifications) or the height of the page.

Pdf readers do the following calculation:

P = number of the target page
offset_y = calculate offset_y of page P
if (top is not null)
offset_y += height_of_page(P) - top
move to offset_y


So, the offset_y is actually the next page of our target because top is 0 in our case.

More info about XYZ links from PDF Reference 1.7:

[ page /XYZ left top zoom ]
Display the page designated by page, with the coordinates (left, top) posi-
tioned at the upper-left corner of the window and the contents of the page
magnified by the factor zoom. A null value for any of the parameters left, top,
or zoom specifies that the current value of that parameter is to be retained
unchanged. A zoom value of 0 has the same meaning as a null value.


Since, I'm newbie in Latex, I can not fix this bug, but I think it has to do with '\hyperlink' arguments.

# Comments (14)

I can't reproduce this: for me the PDF I produce is fine. Can you attach your .log and PDF files, and also details of which PDF viewers you've tried other than Evince? (beamer uses hyperref to set up most of this stuff, and that package is in general pretty reliable. Using one viewer on one platform you are always risking it being a viewer issue.)

1. reporter

I can reproduce it also with okular and I'm sure that is not a bug in pdf viewers (or in poppler library) because I have analyze the bug by checking the source codes of the programs, the .pdf file and the pdf standard. I think hyperref has a parameter for XYZ type of links.

2. This is a tricky one, as Evince seems to be the only viewer that shows the issue. I can understand the point about the spec, but I can't see where else beamer can place the line, as it has to be somewhere on the page. You can't typeset to 'null', so the spec seems to be strange to say the least. As this works in other viewers, and as beamer does not actually set the position (it just sets a zero-sized box at the start of the page), I'm saying WONTFIX here.

3. reporter
\documentclass{article}
\usepackage{hyperref}
\begin{document}
\hyperlink{page.2}{A}
\hyperlink{page.3}{B}
\hyperlink{page.4}{C}
\newpage
A
\newpage
B
\newpage
C
\end{document}


The above code is working without any problems, so I think is something incorrect in beamer.

• changed status to open

I'll take another look: as I say, my concern is that whatever the spec might say other viewers already handle the output correctly, and I don't want to break that.

4. reporter

this is how you can check if there are XYZ links with 0 top:

pdflatex a.tex
pdflatex a.tex
qpdf --qdf a.pdf - | grep -A2 XYZ | grep -B2 ' 0'


with the above commands I got 8 links that have 0 top.

I managed to decrease them from 8 to 4 by changing the following in beamer.cls file

\RequirePackage[implicit=false]{hyperref}


to

\RequirePackage{hyperref}


this is not the solution, but maybe a helpful info. also, this does not fix any links of toc.

I am having a similar problem with the navigation bar (the bullets on the top of some beamer themes link to the next slide). I noticed that the first time I generate the pdf (pdflatex) after having added/removed a section, the navigation links work fine. If I generate again the pdf with exactly the same source code, the navigation bullets link to the wrong page. I hope this information can help to identify the problem.

I've now traced the problem through carefully and have a pretty good idea what is wrong. The beamer class loads hyperref with implicit=false as beamer does it's own thing with a lot of LaTeX internals. However, that means that hyperref's mechanism for page links is never activated, and so Till wrote his own code to do this. The problem is that he did that as part of \@oddfoot rather than using the shipout box (which is what hyperref does). So a fix will be to copy-paste the hyperref code but for beamer's navigation links. That will take a little care: update perhaps later today or tomorrow.

5. Move page (navigation) links to shipout box (fixes #238)

The code here is now modelled on hyperref, which is loaded by beamer but not including the page links part. The links are now correctly positioned for selection by (hopefully) all viewers.

→ <<cset 974005d557bd>>

6. Log in to comment