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
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 10 Feb 2010 18:56:23 +0000
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
From:
Joseph Wright <[log in to unmask]>
Parts/Attachments:
text/plain (19 lines)
Hello Chris,

> Input is not the only place where character-like things appear in TeX; this is another way of saying what Lars said.  Character repertoires are distinct from encodings of characters and these are different again from the encodings used in external files.
>
> So you need to know what character repertoires you are going to deal with internally in these various types of string, whether or not these are represeted by, for example, 7-bit LICRs.

I was thinking of input encodings, where my point was (supposed to) be 
that something like the inputenc "utf8" approach would be an approach I 
hope we can avoid as there are better solutions (in the form of engines 
which deal with the issue). (Of course, that leaves UTF-16 issues, but 
I'd hope that engine developments can help out).

(I'd point out that LaTeX3 code is intended for use in new documents, 
and the rest of the computer world is standardising on UTF-8 as far as I 
can see. So I'd hope very much that having an approach based on this 
concept is not too risky.)
-- 
Joseph Wright

ATOM RSS1 RSS2