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

[Jonathan Kew]

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}
>   \hyperlink{foobar}{Kick me!}
>   \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