[XeTeX] ifxetex package

[Ross Moore]

Hi Will,

On 19/06/2006, at 6:34 PM, Will Robertson wrote:

> Ah, I see how you meant now. Maybe it would be good to add a couple of
> features like this to the ifxetex package. There could be something
> like
>   \def\endunlessxetex{\unless\ifxetex\expandafter\endinput\fi}
>
> (At uni, therefore untested. Not sure if that \expandafter is
> required, but it seemed like the right thing to do at the time to keep
> things tidy even if it doesn't make a difference in execution.)

Yes it is, else the conditional never gets closed after the \endinput .

It doesn't actually prevent anything in subsequent processing, but
you'll get a log-message at the end of the job warning that an \ifx
wasn't closed. In fact, if the package is attempted to be loaded
several times, then there'll be one such warning for each time
the package-file is read and exited.
Mostly this is just a nuisance, but it does use up some resources.



> An
> optional argument to write a message would also be a good idea.
>
>> This then allows an author to write documents that can
>> be compiled with different processors, allowing blocks:
>>
>> \ifxetex ... \else ... \fi
>>
>> to do the correct thing according to the typesetting
>> engine; e.g., employ different font-loading mechanisms.
>
> Yes, this sort of feature is more useful for document writers.

I used to frequently write documents that were to be processed
into .ps  and .html  and .pdf .
Use of such conditionals is an integral part of the preamble,
hence of specialised packages that I'd write to handle such
technicalities.


>
>> Surely the purpose is more for when XeTeX is *not* the engine
>> --- hence it may not be e-TeX based either ---
>> than for when it *is* the engine.
>
> Yes, it's for error checking and conditionals when XeTeX ain't being 
> used.
> However, bearing that in mind I *still* think that any engine running
> this package will still have eTeX extensions -- I mean, sure, it's
> possible that someone will be using Knuth's TeX, but I think the
> chances are fairly small.

Umm, how about the following engines:

    tex4ht ,  lacheck ,  LaTeX2HTML ,  Omega , Lambda , Aleph
    lamed , hyperlatex , t4ht
(not sure about the 1st and last.)
    and  texi2dvi ,  texi2html ,  etc.



>
> It's a bit of a philosophical problem: what's the point in these nice
> eTeX extensions if they're never used for backwards compatibility
> concerns? Still, I'd be willing to change my mind since this is a
> fairly extreme case.

Sure they can be used inside packages, once you know that the
engine supports them. This is fine for package-writers and advanced
users who have full control over their own large projects.

The purpose of packages such as  ifpdf ,  ifvtex , and now  ifxetex ,
is to provide a standardised way of finding out what *is* the engine,
so that appropriate customisations can then be made.


As a guiding principle, ideally (low-level) primitives should never
appear within a document, especially not within the body.
(Of course we all break this rule sometimes;  besides, (La)TeX
  doesn't make it clear what is primitive and what is a macro.)

>
> Regards,
>
> Will
>

Cheers,

	Ross