[XeTeX] pdfpages?

Mojca Miklavec mojca.miklavec.lists at gmail.com
Fri Nov 2 19:04:15 CET 2007


On 11/2/07, Andreas Matthias wrote:
> Mojca Miklavec wrote:
>
> > Does adding this line
> >     \def\pgfsysdriver{pgfsys-dvipdfm.def}
> > at the top of your document help?
>
> Yes, that's one way to do it. But I think there should be another.
>
> The problem is that both tikz and pdfpages try to load graphics.sty.
> Tikz wants to get the dvipdfm driver (specified by the documentclass
> option), whereas pdfpages needs the xetex driver. As I understand
> it dvipdfm.def is a subset of xetex.def, so it should not hurt
> to load xetex.def instead of dvipdfm.def when running XeTeX.
> Is that correct?

Dvipdfm is not really a subset of XeTeX, perhaps a subset of
xdvipdfmx, which is one of two possible ways to compile a document
with XeTeX (and the only one which works with TikZ; the other one,
xdv2pdf, cannot be used with TikZ anyway).

But sure - your idea is OK - you can create pgfsys-xetex.def and put
"\input pgfsys-dvipdfm.def" into it or simply copy that file to
pgfsys-xetex.def (if done that way you won't need the additional line
in your source, so it might indeed be a more elegant solution).

> Without specifying a driver as a documentclass option tikz tries to
> load pgfsys-xetex.def which doesn't exist. But if dvipdfm.def is a
> true subset of xetex.def then it shouldn't hurt to copy pgfsys-dvipdfm.def
> to pgfsys-xetex.def. And simple tests did work.
> Any objections?

Objections to what? I believe that your solution works nice, so if it
fixes the problem - why not using it? (If you're talking about fixing
TikZ, that has been done already. Your proposal might indeed be
slightly more clean than the current solution. Personally, I don't
really care which one is used as long as it works.)

Mojca


More information about the XeTeX mailing list