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:42:48 +0100 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n2OCgmu5018755 for ; Tue, 24 Mar 2009 13:42:48 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n2OCdAvR007283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 13:39:11 +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 n2O8wjg6001396; Tue, 24 Mar 2009 13:39:10 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 218641 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 24 Mar 2009 13:39:10 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n2OCdA2F007304 for ; Tue, 24 Mar 2009 13:39:10 +0100 Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n2OCcuOe032274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Mar 2009 13:38:59 +0100 Received: from roth.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 1E76935B9E for ; Tue, 24 Mar 2009 13:38:55 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by roth.elzevir.fr (Postfix) with ESMTP id A095CBFE3 for ; Tue, 24 Mar 2009 13:38:52 +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> <49C8CD5A.4070105@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: <49C8D45C.6080205@elzevir.fr> Date: Tue, 24 Mar 2009 13:38:52 +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: <49C8CD5A.4070105@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:42:48.0736 (UTC) FILETIME=[09D1A200:01C9AC7E] Status: R X-Status: X-Keywords: X-UID: 5732 Elie Roux a écrit : >> By the way, people using XeTeX just encode their sources in utf-8 and skip >> loading inputenc, and seem to be happy with it. >> > I think LuaTeX does not target the same users. With luainputenc and > fontenc working, LuaTeX can start targetting the average user, as the > old LaTeX documents will be working with LuaLaTeX (if inputenc loads > luainputenc). XeTeX will never allow old documents to be compiled with > it, as most input encoding problems have no solution. > Sure. But their is no need to target the average user too early. Leave early beta-testing to advanced users. luainputenc and a working fontenc for LuaTeX are very new and quite untested. Don't throw it in the hands of the average user right know, please wait. >> So I see no harm in waiting a bit before implementing backward >> compatibility solutions. >> > And I see no harm in proposing a working LuaLaTeX... Half-working and quite untested, sorry. I still had no time to look closely at luainputenc's latest versions, but if I understand correctly how it works, I'm pretty sure some of my own documents won't comile without modification with it. (And I'm talking of real-life documents, not specially-forged tricks.) > Of course, as > LuaTeX is not stable, LuaLaTeX won't be stable... but remember that > people call LuaLaTeX with the command "lualatex", so they know what they > are doing. > And since they know what they are doing, the can just change inputenc into luainputenc. By the way, a point I forgot to mention earlier is documentation. Keeping separate names allows to properly document the current limitations, known issues and how to solve them, for every individual package, at least during the testing phase. > LuaTeX can only write UTF-8, so people needing to write in files in > 8-bit without LICR (meaning not a lot of people) Well, not meaning nobody either. > will have problems if > they do it in home-made package (I solved the problem for all files > generated by packages in TeXLive), so the problem concerns noone except > very advanced TeX users... I don't think using VerbatimOut or filecontents qualifies as a very advanced TeX user. > I know you're one of them, but for the > average user it will be 99.9999% backward compatible. I tend to disagree with this value. But only testing will really show if it is rather 90% or 99.9999%. > Well, I'm not sure pdfTeX and TeX82 were 100% compatible neither... > Of course they weren't. The question is: concerning the encodings, is it possible to handle the differences well enough in a macro package so that we can hide them to the user? Maybe, but I don't think it is already done, sorry. > Or even better: a warning and the loading of luainputenc. I don't think > this warning is necessary, but I don't have a strong opinion about it, I > think it will just be boring for the average user... Experience proves normal users don't read warnings. (Even when they have problems.) (Well, it probably holds for most error messages too...) Manuel.