Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
References: <4B727378.8060704@morningstar2.co.uk>,
            <4B729944.5050308@residenset.net>                      
            <OFD3BDE8BF.D25CA425-ON802576C6.0043FFAD-802576C6.0043FFAE@mcs-notes1.open.ac.uk>,
            <4B72B36E.6010401@morningstar2.co.uk>
            <OF7A9BB41F.2FC253BE-ON802576C6.005B33FC-802576C6.005B340D@mcs-notes1.open.ac.uk>
            <4B730157.5060605@morningstar2.co.uk>
Content-Transfer-Encoding: 8bit
Message-ID:  <3A6B880C-91AA-4597-8E53-92F72E3FA70A@yahoo.de>
Date:         Wed, 10 Feb 2010 22:18:54 +0100
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: Philipp Stephani <st_philipp@YAHOO.DE>
Subject: Re: LaTeX3 8-bit only?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4B730157.5060605@morningstar2.co.uk>
Precedence: list
Status: R

Am 10.02.2010 um 19:56 schrieb Joseph Wright:

> 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).

Current implementation strategies for strings in development environments define one Unicode encoding scheme (UTF-16 in nearly all cases like Windows, Java, Python, Qt, .NET, COM, Cocoa, Carbon; a few technologies like Gnome and Emacs choose UTF-8 instead) that is used exclusively for internal processing, and define "strings" as sequences of UTF-16 or UTF-8 code units. LaTeX could do the same, depending on the engine: UTF-8 for pdfTeX, UTF-16 for XeTeX. Other possibilities (e.g. LICR or UTF-32) are probably either too complicated or not flexible enough.