MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <AANLkTinjH5Ppg2QWWBTDBBU9u3Vvdsjnrrr1OvPvWfnA@mail.gmail.com>
Message-ID:  <19799.41553.794248.532467@morse.mittelbach-online.de>
Date:         Sun, 13 Feb 2011 10:20:17 +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: Expandable versions of \uppercase, \MakeUppercase, \lowercase, \MakeLowercase
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <AANLkTinjH5Ppg2QWWBTDBBU9u3Vvdsjnrrr1OvPvWfnA@mail.gmail.com>
Precedence: list
Status: R

Bruno Le Floch writes:
 > Hello, and sorry for the long title (useful perhaps for searching
 > purposes later on).
 > 
 > There was recently a question on tex.stackexchange about writing a purely
 > expandable version of LaTeX2e's \MakeUppercase. Joseph Wright and me
 > posted two answers with different interpretations of uppercasing, and he asked
 > me to transfer the discussion to this list. For the code, see
 >          http://tex.stackexchange.com/questions/10805/
 > and in particular our two answers.
 > 
 > His method yields
 > "\Uppercase{Som{e } {te{x}t} with $math$.}" -> "SOMe  te{x}t WITH $math$."
 > Mine yields:
 > "\Uppercase{Som{e } {te{x}t} with $math$.}" -> "SOM{E } {TE{X}T} WITH $MATH$."
 > 
 > Two questions:
 > - what precise behaviour do we want an uppercase function to have? Note that
 > we could even provide hooks to let the user choose. (See near the
 > bottom of this
 > long email.)
 > - what do you think of the advantages/drawbacks described below?
 > 

In my opinion uppercasing of strings should be transparent to other string
manipulation and presentation options. That is should make no difference if I
first uppercase some text and then bolden a word inside or first bolden
something and then uppercase the whole, eg

   \MakeUppercase{abc \textbf{foo} xyz}

should in my opinion yield  "ABC \textbf{FOO} XYZ"

However if braces prevent uppercasing I would need to write something like

   \MakeUppercase{abc \textbf{\MakeUppercase{foo}} xyz}

so on the whole I'm against the idea to use braces to prevent uppercasing.

Concerning math I would claim that normally formulas should not be subject to
uppercasing which is a *text* string feature. in 99.5% of all cases
uppercasing a formula renders it invalid.

I guess I agree with Will that "case" would be best thought of as a font
property ie a glyph representation, that is in NFSS terms a separate axis
which contains "uppercase, lowercase, smallcaps, mixedcase". When I designed
NFSS in the '90 one of the strange design decisions was to make small caps a
"shape" like "italic" rather than a separate axis. But he issue back then (and
most likely even today) was that that axis would have been more or less empty
because of no fonts properly supporting it. Perhaps this was a wrong decision
even back then because shortly afterwards the takeoff of virtual fonts would
have allowed us to produce the missing fonts with fontinst fairly easily.

frank