\setbeamercolor{math text} or \setbeamercolor{math text inlined} changes the color of inline math $...$ as intended, but it also affects/resets the color in internal constructs of LaTeX or packages which use inline math (typically as $\m@th ...$). Examples are \smash, \root, \sqrt, \big, \Big, etc., but also the pmatrix, aligned, gathered environments of amsmath and probably many more. When this happens, it is difficult to readjust the undesired behaviour at the user level.
There are many combinations that lead to different behaviour which is not easy to describe conclusively. Hence I have created a test file that shows many cases along with some general expectations, see below. Some displayed combinations work as intended, others not, so this may be useful for testing and bugfixing purposes.
Further comments:
General question:
Packages may avoid the undesired behaviour by injecting \donotcoloroutermaths in their internal math constructs. The question here would be whether they should make such compatibility adjustments when beamer or beamerbasecolor is loaded or whether they should rather rely on beamer to avoid the undesired color resets. One might try to do this within \m@th which indicates an internal construct, but it's rather too late because the math text inline color is already set by then.
A general solution might be to disable math text colors when nesting, i.e. when a math text color has already been set in the present scope (\@parboxrestore could reenable where nesting is desired). Alternatively, beamer could implement within \m@th the undo of a color set from within \everymath? Not sure whether that makes any sense.
Test file: output beamer-math-color.pdf log beamer-math-color.log
\documentclass[12pt]{beamer}
\newcommand{\red}{\color{red}}
\let\latexbig=\big
\let\latexequation=\equation
\let\endlatexequation=\endequation
\usepackage{amsmath}
\let\amsmathbig=\big
\IfFileExists{eqnlines.sty}{\usepackage[env=none]{eqnlines}}
\IfFileExists{delimset.sty}{\RequirePackage{delimset}}
\makeatletter
% The following sometimes helps, but breaks other cases
% \edef\m@th{\unexpanded\expandafter{\m@th\donotcoloroutermaths}}
\let\beamer@orig@mathsm@sh=\mathsm@sh
\def\fix@mathsm@sh#1#2{\donotcoloroutermaths\beamer@orig@mathsm@sh{#1}{#2}}
\def\fix@mathmeasure#1#2#3{\setbox#1\hbox{\donotcoloroutermaths\m@th$#2#3$}}
\def\fix@dlm@big@choice#1#2#3{\hbox{\donotcoloroutermaths
$\m@th\nulldelimiterspace\z@#1\left#3\vcenter to#2\delimsize{}\right.$}}
\def\fix{
\let\mathsm@sh=\fix@mathsm@sh
\let\@mathmeasure=\fix@mathmeasure
\let\dlm@big@choice=\fix@dlm@big@choice
}
\makeatother
\begin{document}
\newcommand{\trycase}[2]{
\ifcase#1\relax
\or
\begin{frame}{#2: inside}
inline: $\red x=y$\par
\textbackslash parbox: \parbox{5em}{$\red x=y$}
\begin{latexequation} \red x=y \end{latexequation}
\begin{equation} \red x=y \end{equation}
\begin{align} \red x&\red=y \end{align}
\vfill
\textbf{expect:} all math red; numbers: default/display/red (?!)
\end{frame}
\or
\begin{frame}{#2: outside}
\red
inline: $x=y$\par
\textbackslash parbox: \parbox{5em}{$x=y$}
\begin{latexequation} x=y \end{latexequation}
\begin{equation} x=y \end{equation}
\begin{align} x&=y \end{align}
\vfill
\textbf{expect:} everything red; numbers: display/red (?!)
\end{frame}
\or
\begin{frame}{#2: nested inline}
latex \textbackslash big: $\red\latexbig( x=y \latexbig)$ \par
amsmath \textbackslash big: $\red\amsmathbig( x=y \amsmathbig)$\par
\ifdefined\brk delimset \textbackslash big: $\red\brk!{ x=y }$\par\fi
\textbackslash smash: $\red x=\smash{y}$ \par
aligned: $\red\begin{aligned} x&=y \end{aligned}$\par
pmatrix: $\red\begin{pmatrix} a&b\\c&d \end{pmatrix}$\par
\textbackslash sqrt: $\red\sqrt[n]{x}$ \par
within display
\[\amsmathbig( x=y \amsmathbig) \]
inline within text within display
\[\text{text $\amsmathbig( x=y \amsmathbig)$} \]
\vfill
\textbf{expect:} all inline math red, display math default
\end{frame}
\or
\begin{frame}{#2: eqnlines}
default colors:
$\< x&=y \>$
\<[1,!] x=y \>
\<! x& =y \>
red: $\red \< x&=y \>$
\par
text red: \red
$\< x&=y \>$
\<[1,!] x=y \>
\<! x& =y \>
\end{frame}
\fi
}
\newcommand{\trygroup}[1]{
\begin{frame}[c]\centering\huge\bfseries
\ifcase#1\relax
\or
inside
\or
outside
\or
nested inline
\or
eqnlines
\else
end
\fi
\end{frame}
\begingroup
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\trycase{#1}{no math text color defined}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\setbeamercolor{math text inlined}{fg=blue}
\trycase{#1}{inline math text color defined}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\setbeamercolor{math text inlined}{fg=blue}
\setbeamercolor{math text displayed}{fg=gray}
\trycase{#1}{pair of math text colors defined}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\fix
\trycase{#1}{some structures repaired}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\endgroup
}
\trygroup{1}
\trygroup{2}
\trygroup{3}
\ifdefined\equations\trygroup{4}\fi
\trygroup{5}
\trygroup{6}
\end{document}
\setbeamercolor{math text}or\setbeamercolor{math text inlined}changes the color of inline math$...$as intended, but it also affects/resets the color in internal constructs of LaTeX or packages which use inline math (typically as$\m@th ...$). Examples are\smash,\root,\sqrt,\big,\Big, etc., but also thepmatrix,aligned,gatheredenvironments of amsmath and probably many more. When this happens, it is difficult to readjust the undesired behaviour at the user level.There are many combinations that lead to different behaviour which is not easy to describe conclusively. Hence I have created a test file that shows many cases along with some general expectations, see below. Some displayed combinations work as intended, others not, so this may be useful for testing and bugfixing purposes.
Further comments:
equationvs.gatherandalignand whether both math text colors are the same or different). It's not even apparent what the desired behaviour might be here. I'd say eithermath text displayedor color of surrounding text (or a new category math text tags), but notmath text inlined\text, however, does not appear to set the inline math color. Shouldn't it?\setbeamercolor{math text}changes color of\textsubscript#382.General question:
Packages may avoid the undesired behaviour by injecting
\donotcoloroutermathsin their internal math constructs. The question here would be whether they should make such compatibility adjustments when beamer or beamerbasecolor is loaded or whether they should rather rely on beamer to avoid the undesired color resets. One might try to do this within\m@thwhich indicates an internal construct, but it's rather too late because the math text inline color is already set by then.A general solution might be to disable math text colors when nesting, i.e. when a math text color has already been set in the present scope (
\@parboxrestorecould reenable where nesting is desired). Alternatively, beamer could implement within\m@ththe undo of a color set from within\everymath? Not sure whether that makes any sense.Test file: output beamer-math-color.pdf log beamer-math-color.log