# color / xcolor bug – changing geometry

Can you reproduce this xcolor bug?

\documentclass{article}
\usepackage{xcolor}
\begin{document}
$X_{a}^{b}$\par
$X_{\color{red}a}^{b}$
\end{document}


pdfLaTex, LuaLaTex, XeLaTex, all create the same result. Even switching to the color package does not solve it.

• Is your :-) intended to mean irony? (I think so, but am not 100% sure. If not, could you mention any sensible use case for that feature). Apr 2, 2015 at 10:57
• I'll rephrase: It's a documented feature (so not really a bug) that colour support can sometimes adversely affect spacing. Using \textcolor (or simply an extra group) usually helps, details to be found in grfguide.tex and color.dtx in the latex distribution. Apr 2, 2015 at 12:19
• That is disappointing. The LaTeX community is proud of a professional, robust typesetting system – and still, since decades (?) we cannot get this command right? The most-prominent command for doing something as basic as switching document color has side-effects? Really? Many of us would laugh out loud if a Word user told us that his text geometry changed when applying a color. Apr 8, 2015 at 18:15
• A word document from the 1980s probably isn't processable in any real way in the current system, sometimes there is a price to be paid for stability. It's fixable with difficulty in the macro layer but not in a way compatible with current documents or packages (see l3galley for some experimental code in that direction) or it is fixable by rewriting the engine if you can persuade people to move off TeX (luatex has some support for colour as an attribute of the font, which avoids most of these problems) Apr 8, 2015 at 18:40

Use \textcolor instead of \color and it is expected result (not the bug)
\documentclass{article}
$X_{a}^{b}$\par
$X_{\textcolor{red}{a}}^{b}$