Incorrect link location with notes on second screen

[Cimbali]

Using a simple setup for notes on second page, the link locations of the second page appear shifted onto the first page, as if their x coordinate was missing the width of the page:

I am compiling the following example:

\documentclass{beamer}
\usepackage{pgfpages}
\setbeameroption{show notes on second screen}
\setbeamertemplate{note page}{\insertnote}
\begin{document}
\begin{frame}{Foo}
Some content\
and a Test link: \url{http://www.google.com}
\note{\begin{itemize}
\item Other content
\item Test link: \url{http://www.google.com}
\end{itemize}}
\end{frame}
\end{document}

I am using pdflatex distributed by texlive which seems to be version 58.2* on OpenSuse Tumbleweed (rolling release) and have tried the latest pgf available in my repos (version 3.1.2*) as well as the current master (ee17ca5, used by setting TEXMFHOME to the git directory and confirming this path appears in the log file). These are the only warnings in the log:

[2

{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}pdfTeX warning (ext4): desti
nation with the same identifier (name{Navigation1}) has been already used, dupl
icate ignored

\pgfpages@shipoutshipoutbox ...physicalpagesizes }
                                                  \endgroup 
l.17 \end{document}
                   pdfTeX warning (ext4): destination with the same identifier 
(name{page.1}) has been already used, duplicate ignored

\pgfpages@shipoutshipoutbox ...physicalpagesizes }
                                                  \endgroup 
l.17 \end{document}
                   

]

This bug seems reproducible with okular 1.8.0, evince 3.32.0, and by accessing the link positions directly with Poppler (version 0.79.0, gobject introspection typelib 0.18), e.g. from a python script:

reading test.pdf...
page:  1 (width=725.669, height=272.126), link: x1= 92.257 x2=204.087 y1=233.050 y2=244.175
                                  relative pos: x1= 12.71% x2= 28.12% y1= 85.64% y2= 89.73%
                                   link target: None -> http://www.google.com
page:  1 (width=725.669, height=272.126), link: x1=170.168 x2=292.432 y1=140.617 y2=152.609
                                  relative pos: x1= 23.45% x2= 40.30% y1= 51.67% y2= 56.08%
                                   link target: None -> http://www.google.com
2 link(s) found

The first link should be at x1=454.257 x2=566.087 (or x1= 62.71% x2= 78.12%) to be correctly positioned.

Click to show the python script extracting link positions

#!/usr/bin/python3
import sys
import urllib.request
import os

import gi
gi.require_version('Poppler', '0.18')
from gi.repository import Poppler

for input_filename in sys.argv[1:]:
  print(f'reading {input_filename}...')
  document = Poppler.Document.new_from_file(f'file://{urllib.request.pathname2url(os.path.abspath(input_filename))}', None)

  n_pages = document.get_n_pages()
  all_links = 0

  for i in range(n_pages):
    page = document.get_page(i)
    size = page.get_size()
    for link in page.get_link_mapping():
      action = link.action
      if action.type == Poppler.ActionType.URI:
        all_links += 1
        print(f'page: {i + 1:2} {size}, link: x1={link.area.x1:7.3f} x2={link.area.x2:7.3f} y1={link.area.y1:7.3f} y2={link.area.y2:7.3f}')
        print(f'{" " * 34}relative pos: x1={100 * link.area.x1 / size.width:6.2f}% x2={100 * link.area.x2 / size.width:6.2f}%'
              + f' y1={100 * link.area.y1 / size.height:6.2f}% y2={100 * link.area.y2 / size.height:6.2f}%')
        print(f'{" " * 35}link target: {action.uri.title} -> {action.uri.uri}')


  print(f'{all_links} link(s) found')

According to the user who reported this bug to me (Cimbali/pympress#115), the links work fine using Acrobat Reader and Sumatra − presumably on Windows − which I can not confirm as I’m running a linux machine.

• Can this bug be reproduced by someone else using a Poppler-based pdf reader?
• Can this bug be reproduced using other pdf readers?
• Is it possible that Poppler, or maybe the way in which I use Poppler (see script above), is missing some information?
• Or alternately, is the link position for the notes page PDF incorrectly generated by pgf (missing a page width to the x coordinates) ?

* this is the output of the package manager from which I guessed the versions:

> zypper info texlive texlive-latex-bin-bin texlive-pgf
Information for package texlive:
--------------------------------
Repository     : openSUSE-Tumbleweed-Oss       
Name           : texlive                       
Version        : 2019.20190407-58.2            
Arch           : x86_64                        
Vendor         : openSUSE                      
Installed Size : 946 B                         
Installed      : Yes                           
Status         : up-to-date                    
Source package : texlive-2019.20190407-58.2.src
Summary        : The TeXLive Formatting System 


Information for package texlive-latex-bin-bin:
----------------------------------------------
Repository     : openSUSE-Tumbleweed-Oss       
Name           : texlive-latex-bin-bin         
Version        : 2019.20190407.svn14050-58.2   
Arch           : x86_64                        
Vendor         : openSUSE                      
Installed Size : 0 B                           
Installed      : Yes                           
Status         : up-to-date                    
Source package : texlive-2019.20190407-58.2.src
Summary        : Binary files of latex-bin     


Information for package texlive-pgf:
------------------------------------
Repository     : openSUSE-Tumbleweed-Oss                  
Name           : texlive-pgf                              
Version        : 2019.167.3.1.2svn50867-39.1              
Arch           : noarch                                   
Vendor         : openSUSE                                 
Installed Size : 4.5 MiB                                  
Installed      : Yes (automatically)                      
Status         : up-to-date                               
Source package : texlive-specs-r-2019-39.1.src            
Summary        : Create PostScript and PDF graphics in TeX


> pdflatex --version
pdfTeX 3.14159265-2.6-1.40.20 (TeX Live 2019/TeX Live for SUSE Linux)
kpathsea version 6.3.1
Copyright 2019 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.37; using libpng 1.6.37
Compiled with zlib 1.2.11; using zlib 1.2.11
Compiled with poppler version 0.79.0

[hmenke]

@josephwright

[hmenke]

BTW, you can also just add \hypersetup{pdfborder={0 0 1}} after \documentclass to display the link borders, rather than having to use a clumsy Python script.

[hmenke]

I have the feeling that this is not solvable, because the way pgfpages works is that it hooks into shipout and just shifts the shipout box to the right but at that point link positions have already been written into the PDF stream, i.e. their position is fixed. To get around this, one would have to rethink the beamer shipout routine.

[projekter]

This is an interesting and annoying issue that I also dealt with some years ago. The link is positioned incorrectly at the left. However, in Sumatra and Foxit, the is also a link on the right-hand side, which is not the case in Acrobat and Poppler-based readers. Still, this second link is only due to the fact that the reader auto-detects that there is a url and for the user's convenience turns it into a link; it is not because the document says so. I fixed some hyperref related issues before and will just give the patches here. They really hack into hyperref, not beamer or pgfpages, though they could probably be incorporated in the latter one. They are a couple of years old. Perhaps by now something else would be more appropriate - I didn't investigate too much.

duplicate identifiers

This was a warning by the PDF subsystem that you also observed in the log. hyperref inserts anchors for every page, but now it tries to insert those for both the left and right page - and since they are indexed by their physical page number, this is a duplicate. This probably will never harm, since you usually view beamer presentations in fit-page mode, so that the anchor is correct anyway, whether it points to the left or to the middle. But then, pgfpages is not made exclusively for beamer.

\usepackage{etoolbox}
\makeatletter
\newcount\pageanchored
\preto\Hy@EveryPageAnchor{%
   \ifnum\count\pageanchored<\c@page\relax% Don't insert twice
}
\appto\Hy@EveryPageAnchor{%
      \global\count\pageanchored=\c@page\relax%
   \fi%
}%

Extremely simple-minded: Keep the page number in a separate counter and keep hyperref from inserting duplicates. This could of course be extended to naming those duplicates differently instead of just dropping them.

wrong positioning of the links

This is what you actually asked for. Once again, a very simple-minded solution.

\AtBeginNote{%
   \let\hyper@link@\hyper@link@note%
}
\AtEndNote{%
   \let\hyper@link@\hyper@link@default%
}
\let\hyper@link@default\hyper@link@
\def\hyper@link@note[#1]#2#3#4{%
   \begingroup%
      \parbox[t][0pt][t]{0pt}{%
         \hfuzz=\maxdimen%
         \hspace*{\paperwidth}%
         \vbox{\hyper@link@default[{#1}]{#2}{#3}{\phantom{#4}}}%
      }%
      \color{blue}#4%
   \endgroup%
}

This is actually a hand-tailored solution specifically made for the layout with notes on the right-hand side. We replace the \hyper@link@ command by a wrapper (probably there is a better way for this, since \hyper@link@ performs some checks and might actually do nothing, in which case we also would not need to do somthing). Then, we insert a zero width box and suppress all overfull box warnings. We shift this box by the width of the left page to the right (which would in principle shift it out-of-page, but since the hyperlinks do not know about the first-hand shift, it is instead moved to the correct horizontal position). Here, we draw the hyperlink with correct box sizes, but without any actual content. After that and after all those shifts, we print the actual link content (once again, it would be nice to extract the link style from hyperref settings [subtracting all link boxes, which were already drawn, so really just the font settings] instead of hardcoding a blue color). But this may serve as a start.

[lrtfm]

Following @projekter's solution, I've created a patch file for this issue. Please see beamer-notes-patch.tex.