9

I'm having an odd problem---it seems like XeLaTeX isn't working so well with beamer. I'm using MacTex 2011 and have updated to the latest packages using the TexLive utility.

The problem is that compiling with XeLaTeX prevents me from using the \setbeamertemplate command more than once.

As an example, I would like to have two slides with different backgrounds, say one with a blue gradient and the next with a red gradient. See the following sample code:

\documentclass[12 pt]{beamer}

\begin{document}


\setbeamertemplate{background canvas}[vertical shading][bottom=blue!30, top=white]

\begin{frame}[t]\frametitle{This should have a blue gradient}
    Since this is the first instance of \texttt{setbeamertemplate}, it works properly.
\end{frame}  

\setbeamertemplate{background canvas}[vertical shading][bottom=red!30, top=white]

\begin{frame}[t]\frametitle{This should have a red gradient}
    However, if \texttt{XeLaTeX} is run, this will still show as blue.
\end{frame}

\end{document}

If I compile with PdfLaTeX, then this works as hoped. However, if I compile with XeLaTeX, then BOTH slides have blue gradient backgrounds. The second \setbeamertemplate{background canvas} call is ignored.

Does anyone have any suggestions for this or an explanation for what's happening?

Caramdir
  • 89,023
  • 26
  • 255
  • 291
Flip
  • 527

2 Answers2

7

This seems to be a problem with the pgfsysdriver-xetex definition. If you put

\def\pgfsysdriver{pgfsys-dvipdfmx.def}

before the \documentclass line, you get the correct output on the MWE.

I offer no guarantees on whether or not this will break other things, however. One thing that will not work is anything involving TikZ/pgf remember picture. There may be other things that don't work that I'm unaware of.

If you do encounter problems, another workaround is to compile using lualatex instead of xelatex.

Alan Munn
  • 218,180
  • Thanks! It looks like that fixed the problem and doesn't seem to have broken anything else in a more complicated example. Just a remark if anyone else is doing this: for the more complicated example I had trash the old auxiliary files when recompiling. – Flip Sep 26 '11 at 01:25
  • Okay, one thing broke: the arrows in this example get lost and seem to no longer be able to find their node: [link] (http://www.texample.net/tikz/examples/beamer-arrows/)

    (I have a MWE, but it's too big to fit into a comment---what is the proper Stack Exchange etiquette for this?)

     – Flip Sep 26 '11 at 02:22
  • @Flip Yes, I was worried that certain things would break. The link is fine. Unfortunately this shows that my solution isn't very robust (as I suspected). Is there some independent reason you can't compile with lualatex? – Alan Munn Sep 26 '11 at 02:41
  • @Flip The solution I used loads the driver for for dvipdfmx whereas XeLaTeX uses xdvipdfmx, a related, though different driver, but there is as yet, no pgfsys- equivalent. – Alan Munn Sep 26 '11 at 02:47
  • Thanks for explaining a bit about how your solution works. I'm not so familiar with lualatex, but when I tried to compile it didn't recognize Gill Sans as a font. (It seems that lualatex doesn't work with TTC fonts?) – Flip Sep 26 '11 at 02:52
  • @Flip There was an error of that sort, but I thought it had been fixed, but maybe not. Unfortunately, the most recent TeX Live update (9/25) just broke a whole bunch of things so that this example no longer worked at all. So updating at this instant in time just makes things worse. – Alan Munn Sep 26 '11 at 03:15
  • Thanks for pointing this out... unfortunately I'd just updated to the most recent TeX Live distribution while trying to sort all of this out! :-) Do you know what the usual time scale is for these kinks to get worked out? (Days, weeks, months?) What's the best way to know when it's safe to update again (and have Gill Sans working again)? (Sorry for turning this into a long discussion---we can move this into a chat, but I don't have enough reputation to do this myself yet.) – Flip Sep 26 '11 at 03:44
  • @Flip, sorry to hear that. I was a bit amazed myself. I suspect the time scale for fixing this will be days, not weeks or months. – Alan Munn Sep 26 '11 at 04:29
3

Instead of loading with xelatex the complete pgfsys-dvipdfmx.def you could try to load only the needed definitions. E.g. for your vertical shading it seems to be enough to define a counter and copy the definition of \pgfsys@vertshading:

\documentclass[12 pt]{beamer}

\makeatletter
\newcount\pgfsys@objnum\pgfsys@objnum\@ne

\def\pgfsys@vertshading#1#2#3{%
  {%
    \pgf@parsefunc{#3}%
    \pgfmathparse{#2}%
    \pgf@process{\pgfpoint{\pgf@max}{#2}}%
    \edef\@tempa{\noexpand\pgfutil@insertatbegincurrentpagefrombox{%
      \special{pdf:bxobj @pgfshade\the\pgfsys@objnum\space width \pgfmathresult pt\space height \the\pgf@max}%
      \special{pdf:put @resources
      <<
        /Shading << /Sh << /ShadingType 2
        /ColorSpace /DeviceRGB
        /Domain [\pgf@pdfparseddomain]
        /Coords [0 \pgf@doma\space0 \pgf@domb]
        /Function \pgf@pdfparsedfunction
        /Extend [false false] >> >>
      >>}%
      \pgfsys@invoke{/Sh sh}%
      \special{pdf:exobj}}}\@tempa% <<
    \expandafter\xdef\csname @pgfshading#1!\endcsname{%
      \hbox to\pgfmathresult pt{\vbox to\the\pgf@max{\vfil\special{pdf:uxobj @pgfshade\the\pgfsys@objnum}}\hfil}}%
  }%
  \global\advance\pgfsys@objnum\@ne%
}
\makeatother

....

But what is really missing is someone who can and is willing to sort out the xetex driver files. Most things currently missing (e.g. clipping of graphics) could work if the driver files were updated.

Ulrike Fischer
  • 327,261