LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Sun, 13 Feb 2011 10:20:17 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Frank Mittelbach <[log in to unmask]>
text/plain (55 lines)
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
 > 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.