References: <11ECEE9E-C040-44DF-9D1F-97281D9128ED@gmail.com>
            <49C8B459.5050201@telecom-bretagne.eu>
            <49C8C80B.3020504@elzevir.fr> <86eiwncer9.fsf@lola.quinscape.zz>
            <49C8D015.1070205@elzevir.fr>
            <49C8D320.3070400@telecom-bretagne.eu>
            <49C8D715.7020805@elzevir.fr>
            <510AF2B3-466E-4362-BCEF-E53F4D0974BF@gmail.com>
            <863ad3cbck.fsf@lola.quinscape.zz>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 5H11)
Message-ID:  <7B45226F-3C03-4C0A-98D0-3154E1F463EA@gmail.com>
Date:         Tue, 24 Mar 2009 23:54:26 +1030
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: inputenc for XeTeX and LuaTeX
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <863ad3cbck.fsf@lola.quinscape.zz>
Precedence: list
Status: R

(Sent from my phone.)

On 24/03/2009, at 23:43, David Kastrup <dak@GNU.ORG> wrote:

> Will Robertson <wspr81@GMAIL.COM> writes:
>
>> Hi all,
>>
>> Don't forget that for utf8 encoded documents, the luatex and xetex
>> inputenc packages do *not* mess around with active characters or
>> whatever -- they prevent the legacy inputenc from doing so in the
>> first place.
>
> Wouldn't that preclude auxiliary files being written in LICR?

Licr support still works (or can still work) because the appropriate  
macros can still be defined (to eventually turn into the correct  
unicode character). However, user input is never transformed into a  
licr form internally.

But you do lose the advantages of the licr -- being able to throw an  
error, or recover by faking it, if the font doesn't contain a  
necessary glyph.

Will