LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Will Robertson <[log in to unmask]>
Tue, 17 Mar 2009 11:53:07 +1030
text/plain (2527 bytes) , smime.p7s (2446 bytes)
(Karl replied off-list with some other stuff as well; I'm replying to  
the pertinent bits on-list)

On 17/03/2009, at 10:48 AM, Karl Berry wrote:

>    reliably detect or branch based on \input
> I don't understand what this means.  Do we need to extend the  
> engines in
> some way?

LuaTeX can handle things just fine, since it can add a callback to the  
file loading routine. The problem is that XeTeX always writes in UTF8  
(having discussed with Jonathan the possibility of an output write  
encoding, always using UTF8 is the more sensible way to do it).

When reading files in LaTeX, there are two possibilities:
   1. It's an external file, like a section or chapter; this has to  
follow the input encoding of the main file
   2. It's an auto-generated file being read in a second compilation;  
this has to be read in UTF8

The idea of xetex-inputenc is to set up the default encoding for the  
main file and all subsequent files; it then has to detect when auto- 
generated files (like .aux) are being read and insert the code to  
temporarily switch back to UTF8.

This is what I do (and it works well, seemingly) for \@input, which is  
used by the kernel for reading in auxiliary files that aren't added to  
the \listfiles list. If only every package used that macro. Many  
packages use \input instead, which is the problem, because LaTeX  
redefines \input to *either* behave like the TeX primitive *or* to  
take a braced argument. So some packages write "\input foo" and others  
"\input{foo}". From the LaTeX POV, it's impossible to conditionally  
call code based on the file input, then, because some packages don't  
use the sane syntax.

However, all of the above is slightly obscure, since most people will  
be using UTF8 input with XeTeX anyway. The fact that some edge cases  
aren't covered doesn't worry me, personally, but does mean that this  
code probably shouldn't become part of LaTeX2e proper. For me, the aim  
is to fix the problem when users try

We're just trying to support the other encodings because it's (mostly)  

>   Like I said above, I'd like to resolve this for TeXLive 2009,
> Do you have any idea of whether there will be another LaTeX release in
> time?  I was kind of expecting that there wouldn't be, although of
> course it would be great if so.

I hadn't thought that far ahead :)
I was hoping at the very least it would be easy enough to get a  
patched inputenc.sty into TL'09, even if it slightly by-passed the  
normal LaTeX release regime. But perhaps I'm being naive.