Mail-Followup-To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
References: <553234443@web.de> <m3sklc2b5e.fsf@lugabout.jhcloos.org>
            <49C01E4B.4020604@elzevir.fr>
            <18880.10491.482905.22434@morse.mittelbach-online.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Message-ID:  <20090318015925.GA29765@irwin.vpn.uni-freiburg.de>
Date:         Wed, 18 Mar 2009 02:59:26 +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: Heiko Oberdiek <oberdiek@UNI-FREIBURG.DE>
Subject: Re: inputenc for XeTeX and LuaTeX
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <18880.10491.482905.22434@morse.mittelbach-online.de>
Precedence: list
Status: R

On Tue, Mar 17, 2009 at 11:49:31PM +0100, Frank Mittelbach wrote:

> Manuel Pégourié-Gonnard writes:
>  > James Cloos a écrit :
>  > > As for utf-8 or other, it may be useful to default to the character set
>  > > specified for the current $LOCALE.  Maybe. :-/
>  > > 
>  > Please don't do anything in the compilation of the document depend on the
>  > locale! It would completely ruin portability of the source files.
> 
> perhaps. it might be a straight path into long-term disaster.On the other
> hand the whole area is a disaster in the first place. When we started out with
> inputenc in 2e I also thought that it is really good to keep the encoding with
> the file (which you do by stating \usepackage[latin1]{inputenc} and the like)
> and that worked for a while fairly good. But then OSes started to convert on
> the fly so by cut-n-paste sometimes even on the same machine an old latin1 got
> translated into something else (except for the string specifying the encoding
> inside)... so ... not easy really

It's addressed by package selinput.

> ps interestingly enough, in 2e on top of anormal TeX engine that problem was
> properly solved as we ensured that internally written files were always
> written in LICR which is unicode in 7bit so it was always coming back
> properly.

For similar reasons I have converted arbitrary user data into hex when
writing them to auxiliary files and decoded them reading back.
This solves problems like unmatched curly braces, characters with
special catcodes, ...

Yours sincerely
  Heiko <oberdiek@uni-freiburg.de>