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 f169HKH05275 for ; Tue, 6 Feb 2001 10:17:20 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f169HCd04054 . for ; Tue, 6 Feb 2001 10:17:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0901D.9B47D000" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f169HB708277 for ; Tue, 6 Feb 2001 10:17:11 +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 KAA12134 for ; Tue, 6 Feb 2001 10:17:10 +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 f169H8708269 for ; Tue, 6 Feb 2001 10:17:08 +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 <9.6A099E7B@mail.listserv.gmd.de>; Tue, 6 Feb 2001 10:17:03 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 487762 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 6 Feb 2001 10:17:05 +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 KAA26376 for ; Tue, 6 Feb 2001 10:17:04 +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 KAA38784 for ; Tue, 6 Feb 2001 10:17:04 +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 f169H4u05609 for ; Tue, 6 Feb 2001 10:17:04 +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 f169H3485465 for ; Tue, 6 Feb 2001 10:17:03 +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 10:17:03 +0100 Message-ID: <20010206101702.A5774@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: 3710 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0901D.9B47D000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry for replying late. Hey, in the internet age, a 4 days delay is a long time... Frank Mittelbach wrote: > what i mean is that most people write their document in a single input > encoding and do not switch that encoding (or even can switch) just > because they switch from one language to another. Sure. Mainly because usualy people don't switch from a language to another, or, if they do, it is usually languages with compatible encodings. But I imagine (maybe wrongly) that you need to switch encodings when writing an english-russian document. > Anyway, for font encodings a default setting different from the system = default > (if necessary) does make sense and current babel already tries to do = that, > though as Denis report shows not always successfully. I am happy to hear that. Now, about input encodings... > furthermore, because of the argument that the input encoding doesn't = really > change "wenn ich jetzt in Deutsch schreibe" (both are latin1 as far as > this mail is concerned) so for english and german and french it should > probably be the same. ansinew because a lot of people use PCs? or = latin1 > because Linux is going to take over the world? or should it change in = a > year or two when the latter happens --- with the result that then = older > documents would compile incorrectly because they assume the no longer > correct default? I should go to the latin1 by default, because it is somehow a more accepted standard (in the sens that it is an ISO standard) than ansinew. But we are lucky: ansinew and latin1 are compatible, in the sens that latin1 is a subset of ansinew (there are 24 extra characters in ansinew, in the 130--159 range), so a source.tex composed in the ansinew encoding would be readable on a unix system, except for some very rare = characters. Probably the best of all worlds would be to advertize and document that latin1 is the default encoding (for standards compliance), and thus encourage people to use \oe or \dots or -- instead of the characters = 156, 133 or 150, but silently accept all the extra ansinew characters so that careless window users don't get surprised. What is sure, is that once a default encoding is choosen, it will be = hard to change it (the only way would probably be to change \documentclass into \documenttype :-) > finally applying the wrong input encoding to a document not in that > encoding results in typesetting errors but not in compilation errors. > true, this can also happen if you explicitly specify the wrong = encoding > but this is a conscious act (or so we would hope) and not something = htat > happens behind the scene I have seen many beginners that begin typing in french their document without declaring an inputenc, and not realizing at once that accents = are missing in the document. I would not call forgetting an \usepackage declaration a conscious act. > which reminds me: please take the list of languages babel currently = supports > and attach to them input/font encoding defaults that would be = suitable, i > would really be interested in see such a list (and have it disucssed) Oh, I am certainly not able to do that. If I was to make a choice, I would use the appropriate latinxxx encodings for each language, but I am certainly not qualified to choose for all those languages. =C9ric ------_=_NextPart_001_01C0901D.9B47D000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

Sorry for replying late. Hey, in the internet age, a 4 = days delay is a
long time...

Frank Mittelbach wrote:
> what i mean is that most people write their = document in a single input
> encoding and do not switch that encoding (or = even can switch) just
> because they switch from one language to = another.
Sure. Mainly because usualy people don't switch from = a language to
another, or, if they do, it is usually languages with = compatible
encodings. But I imagine (maybe wrongly) that you = need to switch
encodings when writing an english-russian = document.

> Anyway, for font encodings a default setting = different from the system default
> (if necessary) does make sense and current babel = already tries to do that,
> though as Denis report shows not always = successfully.

I am happy to hear that. Now, about input = encodings...

> furthermore, because of the argument that the = input encoding doesn't really
> change "wenn ich jetzt in Deutsch = schreibe" (both are latin1 as far as
> this mail is concerned) so for english and = german and french it should
> probably be the same. ansinew because a lot of = people use PCs? or latin1
> because Linux is going to take over the world? = or should it change in a
> year or two when the latter happens --- with the = result that then older
> documents would compile incorrectly because they = assume the no longer
> correct default?

I should go to the latin1 by default, because it is = somehow a more
accepted standard (in the sens that it is an ISO = standard) than ansinew.
But we are lucky: ansinew and latin1 are compatible, = in the sens that
latin1 is a subset of ansinew (there are 24 extra = characters in ansinew,
in the 130--159 range), so a source.tex composed in = the ansinew encoding
would be readable on a unix system, except for some = very rare characters.
Probably the best of all worlds would be to advertize = and document that
latin1 is the default encoding (for standards = compliance), and thus
encourage people to use \oe or \dots or -- instead of = the characters 156,
133 or 150, but silently accept all the extra ansinew = characters so that
careless window users don't get surprised.

What is sure, is that once a default encoding is = choosen, it will be hard
to change it (the only way would probably be to = change \documentclass
into \documenttype :-)

> finally applying the wrong input encoding to a = document not in that
> encoding results in typesetting errors but not = in compilation errors.
> true, this can also happen if you explicitly = specify the wrong encoding
> but this is a conscious act (or so we would = hope) and not something htat
> happens behind the scene

I have seen many beginners that begin typing in french = their document
without declaring an inputenc, and not realizing at = once that accents are
missing in the document. I would not call forgetting = an \usepackage
declaration a conscious act.

> which reminds me: please take the list of = languages babel currently supports
> and attach to them input/font encoding defaults = that would be suitable, i
> would really be interested in see such a list = (and have it disucssed)

Oh, I am certainly not able to do that. If I was to = make a choice, I
would use the appropriate latinxxx encodings for each = language, but I am
certainly not qualified to choose for all those = languages.

=C9ric

------_=_NextPart_001_01C0901D.9B47D000--