# [tex-live] Bad .cfg files in TeX source tree?

Jonathan Kew jonathan_kew at sil.org
Fri Jan 19 21:06:50 CET 2007

On 19 Jan 2007, at 3:00 pm, Heiko Oberdiek wrote:

> On Fri, Jan 19, 2007 at 02:00:31PM +0000, Jonathan Kew wrote:
>
>> Packages like this that test the engine and configure their back-end
>> accordingly need to be updated to support xetex; in many cases, this
>> will just mean checking for the xetex engine (e.g. using ifxetex.sty)
>> and activating the same code as for pdftex. I haven't had time to
>> pursue this with all the package maintainers, though (and until xetex
>> became part of mainstream distributions, the incentive to support it
>> in standard packages wasn't so strong, either).
>
> But TeX Live is a mainstream distribution, isn't it?

Indeed, and so I hope that support will now become much better
organized and integrated.

>
>> The .cfg files in the xelatex tree were created as a workaround to
>> get xetex-unaware packages to use the right (pdftex-like) back-end;
>
> Then at least try finding another workaround.
> Otherwise there will be lots of bug reports, eg.:

In practice, this may not be as likely as you'd think:

> \documentclass{article}
> \usepackage{geometry}
> \usepackage{hyperref}% assumes now that pdfTeX is running in PDF mode

...except that there's a hyperref.cfg in the xelatex subtree, which
overrides this and chooses the right back-end for xetex. :)

> \usepackage{ifpdf}% same assumption

Yes, this would be "fooled" by the hack... but whether that's a good
thing or a bad thing depends what use people (users or package
authors) are making of the conditional. Wherever it seems to make
sense, given the different processing models, xetex tries to be
compatible with pdftex (hence the \pdfpage{height|width} parameters,
for example). So in some cases the best results come from
"pretending" to packages that it *is* pdftex -- until the packages
are specifically aware of xetex itself.

> \ifpdf
>   ...% this would be executed
> \else
>   ...
> \fi
> \begin{document}
> \end{document}
>
> But the best solution is, if the packages can be updated.

Of course.

>> If we can add a test for xetex, and the appropriate driver setup,
>> into standard "global" cfg files for these packages, that would be
>> preferable.
>
> I have done so for color.cfg and graphics.cfg and updated
> hyperref.

Great, thank you.

>
>> Then the ones in the xelatex subtree could be removed.
>
> Yes, color.cfg, graphics.cfg, and hyperref.cfg can be removed there.

With pleasure -- I'll try to take a look at this over the weekend (if
no-one else cleans up first!).

JK