# [XeTeX] geometry.sty FIX for XeTeX 0.994

Jonathan Kew jonathan_kew at sil.org
Wed Jun 7 13:17:11 CEST 2006

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