[XeTeX] xelatex and perltex: incompatibility?
scott at pakin.org
Sat Dec 15 00:04:54 CET 2007
On Sat, 8 Dec 2007 16:05:10 -0600, you wrote:
> The problem is that xetex assumes it can use fseek() on the input
> file to reset its position, and that fails with pipes. The assumption
> was that TeX input files, as processed with \input or \read, etc.,
> will be normal disk files.
> What happens when xetex opens an input file is that it reads the
> first few bytes from the file, in order to detect whether it is a
> UTF-16 (big- or little-endian) file, or has a UTF-8 "BOM" signature;
> if so, it will automatically set the appropriate encoding mode, and
> skip the BOM. But in the (common) case of a plain ASCII file (or
> UTF-8 with no BOM), it uses fseek() to reset the read position to the
> beginning of the file. That operation fails on pipes, and that's why
> you're losing the first two characters of \endinput.
> Modifying xetex to eliminate the use of fseek() would be possible,
> but it's a bit of a nuisance; it'll still need to peek at the initial
> two or three bytes of the file, and then buffer them if they turn out
> to be normal characters rather than an encoding signature. I'll
> consider this...
> Meanwhile, a rather hackish workaround would be for perltex to put a
> few leading spaces on the \endinput line that it writes. Then the
> fact that the initial bytes get lost won't actually affect the
> behavior, and leading spaces should be harmless to other engines.
Thanks for the explanation. I recently uploaded a new version of
PerlTeX that includes your "rather hackish workaround". Actually, I
used percent signs instead of spaces to avoid introducing unnecessary
spaces into the document in the non-xetex case.
More information about the XeTeX