LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Frank Mittelbach <[log in to unmask]>
Thu, 1 Feb 2001 14:13:16 +0100
text/plain (115 lines)
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

ATOM RSS1 RSS2