## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Show All Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Re: Expandable versions of \uppercase, \MakeUppercase, \lowercase, \MakeLowercase Will Robertson <[log in to unmask]> Sun, 13 Feb 2011 18:27:46 +1030 text/plain (42 lines) On 13/02/2011, at 12:31 PM, Bruno Le Floch wrote: > 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? My personal opinion on uppercasing/lowercasing is that it should be a property of the font; some OpenType fonts allow you to do this with, e.g. in fontspec:     \addfontfeature{Letters=Uppercase} (although there might not be a "Letters=Lowercase", which is weird. I guess that one is less useful.) In effect, this replaces all lowercase *glyphs* by uppercase variations. But this is highly font-dependent until we are all using LuaTeX and can dynamically add OpenType font features like this. Anyway, regarding the examples above, I think the behaviour to emulate is David Carlisle's \MakeTextUppercase: \documentclass{article} \usepackage{textcase} \begin{document} \MakeUppercase{abc {def} {g{h}i} $x+y=z$}\par \MakeTextUppercase{abc {def} {g{h}i} $x+y=z$} \end{document} So this is kinda half-way between your and Joseph's example. However, if you're just talking about *strings* and not text, then I think the "all letters uppercase" is the way to go. So if we're speaking in expl3 terms, I'd expect \tl_to_uppercase:n{abc $x+y=z$} to output "ABC $X+Y=Z$" whereas I'd expect \TextUppercase of the same to produce "ABC $x+y=z$". * * * In terms of the algorithms to perform these operations, I prefer the way Joseph's code executes (e.g., keeping the number of csnames low) but I prefer the extensibility of Bruno's (although I suspect Bruno's is faster -- but a better question to ask is whether Joseph's is too slow). For the extensibility thing, I'm wondering for Joseph's code if the "\prg_case_str:nnn {#1} { { a } { A } ..." code could be written as something like "\prg_case_str:nVn {#1} \g_uc_replacements_tl { }". Cheers, -- Will