LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0 (iPhone Mail 5H11)
Content-Type:
text/plain; charset=us-ascii; format=flowed; delsp=yes
Date:
Tue, 24 Mar 2009 23:54:26 +1030
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Will Robertson <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
7bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (26 lines)
(Sent from my phone.)

On 24/03/2009, at 23:43, David Kastrup <[log in to unmask]> wrote:

> Will Robertson <[log in to unmask]> 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

ATOM RSS1 RSS2