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:


(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:

\MakeUppercase{abc {def} {g{h}i} $x+y=z$}\par
\MakeTextUppercase{abc {def} {g{h}i} $x+y=z$}

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 { <else> }".

-- Will