# A “math font error” I fixed but, don't know what was wrong

I was typing my homework and got this error:

! LaTeX Error: \mathfrak allowed only in math mode.

Recently I added some macros to my macro file that gives mathfrak text when used so, I figured I must have used that command without using math mode. I looked around and saw that since I last compiled I had not used that command, so I start commenting out stuff till my document would compile. Anyway long story short it looked like when my document got over a page it would output the error and not compile. I confirmed this by opening a new document (a template I use) that loads my macros file and typed a bit, then made a new page then typed a bit, no math at all, and it would output the same error.


I would like to know why it would only output an error after a page. Also it would be cool to know how I could get the \sl command I defined without that undesirable behavior.

Edit: Here is an example

\documentclass[a4paper,10pt]{article}
\usepackage[utf8]{inputenc}
\usepackage{amssymb}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\sl}{\mathfrak{sl}}
\begin{document}
P
\end{document}


For some reason this example doesn't need a second page. Also it looks like the error has something to do with fancy.

• \sl gives slanted text and it is already defined. You may use \newcommand{\Sl}{\mathfrak{sl}} instead. – user11232 Feb 9 '14 at 7:59
• Welcome to TeX.SE! The command \sl, while OK in Plain-TeX documents, is considered deprecated for LaTeX documents; use either \textsl{…} or {\slshape …} instead of \sl. However, since you're not actually looking to use slanted glyphs, it's best to stay away from this command; in particular, do not try to redefine the command \sl, as doing so may break other things in your document. Instead, use a name for your macro; \sla will work, though I'd like to encourage you to find a more mnemonic name that's not already been taken. – Mico Feb 9 '14 at 8:03
• I think this has nothing to do with the fact you changed \sl to \sla. In the first case you were using \sl outside math mode. This is the error you got. And anyway, as said in other comments, don't redefine \sl – karlkoeller Feb 9 '14 at 8:04
• Welcome to TeX.SE! Please try to give the minimal working example (MWE) in which your problem occurs. Creating it is the first step in debugging and helps us tremendously in pin-pointing where the issue may lie. In particular it should start with \documentclass and end with \end{document}. – bodo Feb 9 '14 at 8:17
• @PaulPlummer - Because \sl is a fairly low level (as well as well-established, though deprecated) command, it may still be in use in various LaTeX packages, whether loaded explicitly by you or by other packages that are in use. Redefining the \sl macro may therefore cause unexpected and unforeseeable problems. It sure looks like you've encountered one such problem, and more might be lurking. That's why I recommend you not redefine the \sl command at all and, rather, come up with an entirely new name for your shortcut macro. – Mico Feb 9 '14 at 8:36

Thanks for posting an MWE that generates the problem behavior you're looking to fix.

The problem -- i.e., the error message about \mathfrak being used outside of math mode -- seems to arise because you're also loading the fancyhdr package: Comment out the instructions \usepackage{fancyhdr} and \pagestyle{fancy}, and no more error message is produced.

Sure enough, inside the file fancyhdr.sty, one finds the following instructions:

\if@twoside
\else
\fi


Given that \sl really shouldn't be used in LaTeX documents anymore, the best solution would be for the package to be amended to use \slshape instead of \sl in the code shown above. The next best solution -- and the one that's available immediately -- is for the user (you!) not to try to redefine \sl in the first place.

Update March 2020: At some point since I originally wrote this answer, the fancyhdr package was updated to use \slshape rather than \sl in all four instances shown in the code chunk above. The following paragraphs are thus mainly (hopefully...) of general interest; however, they no longer describe the current properties of the fancyhdr package.

What is it about the command \sl -- and the related font-changing commands \rm, \sf, \tt, \bf, \it, and \sc -- that makes them "deprecated" for use in LaTeX? For one, these commands are no longer defined in the LaTeX "kernel" (i.e., you won't find them in the file latex.ltx in your TeX distribution) but only in "class" files, e.g., in article.cls. Second, to the extent the command \sl is defined at all, it's generally set up as follows:

\DeclareOldFontCommand{\sl}{\normalfont\slshape}{\@nomath\sl}


(The macros \normalfont and \slshape, naturally, are defined in the LaTeX kernel.)

This definition of \sl, which invokes \normalfont before \slshape, is deliberately crafted to mimic the action of the original Plain-TeX \sl macro. Because of the presence of the \normalfont instruction -- which executes the four instructions \encodingdefault, \familydefault, \seriesdefault, and \shapedefault -- one cannot "combine" several old-style font declaration commands. Thus, an instruction such as \bf\it will not create bold-italic output; it will only create italic output. (Similarly, \it\bf will only create bold output.)

One of the (many) advantages of using \bfseries\itshape instead of \bf\it is precisely that it lets you "combine" the two font-changing commands. (Of course, if the font family in use doesn't provide bold-italic glyphs, TeX/LaTeX can't employ them. However, the availability of specific combinations of font weights and shapes is an entirely separate issue.)

• The code in fancyhdr.sty should be changed. Another possibility could be to define the header in the document, but the possibility that another non updated package calls \sl would still be there. :-( – egreg Feb 9 '14 at 10:10
• @egreg - I agree with you that the code in the fancyhdr should be changed. But, as you say, there are lots and lots of LaTeX packages out there that still use the deprecated font-changing commands. I suspect that tracking down all deprecated commands used in files stored on the CTAN, contacting the packages' maintainers, and asking them to update the deprecated code is a task that even Hercules would take a rather long time to achieve. (No diversion of rivers allowed -- or possible...) – Mico Feb 9 '14 at 10:28