Old font command support: \rm, \sf, \tt, \bf, \it

[edemaine]

This fixes #252 by supporting old LaTeX (2.09) \rm, \sf, \tt, \bf, \tt commands. (\sl and \sc aren't supported because their analogous \textsl and \textsc aren't supported in KaTeX, from lack of fonts.) These old (LaTeX 2.09) font commands are defined in article.cls as follows:

\DeclareOldFontCommand{\rm}{\normalfont\rmfamily}{\mathrm}
\DeclareOldFontCommand{\sf}{\normalfont\sffamily}{\mathsf}
\DeclareOldFontCommand{\tt}{\normalfont\ttfamily}{\mathtt}
\DeclareOldFontCommand{\bf}{\normalfont\bfseries}{\mathbf}
\DeclareOldFontCommand{\it}{\normalfont\itshape}{\mathit}
\DeclareOldFontCommand{\sl}{\normalfont\slshape}{\@nomath\sl}
\DeclareOldFontCommand{\sc}{\normalfont\scshape}{\@nomath\sc}

The last argument is how they behave in math mode. For example, \rm xxx behaves like \mathrm{xxx} in math mode but \normalfont\rmfamily xxx (not supported by KaTeX) in text mode, whereas \sl xxx behaves like \textsl{xxx}.

I also noticed that the parsing of implicit groups didn't correctly parse spaces. For example, \text{x\large y} outputs a space in current KaTeX, but not LaTeX (the space is part of the macro name). This is now fixed for size and styling commands, in addition to the newly supported old-font commands.

This was surprisingly easy to implement -- unfortunately, because existing font commands (e.g. \textbf) are implemented as if they are full-reset commands (like \bf), whereas they are only supposed to set one aspect of the font. That's for another issue... (#676)

[gagern]

LGTM. It might make sense to add a comment about how building these old commands on \text… relies on the broken behavior of the latter, and would need adjustment when that gets fixed. But we have it in the bug and in the screenshot, so a comment is not vital. We probably should move the consumeSpaces implementation to the MacroExpander at some point, as any space after any command gets eaten. But that can be in a follow-up PR once #605 has landed.

[edemaine]

Thanks! Agreed, hopefully #676 keeps track of this. And certainly feel free to move consumeSpaces (I was surprised this wasn't a function already), even in #605.