Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f16FEdH19112 for ; Tue, 6 Feb 2001 16:14:39 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f16FEdd05057 . for ; Tue, 6 Feb 2001 16:14:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0904F.85EB9980" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f16FEcM04920 for ; Tue, 6 Feb 2001 16:14:38 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id QAA23006 for ; Tue, 6 Feb 2001 16:14:37 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f16FEb712892 for ; Tue, 6 Feb 2001 16:14:37 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <10.5A653EE6@mail.listserv.gmd.de>; Tue, 6 Feb 2001 16:14:32 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488424 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 6 Feb 2001 16:14:33 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id QAA07656 for ; Tue, 6 Feb 2001 16:14:32 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id QAA40298 for ; Tue, 6 Feb 2001 16:14:33 +0100 Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f16Eu6u01183 for ; Tue, 6 Feb 2001 15:56:06 +0100 (MET) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id f16Eu5421915 for ; Tue, 6 Feb 2001 15:56:05 +0100 (CET) Received: from (ebrunet@localhost) by clipper.ens.fr (8.9.2/jb-1.1) Return-Path: User-Agent: Mutt/1.2i Content-class: urn:content-classes:message Subject: Re: default inputenc/fontenc tight to language Date: Tue, 6 Feb 2001 15:56:04 +0100 Message-ID: <20010206155604.A14544@clipper.ens.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Eric Brunet" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3718 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0904F.85EB9980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank wrote: > this is a problem agreed, because of this unfortunate fact of letting = 8bit > loose if no inputenc is specified. > but providing an input encoding automatically would be a big = compatibility > problem and within 2e kernel we have a firm policy of not doing this = (and if > we move it to a package (aka inputenc) then you are back to your above > problem). Oh, that I understand very well that the 2e kernel should be always perfectly backward compatible. It is a good policy. However, I believe = it is not true of the packages: if two people use two different versions of the same package, it is allowed that their document differ in the end = for the same source, I think. That is why I was proposing in the beginning = of this thread to put this new facility in a new version of the babel package. After all, the kernel has no way to determine a good default input encoding without knowing first which is the language of the document, and thus it makes sense to let babel choose the default encoding. In this way the 2e kernel stays compatible, only babel user = see a difference. Moreover, the change wouldn't disturb anybody: if someone doesn't hear about the change, he would probably keep on declaring \usepackage[something]{inputenc} and might never become aware that there is a default encoding for the language he is using. > will? the user groups? for many lanugages there isn't a user group If not all languages have their newsgroups, I think you can find them in comp.text.tex. If not, somebody must have written all those language files for babel. This person might be qualified to choose. In last recourse, I would choose the suitable latinxxx for the language. Or = maybe leave it to ascii till someone complains; we don't need to give a = default to all language in one go. > anyway, for the code that i'm currently writing i've added a way to = specify > inputencodings by language (or script) at least for the moment Yes, that is needed anyway, and it is excellent news. But it would be so much nicer to have a default value. =C9ric ------_=_NextPart_001_01C0904F.85EB9980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

Frank wrote:

> this is a problem agreed, because of this = unfortunate fact of letting 8bit
> loose if no inputenc is specified.

> but providing an input encoding automatically = would be a big compatibility
> problem and within 2e kernel we have a firm = policy of not doing this (and if
> we move it to a package (aka inputenc) then you = are back to your above
> problem).

Oh, that I understand very well that the 2e kernel = should be always
perfectly backward compatible. It is a good policy. = However, I believe it
is not true of the packages: if two people use two = different versions of
the same package, it is allowed that their document = differ in the end for
the same source, I think. That is why I was proposing = in the beginning of
this thread to put this new facility in a new version = of the babel
package. After all, the kernel has no way to = determine a good default
input encoding without knowing first which is the = language of the
document, and thus it makes sense to let babel choose = the default
encoding. In this way the 2e kernel stays compatible, = only babel user see
a difference.  Moreover, the change wouldn't = disturb anybody: if someone
doesn't hear about the change, he would probably keep = on declaring
\usepackage[something]{inputenc} and might never = become aware that there
is a default encoding for the language he is = using.

> will? the user groups? for many lanugages there = isn't a user group

If not all languages have their newsgroups, I think = you can find them in
comp.text.tex. If not, somebody must have written all = those language
files for babel. This person might be qualified to = choose. In last
recourse, I would choose the suitable latinxxx for = the language. Or maybe
leave it to ascii till someone complains; we don't = need to give a default
to all language in one go.

> anyway, for the code that i'm currently writing = i've added a way to specify
> inputencodings by language (or script) at least = for the moment

Yes, that is needed anyway, and it is excellent news. = But it would be so
much nicer to have a default value.

=C9ric

------_=_NextPart_001_01C0904F.85EB9980--