[tex-live] beamer vs. hyperref

[Till Tantau]

Hello everyone,


hmm... I really hate this driver mess...

Anyway, I do not think that packages should use the *existence* of the  
pdfoutput counter for determining whether *xetex* is present. I know  
that beamer is not the only package that uses the define-pdfoutput-if- 
it-is-not-defined-strategy. Admittedly, this strategy is not perfect,  
but it does not seem so bad either.

I presume mankind really, really needs a central ultra-portable  
package for determining the backend driver...

I think the right way to discern the driver is, indeed, the one  
suggested in the mail, namely making hyperref smarter.


Best regards,
Till


Am 11.07.2008 um 22:30 schrieb Jonathan Kew:

> It has just come to my attention (though it may not actually be a  
> new issue) that beamer and hyperref don't get along perfectly when  
> used with xelatex.
>
> First, consider a simple test using the "article" class:
>
>  \documentclass{article}
>  \usepackage{hyperref}
>  \title{A Test}
>  \author{A. N. Author}
>  \begin{document}
>  \maketitle
>  \end{document}
>
> When this is run with xelatex, hyperref recognizes that it should  
> use a dvipdfm-style driver:
>
>  This is XeTeXk, Version 3.1415926-2.2-0.999.2 (Web2C 7.5.6)
>  .....
>  LaTeX2e <2005/12/01>
>  Babel <v3.8j> and hyphenation patterns for english, usenglishmax,  
> dumylang,
>  .....
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/base/article.cls
>  Document Class: article 2005/09/16 v1.4f Standard LaTeX document  
> class
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/base/ 
> size10.clo))
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/hyperref/ 
> hyperref.sty
>  .....
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/generic/oberdiek/ 
> ifpdf.sty)))
>  *hyperref using default driver hdvipdfm*
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/hyperref/ 
> hdvipdfm.def)
>  .....
>
> and the result is that hyperref features work as expected.
>
> However, changing the document class to "beamer" leads to a  
> surprising result:
>
>  This is XeTeXk, Version 3.1415926-2.2-0.999.2 (Web2C 7.5.6)
>  .....
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/beamer/ 
> beamer.cls
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/beamer/ 
> beamerbasercs.sty)
>  Document Class: beamer 2007/03/11 cvs version 3.07 A class for  
> typesetting pres
>  entations (rcs-revision 1.70)
>  .....
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/hyperref/ 
> hyperref.sty
>  .....
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/generic/oberdiek/ 
> ifpdf.sty))
>
>  Package hyperref Warning: Option `pdfpagelabels' is turned off
>  (hyperref)                because \thepage is undefined.
>
>  Hyperref stopped early
>  )
>  *hyperref using default driver hdvips*
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/hyperref/ 
> hdvips.def
>  (/Users/jonathan/texlive/Master/texmf-dist/tex/latex/hyperref/ 
> pdfmark.def))
>  .....
>
> Hyperref has chosen the dvips driver, with the result that xetex's  
> output driver xdvipdfmx generates a mass of warnings for all the  
> dvips-specific \specials that it doesn't recognize.
>
> So beamer is interfering with hyperref's attempt to choose the  
> appropriate driver by default, which otherwise works well. This  
> happens because beamer.cls actually defines a \count register  
> \pdfoutput, if the pdfTeX primitive is not present:
>
>  \ifx\pdfoutput\@undefined \newcount\pdfoutput \fi
>  \ifx\pdfoutput\relax \newcount\pdfoutput \fi
>
> (beamer.cls, lines 25-26.)
>
> I'm not sure what else in beamer depends on having defined  
> \pdfoutput; in a minimal test, removing these lines solves the  
> hyperref problem and the output looks fine. However, there are  
> probably many more implications that need to be considered.  
> Alternatively, it would be possible to revise the tests in  
> hyperref.sty to check for XeTeX before testing for the existence of  
> \pdfoutput, so that it is not "fooled" by beamer's tricks. In any  
> case, I suspect that defining \pdfoutput is a risky strategy, as it  
> may mislead other packages besides hyperref, so I hope that beamer  
> can be updated to eliminate this.
>
> In the meantime, I suggest that in TeX Live, we add a hyperref.cfg  
> file to the texmf-dist/tex/xelatex/xetexconfig/ directory, which  
> will check that it is running under xelatex and then define  
> \Hy at defaultdriver appropriately. Something like this:
>
>  \ProvidesFile{hyperref.cfg}%
>    [2008/07/11 v1.2 hyperref configuration for XeLaTeX]
>  \ifx\XeTeXversion\undefined \else
>    % Change default driver to "dvipdfm" instead of "hypertex",
>    % requires hyperref 2002/06/05 v6.72s
>    \providecommand*{\Hy at defaultdriver}{hdvipdfm}%
>  \fi
>  \endinput
>
> By placing this file in a tex/xelatex subtree, it will be found in  
> preference to the existing file under tex/latex *only* when running  
> under xelatex, and so other engines will not be affected.
>
> Unless there are objections (or better suggestions), I propose to  
> add this to the xetexconfig directory shortly.
>
> Comments welcome....  JK
>

--
Prof. Dr. Till Tantau <tantau at tcs.uni-luebeck.de>
http://www.tcs.uni-luebeck.de



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4780 bytes
Desc: not available
Url : http://tug.org/pipermail/tex-live/attachments/20080715/bbf3460e/attachment.bin