# [OS X TeX] Re: XeTeX and pdfpages: no dice?

Jonathan Kew jonathan_kew at sil.org
Sun Apr 15 10:07:07 EDT 2007

Hi Andreas,

On 15 Apr 2007, at 2:32 am, Andreas Matthias wrote:

> Here is a first beta version of pdfpages with a XeTeX driver file:
>
> http://stud4.tuwien.ac.at/~e9225580/pdfpages-v0.4b-beta1.tar.bz2

Many thanks for working on this. I haven't yet had a chance to look
at it myself, but I know users will be grateful.

> I am totally new to XeTeX (actually, yesterday I ran XeTeX for
> the first time), so I'm not sure I did things right. Especially
> the driver business of XeTeX puzzles me a bit. XeTeX has a built-in
> driver (any name for that?), which can output PDF directly; but
> then there also exist xdvipdfmx, which is actively developed as
> far as I can see. Why do I need xdvipdfmx and why is it not
> embedded into xetex?

OK, let me clarify a bit.

XeTeX has no built-in PDF generator or "driver"; the engine generates
an extended form of DVI (.xdv). However, the default behavior is to
pipe this directly to a default xdv-to-pdf driver, rather than
writing a file on disk. That's why it seems as though the default
output is PDF.

This provides two benefits over writing a .xdv file: (1) the .xdv is
not useful by itself, so it would usually just be extra "clutter" and
you'd have to run a driver anyway in order to do anything with it, so
we do this for you automatically; (2) using a pipe to send the output
to the driver allows the two processes to run in parallel, which
provides a substantial performance boost on multi-processor systems.

The -no-pdf option tells xetex to write an actual .xdv file instead
of piping output to a driver.

On Mac OS X, the default xdv-to-pdf driver is currently xdv2pdf, a
Mac-only tool (based heavily on several Apple technologies); on all
other platforms, the default (and only) driver is xdvipdfmx. So when
you run XeTeX on Linux, with no special options, you *are* actually
using the xdvipdfmx driver.

The -output-driver option allows you to change the driver command
that XeTeX will use for its output pipe. Currently, this is mainly
useful on Mac OS X, to use xdvipdfmx in place of xdv2pdf; it can also
be used if you want to pass special options to the driver, while
still running it via a pipe rather than creating an intermediate file
and then running it separately "by hand".

Hope that makes things a bit clearer!

>
> I seems to me that it is somehow possible to include PostScript
> files as well. I tried it with xetex -no-pdf' followed by
> xdvipdfmx but got the message No image converter available'...

This would depend on an option in dvipdfmx.cfg, the configuration
file for the (x)dvipdfmx driver. I think it's the "D" option that is
required; you can set this up to run ghostscript, for example, to
convert PS to PDF.

> I tested pdfpages by just calling the xetex binary directly; no
> options like -output-driver, -no-pdf and no external dvi->pdf
> converter. I am working on Linux if that matters;

As noted above, this means you were actually running the xdvipdfmx
driver behind the scenes.

> just heard
> of a xdv2pdf for MacOS -- one more driver business ... good lord.

Don't worry; if you're basing your work on the graphic[sx] package,
the xetex back-end for that makes use of the \XeTeXpdffile primitive
to include PDFs, and both drivers support that. So you wouldn't need
to do anything different in your package.

> To detect the number of pages of a PDF file, I used some really
> clever macro code that Heiko Oberdiek send me some years ago.
> I am not sure if it is really foolproof and it is not too fast,
> since it parses the whole PDF. But it is really wonderful to
> see what can be done on TeX macro level.

That's amazing! But I hope we'll have a better solution shortly.

> Oh, I nearly forgot that: Why do \pdfpagewidth and \pdfpageheight
> not have sensible defaults. Concerning pdftex these dimens are
> set in pdftexconfig.tex which is read when creating the format
> files. Wouldn't this be usefull for xetex as well?

It probably would. Currently, you will simply get the driver's
default page size, unless you use a -papersize option to change it,
or set these dimens yourself, or use a papersize \special.

Note that the PDF page size is entirely the responsibility of the
driver, and xetex itself doesn't have any way to read the driver's
default. However, if we set these dimens by default, then they'll
override the driver anyway; what they actually do (remember that
xetex isn't generating the PDF itself!) is to automatically insert a
papersize \special at the beginning of each \shipout, and then the
driver sees that and sets the page size accordingly.

> While working on pdfpages' XeTeX driver I came across a few
> things that I miss in XeTeX:
>
> * Detecting the number of pages of a PDF document.

Yes, this is on the to-do list and should appear sometime soon.

> * Clipping of graphics.

This is also something I'd like to do, but haven't had time to
investigate properly yet. Note that when placing PDF pages, you do
have the option to use any of the PDF rectangles (media, bleed, crop,
etc) from the source document. But we don't have support for
arbitrary clipping yet.

> * FitR destinations. The following is a pdftex example,
>   to show how FitR destinations work.
>
>   \documentclass[a4paper]{article}
>   \usepackage{hyperref}
>   \begin{document}
>   \newpage
>   \newbox\mm
>   \setbox\mm=\hbox{\rule{150mm}{150mm}}
>   \pdfdest name {foobar} fitr
>            width \the\wd\mm height0pt depth\the\ht\mm
>   \copy\mm
>   \end{document}
>
>   The closest I can come with XeTeX is
>   \special{pdf: dest (foobar) [ @thispage /XYZ @xpos @ypos 0]}
>   but that's definitely not the same.

This is driver-dependent; with xdvipdfmx, you have whatever features
were supported in dvipdfmx, as that's the basis of this driver. Maybe
we can enhance it, if the current support isn't enough.

Thanks again,

JK