## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Condense Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> From: Frank Mittelbach <[log in to unmask]> Date: Thu, 1 Feb 2001 10:48:37 +0100 In-Reply-To: <[log in to unmask]> Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> Parts/Attachments: text/plain (83 lines) ```Denis,  > Well, when I brought up that issue, it was not pure theory. didn't expect it otherwise.  > (inputenc2 is a variant of inputenc where you can switch the input encoding  > within a paragraph; it is possible that there is a standard package  > achieving this now) think it is called inputenc these days  > Yes, I had such a problem with differed layouts like the table of contents.  > For instance, say you have a French, then a Russian section. If you write  >  > switch encoding to French  >  > \tableofcontents  >  > \section{French}  >  > switch encoding to Russian  >  > \section{Russian}  >  > you'll end up with `French' appearing in Cyrillic, because  > the state at the end of the \tableofcontents is not restored.  > You have to add an explicit change of encoding, for instance after  > \tableofcontents, or at the end of your document. basically what you are saying is that moving text needs to keep information about its state with it, right? it fortunately doesn't need to keep information about its input encoding since that got all normalised into the internal representation but unfortunately you need to keep information about the encoding used (or rather the encoding intended) a bit inconsistent that, isn't it? but would it help if the language has a tie to the encoding? i think current babel would handle the toc example right (if the output encoding is set by the language) but i guess this would not be true for mark entries. concerning the output encoding: assuming there is something like \languagefontencoding which is either unset or set (per language) and if set results in a change to the font encoding whenever a language switch happens. (if unset for a language that should probably mean revert to the document default encoding). for languages like Russian things are relatively clear (though not really either) since due to the limitation of TeX we are forced to select an encoding, so there the language might as well provide a default like T2A, but for German this it is not the case, ie one can type in OT1, T1, or even OT4. a scheme like the above would then do well enough but the user still has to make some font encoding decisions (like what is the default font encoding, or do i want T1 with english ...) however it would be far nicer if TeX (or LaTeX) would be able to take a bit of text written in the internal LaTeX representation (plus language tags), ie ascii + font encoding specific commands and automagically figures out behind the scene how to typeset the lot. only i can't see how to make this happen more automatically with the above scheme, which requires a) language tags and b) potentially customisation in the preamble. a lot of people find (and i agree) that  \usepackage[T1]{fontenc} is already to much to expect (and difficult or impossible to explain) --- and why should a user be concerned with it? but then, the same people have diametral ideas what are the right values of fontencodings for a certain language: just look at the different opinions on this list concerning French and OT1 or T1. so we have to offer a choice, question is, is there a better way to present it? frank ```