References: <200602231927.45843.lehman@gmx.net>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <20060223.202144.04749817.wl@gnu.org>
Date:         Thu, 23 Feb 2006 20:21:44 +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: Werner LEMBERG <wl@GNU.ORG>
Subject: Re: [latex/3844] uc/lccode controls in inputenc?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <200602231927.45843.lehman@gmx.net>
Precedence: list
Status: R

> My suggestion was: why not set the uppercase and lowercase codes of
> all bytes used in UTF-8 to zero? The concept of uc/lccodes doesn't
> apply to UTF-8 anyway (at least not with an 8-bit engine...), why
> take the risk of having it backfire?

This sounds reasonable to me.

> There is one thing I didn't mention in the report. Since inputenc
> may switch the input encoding mid-stream, the codes would also need
> to be restored before a new encoding is initialized. So the issue at
> stake is really: should there by a central uc/lccode management in
> inputenc?

Hmm.  Isn't there a rule that uc/lccode values are fixed?
Additionally, they apply to the font encoding, IIRC, and not the input
encoding...

I vote for setting uc/lccode values to zero for UTF-8 but retain them
as-is for all other 8bit input encodings.


    Werner