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}


\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.

\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.


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?

  • Welcome to TeX.sx! A tip: You can use backticks ` to mark your inline code as I did in my edit. – Joseph Wright Sep 25 '11 at 18:53
  • 2
    I get the 'correct' behaviour with pdfLaTeX (no fontspec) and LuaLaTeX (with or without fontspec), but get the odd behaviour with XeLaTeX with or without fontspec. So this looks more like something to do with the engine than fontspec. Does this match what you see? – Joseph Wright Sep 25 '11 at 18:57
  • Hi Joseph, thanks for the tip inline code tip. I agree with you: XeLaTeX without fontspec also doesn't give the correct behavior, so it seems to be a XeLaTex issue not a fontspec issue. Should I edit the post accordingly? – Flip Sep 25 '11 at 19:03
  • yes you should. If you use the @⟨name⟩ syntax (like @Joseph) then people will get notified of your response. – Caramdir Sep 25 '11 at 19:06
  • Not directly relevant to solving this problem, but I wonder if this problem is connected to: How do I get fontspec to work with text color white in XeLaTeX – Alan Munn Sep 25 '11 at 19:09

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


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.

| improve this answer | |
  • 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 1:25
  • Okay, one thing broke: the arrows in this example get lost and seem to no longer be able to find their node: [link] (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 2: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 2: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 2: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 2:52

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}


      \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}}%


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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.