[XeTeX] xelatex and perltex: incompatibility?

[Scott Pakin]

Jonathan,

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.

Regards,
-- Scott