[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
More information about the XeTeX
mailing list