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 f11DEc730466 for ; Thu, 1 Feb 2001 14:14:38 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f11DFR703474 . for ; Thu, 1 Feb 2001 14:15:27 +0100 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 f11DEaM29786 for ; Thu, 1 Feb 2001 14:14:36 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C50.EDB97300" 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 OAA24586 for ; Thu, 1 Feb 2001 14:14:36 +0100 (MET) 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 f11DEZ706737 for ; Thu, 1 Feb 2001 14:14:36 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <4.C0C761C1@mail.listserv.gmd.de>; Thu, 1 Feb 2001 14:14:28 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 486235 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 1 Feb 2001 14:14:28 +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 OAA08385 for ; Thu, 1 Feb 2001 14:14:27 +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 OAA56944 for ; Thu, 1 Feb 2001 14:14:27 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f11DESp03365 for ; Thu, 1 Feb 2001 14:14:28 +0100 (MET) Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14OJZC-0004BZ-00 for LATEX-L@urz.uni-heidelberg.de; Thu, 1 Feb 2001 14:14:26 +0100 Received: from manz-3e3645ca.pool.mediaways.net ([62.54.69.202] helo=istrati.zdv.uni-mainz.de) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 14OJZ9-0004qu-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Thu, 1 Feb 2001 14:14:23 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id OAA22870; Thu, 1 Feb 2001 14:13:17 +0100 In-Reply-To: <20010201110710.A16753@clipper.ens.fr> References: <20010201110710.A16753@clipper.ens.fr> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: default inputenc/fontenc tight to language Date: Thu, 1 Feb 2001 14:13:16 +0100 Message-ID: <14969.24812.867227.593317@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" 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: 3694 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08C50.EDB97300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric, > Franck Mittelbach wrote: it is Frank :-) > > - except when using mule (or emacs) one doesn't (automatically) > > change input encodings when changing a language in the middle = of > > the document. > > I am not quite sure I understand what you mean here, so I won't = comment. 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, there might be many different possible settings, and one can = only > choose a default one. But I don't quite see how this could be an = argument > for not making a decision. For the moment, all the users must define = an > inputencoding/fontencoding tuple for all the languages in their = document. > If a default is choosen, then only some of them (and hopefully a = minority > of them) would have to specify something. Surely it is on the whole a > better solution. i think we have to distinugish between input encodings and font = encodings. for font encodings several language need a default, or say, need a = setting which differs from the system default (which is OT1) though even for = Russian or Greek or other language with drastically different character set = there are often more than a single font encoding that could apply. For example = Polish could be typeset in OT4 (but you have only a small set of fonts = available in that encoding (typically, the situation might be different in Poland)) = or it could be typeset in T1. 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. but with input encodings the situation is quite different. on the desk = here writing in German i could use latin1, ansinew or cp437de (on the same = computer depending only on the OS i'm starting) so here chosing a default that is better than saying specify it would be difficult. 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? 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 know that it is painful to have a five or 10 line preamble but at = least you know then what is in the document and that information is valid. so in summary in my opinion: - output encoding should probably have a language dependent default = (and already do to some extend). Babel in its present form will not be = able to change the default for languages that currently use the document = encoding (whatever it is) because of compatibility reasons but a successor = probably could if there are good arguments for it. - input encoding should stay ascii by default and should not change on = a per language change basis though i think a successor to babel should = offer this functionality on request, eg for the example from Denis the code that = i have here on my computer would be set up like this to achieve an = input encoding switch on a perlanguage basis: \SetLanguageCommandAction{default}\inputencodingname{ascii} \SetLanguageCommandAction{russian}\inputencodingname{koi8-r} \SetLanguageCommandAction{french} \inputencodingname{latin1} which would mean that the input encoding would switch to ascii for all languages except Russian and French (though in real life one would = probably make the "default" latin one in that cas)e. > Certainly it would be usefull to have a mechanism that binds an input = and > a font encodings to each language. But again, it is not because it is > impossible to please everybody that no default should be choosen. = Imagine > that I don't like the default margins in a LaTeX document. As it = would be > impossible to please me (and probably others), would that mean that = there > should be no default margin and that everybody should invoke the = geometry > package and explicitely give their prefered sizes ? no, but i don't think the example quite fits: a) there isn't a single default but rather a large number of defaults = you can to chose from, ie you use \documentclass[a4paper]{article} or you use = the koma classes or you use the xyz journal classes or ... and b) should the = margins be tied to the language? ie would you like to get your margins changed when = you switch languages in the middle of the document? > I used to teach LaTeX to beginners, and it was always very difficult = to > explain why it was necessary that any document should have 5 or 6 = lines > of preambule, even to just typeset a single sentence. I think the more "international" we get the more we need to expicitly = tag our data, LATeX's preamble stuff isn't the best but it isn't the worst = either i guess and specifying, say, an input encoding there, is in my opinion preferable to hidden default especially if there is no easy explanation = why the default is as it is (ie if it is difficult to remember the default) 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) cheers frank ------_=_NextPart_001_01C08C50.EDB97300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

Eric,

 > Franck Mittelbach wrote:

it is Frank :-)

 > >   - except when using mule = (or emacs) one doesn't (automatically)
 > >     change input = encodings when changing a language in the middle of
 > >     the = document.
 >
 > I am not quite sure I understand what you = mean here, so I won't comment.

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, there might be many different = possible settings, and one can only
 > choose a default one. But I don't quite = see how this could be an argument
 > for not making a decision. For the moment, = all the users must define an
 > inputencoding/fontencoding tuple for all = the languages in their document.
 > If a default is choosen, then only some of = them (and hopefully a minority
 > of them) would have to specify something. = Surely it is on the whole a
 > better solution.

i think we have to distinugish between input encodings = and font encodings.
for font encodings several language need a default, = or say, need  a setting
which differs from the system default (which is OT1) = though even for Russian
or Greek or other language with drastically different = character set there are
often more than a single font encoding that could = apply. For example Polish
could be typeset in OT4 (but you have only a small = set of fonts available in
that encoding (typically, the situation might be = different in Poland)) or it
could be typeset in T1.

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.

but with input encodings the situation is quite = different. on the desk here
writing in German i could use latin1, ansinew or = cp437de (on the same computer
depending only on the OS i'm starting) so here = chosing a default that is
better than saying specify it would be = difficult.

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?

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 know that it is painful to have a five or 10 line = preamble but at least you
know then what is in the document and that = information is valid.

so in summary in my opinion:

 - output encoding should probably have a = language dependent default (and
   already do to some extend). Babel in its = present form will not be able to
   change the default for languages that = currently use the document encoding
   (whatever it is) because of = compatibility reasons but a successor probably
   could if there are good arguments for = it.

 - input encoding should stay ascii by default = and should not change on a per
   language change basis though i think a = successor to babel should offer this
   functionality on request, eg for the = example from Denis the code that i
   have here on my computer would be set up = like this to achieve an input
   encoding switch on a perlanguage = basis:

  = \SetLanguageCommandAction{default}\inputencodingname{ascii}
  = \SetLanguageCommandAction{russian}\inputencodingname{koi8-r}
  \SetLanguageCommandAction{french} = \inputencodingname{latin1}

  which would mean that the input encoding would = switch to ascii for all
  languages except Russian and French (though in = real life one would probably
  make the "default" latin one in that = cas)e.

 > Certainly it would be usefull to have a = mechanism that binds an input and
 > a font encodings to each language. But = again, it is not because it is
 > impossible to please everybody that no = default should be choosen. Imagine
 > that I don't like the default margins in a = LaTeX document. As it would be
 > impossible to please me (and probably = others), would that mean that there
 > should be no default margin and that = everybody should invoke the geometry
 > package and explicitely give their = prefered sizes ?

no, but i don't think the example quite fits:

a) there isn't a single default but rather a large = number of defaults you can
to chose from, ie you use = \documentclass[a4paper]{article} or you use the koma
classes or you use the xyz journal classes or ... and = b) should the margins be
tied to the language? ie would you like to get your = margins changed when you
switch languages in the middle of the = document?

 > I used to teach LaTeX to beginners, and it = was always very difficult to
 > explain why it was necessary that any = document should have 5 or 6 lines
 > of preambule, even to just typeset a = single sentence.


I think the more "international" we get the = more we need to expicitly tag our
data, LATeX's preamble stuff isn't the best but it = isn't the worst either i
guess and specifying, say, an input encoding there, = is in my opinion
preferable to hidden default especially if there is = no easy explanation why
the default is as it is (ie if it is difficult to = remember the default)

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)

cheers
frank

------_=_NextPart_001_01C08C50.EDB97300--