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
Condense Mail Headers

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

Print Reply
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Thu, 23 Feb 2006 20:21:44 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Werner LEMBERG <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Transfer-Encoding: 7bit
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: Text/Plain (23 lines)
> 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

ATOM RSS1 RSS2