[XeTeX] geometry.sty FIX for XeTeX 0.994

[Jonathan Kew]

I think there's actually a very simple fix for the geometry.sty issue  
people have encountered. Just replace ..../tex/xelatex/geometry.cfg  
with this version:

- - - - - - - - - - cut here - - - - - - - - -
%% geometry.cfg for XeLaTeX - JK 2006-06-07

%% Use the "pdftex" driver (i.e., \pdfpagewidth, \pdfpageheight) with  
XeTeX
\Gm at setdriver{pdftex}

%% make geometry.sty believe this is valid
\ifx\pdfoutput\@undefined
   \newcount\pdfoutput \pdfoutput=1
\fi

\endinput

%% End of file `geometry.cfg'.
- - - - - - - - - - cut here - - - - - - - - -

This convinces the package that it's OK to use the pdfTeX-style  
primitives for page size, which is more robust than using the dvipdfm/ 
dvips-style \AtBeginDvi{\special{papersize....}} approach.

A similar option can be used with the crop.sty package, too:

- - - - - - - - - - cut here - - - - - - - - -
% crop.cfg for xetex - JK - 2006-06-07
% This attempts to persuade crop.sty to work with xetex

%% Use the "pdftex" driver (i.e., \pdfpagewidth, \pdfpageheight) with  
XeTeX
\def\CROP at reqdriver{pdftex}

%% make crop.sty believe this is valid
\ifx\pdfoutput\@undefined
   \newcount\pdfoutput \pdfoutput=1
\fi

\endinput

%% End of file `crop.cfg'.
- - - - - - - - - - cut here - - - - - - - - -

The one risk of this approach is that it's possible other packages  
will see the "fake" \pdfoutput setting, and then try to use other  
pdfTeX extensions that aren't present in xetex. graphics.cfg and  
color.cfg are set up so that their detection of xetex overrides  
detection of pdftex, but others may stumble over this.

JK