MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200602231927.45843.lehman@gmx.net>
            <17406.56847.567915.709994@morse.mittelbach-online.de>
            <17407.3292.411102.175224@isostar.informatik.uni-stuttgart.de>
Message-ID:  <17407.5802.704111.204260@morse.mittelbach-online.de>
Date:         Fri, 24 Feb 2006 15:22:34 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: [latex/3844] uc/lccode controls in inputenc?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <17407.3292.411102.175224@isostar.informatik.uni-stuttgart.de>
Precedence: list
Status: R

thanks Bernd for adding the details to what I said.

one comment on using eTeX (or friends)

 > What is needed to make this work is add the assignment of this new
 > e-TeX register when loading hyphenation patterns.  In addition one has
 > to check the "correct" lccode settings for each language at that time.
 > 
 > 
 > But this will not solve the problem for standard TeX.  For TeX the
 > current LaTeX approach is fine.

that is correct and would resolve the problem that currently forces T1 as the
only lc table in LaTeX (but it requires a different code base for language to
deal with those patterns).

but it wouldn't solve the problem of allowing \uppercase or \lowercase as
those act on the input encoding which is not being managed by this eTeX
mechanism and you can't chose one lc table during input encoding conversion
and a different one during output encoding conversion as there may be no place
to gain control again is the TeX primitive \lowercase is used directly in
typesetting

eg font encoding is T1 input encoding is UTF8

  foo \lowercase{BAR} base \par

frank