# Issues

Issue #136 resolved

Anonymous created an issue

Hi,

When building a presentation with pdflatex, the navigation buttons in the default theme (in the bottom right hand corner, for moving between frames / framesets and so on) work fine: it is possible to go forwards and backwards between overlays, frames and sections. Building with luatex also works.

However, when building with xelatex (which I want to do for its support of OpenType fonts and Unicode), the buttons are not active; the mouse cursor doesn't change when it hovers over the buttons, and clicking merely goes forward one slide (as a click does anywhere in the pdf viewer). Other links do work: for example section links in the outer "sidebar" theme are active and function as expected.

I've tried tracking down the problem myself but have gotten lost in the tower of files -- and I don't really know how to debug TeX in any kind of efficient way. I'm willing to help as much as I can to help isolate and fix the problem.

Thanks,

Christophe (csr21@cantab.net)

Hi,

I've put some time into this and figured out what the problem is. Apparently, in XeLaTeX links with an empty body disappear, whereas in pdfLaTeX they don't.

Here is a minimal example, using the package hyperref, that illustrates the problem:

\documentclass{article}
\usepackage{hyperref}

\begin{document}

% link that works in both pdfLaTeX and XeLaTeX:

% link that works in pdfLaTeX but not in XeLaTeX (for lack of a clickable body):

\clearpage
\hypertarget{mytarget}{Welcome to page 2!}

\end{document}


In beamerbasenavigation.sty, the navigation symbols are drawn and links are made by creating a link (with a body of empty space) over them. The command to create the empty space is \beamer@linkspace. You can see the drawing of the symbols and the overlaying of empty links for example in the definition of \insertslidenavigationsymbol.

I suppose this is really a XeLaTeX bug (or 'feature') rather than a Beamer one, although the way in which Beamer overlays empty links on pgfpictures is a bit weird. Fixing this bug will, I think, require quite some rewriting of beamerbasenavigation.sty (possibly in combination with ifxetex, to retain functionality for other TeX's), to make proper image links. Or perhaps someone can find a cleverer fix than the extremely dirty one I came up with:

• redefine \beamer@linkspace to include actual characters (I couldn't get XeLaTeX to accept empty space in the form of a phantom or even a \hrulefill or framed empty space) in Beamer's background color, for instance like this:
\def\beamer@linkspace#1{\raisebox{2pt}[-2pt][5.5pt]{\hbox to#1{\color{\beamer@thc@gbg}\textbar \textbar}}}

• alter the definitions like \insertslidenavigationsymbol so that the pgfpicture overlays the link, so that you don't actually see the characters appear as vertical stripes through the symbols:
\def\insertslidenavigationsymbol{%
\begin{pgfpicture}{0pt}{-1.5pt}{20pt}{5.5pt}
\pgfuseobject{beamerslidenavstrong}%
\pgfuseobject{beamerslidenavlight}%
\end{pgfpicture}}


Personally, I do hope the maintainers of Beamer decide to properly fix this nuisance. This particular bug (and #117) are really the only problems I have with Beamer (a package that I love and highly appreciate), but they are quite substantial problems.

Rob

Hello again,

In XeLaTeX, the active area of a hyperlink seems to be the smallest rectangle that still contains all the actual text (and only the text!) that was in the hyperlink argument.

Unfortunately, I couldn't find any functionality in the hyperref package for making image links (perhaps that would have worked nicely in XeLaTeX). Anyway, based on the aforementioned observation, I've come up with a cleaner workaround than the one I presented earlier. Redefine \beamer@linkspace to be:

\def\beamer@linkspace#1{%
\begin{pgfpicture}{0pt}{0pt}{#1}{7pt}% setting up pgf picture dimensions (for pdfLaTeX)
\pgfsetfillopacity{0}% complete transparency from this point on
\pgftext[base,left,at=\pgfpoint{0pt}{-1.5pt}]{.} % put a dot in the lower left corner (kinda)
\pgftext[base,right,at=\pgfpoint{#1}{7pt}]{.} % put a dot in the upper right corner (kinda)
\end{pgfpicture}%
}


In effect, this draws a tiny picture, which is completely transparent, with a dot (period) in the lower left corner and a dot in the upper right corner. XeLaTeX will use the rectangle defined by these two dots as the active area of the hyperlink.

You can redefine this command in the preamble (after all Beamer related stuff), provided that you enclose it between the commands \makeatletter and \makeatother (so TeX doesn't stumble on the @). If you want, you can use the ifxetex package to only redefine it when you're actually compiling with Xe(La)TeX.

Rob

PS. In the code above, the string made up of the characters [hash symbol] and [1], to denote the first argument, might have been replaced by #1 (as it was in my previous post).

PPS. For a real solution: XeLaTeX seems to be better at finding the actual bounding box when the body of the hyperlink is a pdf-image, included with the \pgfimage command. I could not recreate this effect on a pgfpicture by setting bounding boxes, or clipping areas, but someone with more knowledge of pgf might be able to.

<<issue-1>> should be #-1 (remove hyphens)

FYI, I just noticed that my workaround can increase the file size significantly.

Rob

(I am the original reporter in this bug tracking system)

Rob,

Thank you very much for the work you put in to isolate the problem. (I have to say, I find the way that this bug tracker replaces #1 with <<issue-1>> hilarious -- and of course this comment will probably get munged too... :-)

I found that the workaround in your post of 2011-08-20 generated a number of box warnings; changing the pgfpicture dimensions so that the lower y bound was -1.5pt made the warnings go away. I didn't notice a particular increase in file size as a result.

Thanks too to Joseph for taking this on; again, do let me know if there's any testing I can do to help.

Christophe (csr21@cantab.net)

In fact, this issue is also for DVIPDFMx.

Jin-Hwan Cho, the author of DVIPDFMx, has been described this problem in a TUGboat article:

http://www.tug.org/TUGboat/tb30-1/tb94complete.pdf

In Cho's article, he advised to use \special{pdf:ann ...} instead of \special{pdf:bann ...} and \special{pdf:eann ...}. Anyway, it need to change the hyperref package and it is too complex.

I suggest the solution which use text instead of empty box to define \beamer@linkspace, just like Rob do. The code I used is much the same as Rob's:

\def\beamer@linkspace#1{%
\begin{pgfpicture}{0pt}{-1.5pt}{#1}{5.5pt}
\pgfsetfillopacity{0}
\pgftext[x=0pt,y=-1.5pt]{.}
\pgftext[x=#1,y=5.5pt]{.}
\end{pgfpicture}}


That's all stuff. I used this since last summer. I hope it will be fixed soon.

Leo Liu (leoliu.pku at gmail)

1. Draw 'real' content for empty linkes with XeTeX (fixes issue #136)

In an ideal world, this would be fixed in the driver or hyperref code. However, that seems unlikely so a patch at the beamer end is the best that can be achived.