\MakeUppercase in toc breaks microtype with latex 2022+

[scholnik]

Consider the following MWE:

\documentclass{report}
   \usepackage{microtype}
\begin{document}
   \tableofcontents
   \addcontentsline{toc}{chapter}{\numberline{\thechapter.}\MakeUppercase{Test}}
   Test
\end{document}

For pre-2022 latex (I'm using texlive 2021) this compiles fine with any of {pdflatex,xelatex,lualatex}, and generates the .toc file

\contentsline {chapter}{\hbox to\@tempdima {0.\hfil }\leftprotrusion \MakeUppercase {Test}}{1}{}%

A second compile to update the toc completes without error. In texlive 2022, however, the following .toc is generated:

\contentsline {chapter}{\hbox to\@tempdima {0.\hfil }\leftprotrusion \MakeUppercase []{Test}}{1}{}%

Note the additional []. A second compilation now generates the error

./test3.toc:1: Argument of \MakeUppercase (arg 1) has an extra }.
<inserted text> 
                \par 
l.1 ...eftprotrusion \MakeUppercase []{Test}}{1}{}
                                                  %
Runaway argument?
\ERROR \relax \MT@csq@eqgroup 
./test3.toc:1: Paragraph ended before \MakeUppercase (arg 1) was complete.
<to be read again> 
                   \par 
l.1 ...eftprotrusion \MakeUppercase []{Test}}{1}{}
                                                  %

./test3.toc:1: LaTeX Error: The key '__kernel/\MT@gobble@to@nil \MT@nil' is unknown and is
(LaTeX)        being ignored.

It would seem that \leftprotrusion does not like the empty optional argument to \MakeUppercase. I am able to work around this using the nopatch=toc option in microtype v3.1, which eliminates the \leftprotrusion from the .toc, but reporting here since this doesn't seem like intended behavior.

[schlcht]

Oh, I wasn't aware that \MakeUppercase now also accepts an optional argument.

Could you try with:

\def\MT@prot@check@C{%
  \ifx\MT@prot@l\MT@prot@l@tc
    \def\MT@temp*{\MT@exp@one@n\MT@prot@l{\the\MT@toks}}%
  \else
    \let\MT@prot@l\MT@prot@l@tc
    \def\MT@temp*##1{%
      \the\MT@toks
      \MT@toks{}%
      \@ifnextchar[%
        {\MT@prot@check@C@##1}%
        {\MT@prot@check@C@##1[]}%
    }%
  \fi
}
\def\MT@prot@check@C@#1[#2]#3{%
  \MT@ifempty{#2}{%
    \let\MT@maybe@textcmd#1%
    \MT@prot@toks{#1{#3}}%
  }{% 
    \def\MT@maybe@textcmd{#1[#2]}%
    \MT@prot@toks{#1[#2]{#3}}%
  }   
  \MT@prot@get@firstgroup@tc#3\MT@nil
}     
\patchcmd\MT@prot@check@cmds{{F\MakeUppercase}{F\MakeLowercase}}{{C\MakeUppercase}{C\MakeLowercase}}{}{}
\patchcmd\MT@prot@check@cmds{{F\MakeTitlecase}}{{C\MakeTitlecase}}{}{}

[scholnik]

Yes, that seems to take care of it, thanks. I also wasn't aware of the optional argument, don't know what it does, and wasn't trying to use it; it was autogenerated in the .toc file for some reason.

[denilsonsa]

Hi there!

It's been ⅓ of a year since the fix was pushed to the dev branch. Would you think it's worthwhile to make a new release?

Some document classes (such as abntex2) may add the \MakeUppercase automatically, which then breaks and leaves users confused. Having a new release should fix it (plus the time needed for the package to move to stable in the distributions package managers).

[jeinstei]

I need to second this -- is a release planned any time soon? I'm not sure if this is also related to issue 31, but we're seeing changes that we didn't expect since March.

[joaoantoniocardoso]

I'm also -- and possibly any other Arch Linux user trying to use abntex2 with microtype -- stuck with this same issue.

[denilsonsa]

Just to give some background information… Any academic work published in Brazil should follow the standards defined by the ABNT association. To help with that, someone wrote the abnt package, but it seems unmaintained. There is also abntex2, which seems way more active, better maintained, and with more documentation.

Unfortunately, anyone using abntex2 on a modern LaTeX distribution will be bitten by this bug, and will be extremely confused. How many people does it affect? Well, every person in Brazil who publishes research using LaTeX. That's a lot of people.

People using "bleeding edge" Linux distributions (like Arch Linux, or Debian testing/unstable) are the canaries in a coal mine. Since we are using the latest versions, we detect issues before they trickle down to "stable" distributions that are usually stuck in older versions for a long period. And that's why I believe a new version should be released soon (assuming there are no further known bugs/regressions). Whenever those "stable" distros get stuck with an older version, it takes considerably more effort to convince them to update, and it affects many more people (at least one order of magnitude more).

[Italo-ols]

I've also just suffered from the same problem here. I'm glad I've found this issue, because tracking down latex errors is a bit hard for me and I need to write a proposal using abntex2 and Overleaf isn't an option for me.

[schlcht]

sorry everybody for the long delay!