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