Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 13:54:23 +0100 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n2OCsMpE018905 for ; Tue, 24 Mar 2009 13:54:23 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n2OConoO007922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 13:50:49 +0100 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n2O8wjhS001396; Tue, 24 Mar 2009 13:50:45 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 218734 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 24 Mar 2009 13:50:45 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n2OCojuu008222 for ; Tue, 24 Mar 2009 13:50:45 +0100 Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n2OCoVWA017568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Mar 2009 13:50:34 +0100 Received: from roth.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 0F95A35B9E for ; Tue, 24 Mar 2009 13:50:31 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by roth.elzevir.fr (Postfix) with ESMTP id C74FABFE3 for ; Tue, 24 Mar 2009 13:50:29 +0100 (CET) User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 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> X-Enigmail-Version: 0.95.0 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x50A89B42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <49C8D715.7020805@elzevir.fr> Date: Tue, 24 Mar 2009 13:50:29 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= Subject: Re: inputenc for XeTeX and LuaTeX To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <49C8D320.3070400@telecom-bretagne.eu> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -4 () RCVD_IN_DNSWL_MED X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 24 Mar 2009 12:54:23.0241 (UTC) FILETIME=[A7C6AF90:01C9AC7F] Status: R X-Status: X-Keywords: X-UID: 5733 Elie Roux a écrit : > In the future LuaTeX will probably replace pdfTeX, so inputenc will load > luainputenc. The question is not really to decide if it's good or not, Hmm... > it's to decide when we will do it. And I still can't really see why we > should wait three more years... > I don't mean waiting for three years. I just mean waiting enough to be able to tidy up problems. Probably one year will be enough. Be a few months (current time of luainputenc development/testing, iirc) are probably not enough. > Just to repeat myself: (lua)inputenc is not optional in most cases, so > the user will have to load luainputenc. This means that people working > with LuaLaTeX will have to change their documents in 2012, replacing > luainputenc by inputenc... And that's perfectly ok if they need so, because you know you possibly have to change a few names sometimes when you're using something under developement. (And it doesn't mean only LuaTeX: I sometimes have to change my documents in order to make them compile with a newer version of Koma-script, and I accept that. If I don't want to have to worry about it, I use only the standard classes, and I'm happy I have this choice too.) Anyway, I see no reason why luainputenc should stop working with this name if it is later available as inputenc. A package can perfectly have multiple names. > I know it's not 100% stable so users must > know what they're doing, but it still seems more annoying than the > miracle solution for stability... Well, it seems we disagree on what the future will be. In my future, I want to be able to compile utf-8 encoded sources using Unicode fonts without loading some sort of inputenc and making a bunch af character actives. Manuel.