6

I got a strange bug using the two aforementioned packages when I try to build the TOC. The bug happens only after I typeset twice with pdfLaTeX and forbids me to build the TOC.

Edit : following comments and answer from cfr I post here a better MWE that shows the problem actually comes from a conflict between amsart and mathalfa when building the TOC and using some specific options ... I would really like somebody to find a way of correcting this conflict ...

\documentclass{amsart}
\usepackage[frak=boondox]{mathalfa}
\begin{document}
\tableofcontents 
\scriptsize $u$
\section{$\mathfrak{m}$}
\end{document}

And below here is an extract of what I get as a message on my console window.

Use of \reserved@a doesn't match its definition.
\reserved@b ->\relax 
                     \ifmmode \else \non@alpherr \mathfrak  \fi \use@mathgro...

Edit 2: does anybody know if and when this bug could be corrected ? (in Latex or in the mathalfa package ?)

5
  • 1
    I have edited your subject but don't like to edit your content too much. I suggest editing it yourself as TikZ does not seem to have anything to do with the error, but amsart does. Feel free to use the MWE I've put in an answer below if you wish. If you do so, please ping me and I will delete it as it is not an 'answer' but is too long for a comment.
    – cfr
    Jul 25, 2015 at 2:18
  • \scriptsize does not take an argument. It is a switch. {\scriptsize usual work} is probably what you want. Do you want me to delete my answer now? I'm happy to do so - I'm just not sure if that's what you'd like me to do or not since we've got discussion going in comments with barbara. (barbara can help you if anybody can.)
    – cfr
    Jul 25, 2015 at 15:19
  • @cfr If I use properly \scriptsize as a switch the bug disappears .... unless I put the content in {} or $...$. I like your answer because it did a much better work than I did with my first MWE to pinpoint the true conflict. Unfortunately, if somebody find a way to correct it using the same packages I will mark it as the complete answer I was looking for. Thank you for your help !
    – brunoh
    Jul 25, 2015 at 15:31
  • That's odd. It does not disappear for me. But you do need to invoke maths mode, definitely. Anyway, your current example uses it as a switch ;).
    – cfr
    Jul 25, 2015 at 16:49
  • The error is produced because amsart defines \mathfrak by loading amsfonts and somehow LaTeX doesn't like to have such commands redefined. The problem shows up when doing a font change because LaTeX makes some global definitions that confuse it because of how math alphabet changing commands are defined. The minimal example is \documentclass{amsart} \usepackage[frak=boondox]{mathalfa} \begin{document} {\small $\mathfrak{m}$} $\mathfrak{m}$ \end{document} I'm afraid there is no way around the problem.
    – egreg
    Jul 25, 2015 at 21:03

2 Answers 2

5

This is a “feature” of LaTeX, I'm afraid.

Since amsart automatically loads amsfonts, which defines \mathfrak; it appears that redefining commands defined with \DeclareMathAlphabet is not possible with the current kernel. The problem shows up with a very minimal document:

\documentclass{amsart}
\usepackage[frak=boondox]{mathalfa}

\begin{document}

{\small $\mathfrak{m}$}
$\mathfrak{m}$

\end{document}

because the font changing command causes \mathfrak to do some global assignments that, in a sense, “resurrect” the previous definition of \mathfrak leaving the system in an unstable state.

Workaround if you don't need the full force of amsfonts:

% pretend that amsfonts.sty has already been loaded
\expandafter\def\csname [email protected]\endcsname{3000/12/31}
% load the msb symbol font that's needed for \dh
\DeclareSymbolFont{AMSb}{U}{msb}{m}{n}
% end of the hack

\documentclass{amsart}
\usepackage[frak=boondox]{mathalfa}

\begin{document}

{\small $\mathfrak{m}$}
$\mathfrak{m}$

\end{document}

Actually, there is a possibly better way to solve the issue, by redefining \mathfrak using \DeclareSymbolFontAlphabet that shouldn't resurrect the old definition, because math fonts defined with \DeclareMathAlphabet use a different mechanism that avoids wasting math families if the alphabet is not used in the document; since you'll be using Fraktur, this doesn't really matter.

The trick is to manually do what mathalfa does automatically, but using \DeclareSymbolFont.

\documentclass{amsart}

\makeatletter
\def\mathalfa@frakscaled{s*[1]}
\makeatother
\DeclareFontFamily{U}{BOONDOX-frak}{\skewchar \font =45}
\DeclareFontShape{U}{BOONDOX-frak}{m}{n}{
    <-> \mathalfa@frakscaled  BOONDOX-r-frak}{}
\DeclareFontShape{U}{BOONDOX-frak}{b}{n}{
    <-> \mathalfa@frakscaled  BOONDOX-b-frak}{}
\DeclareSymbolFont{boondoxfrak}{U}{BOONDOX-frak}{m}{n}
\SetSymbolFont{boondoxfrak}{bold}{U}{BOONDOX-frak}{b}{n}
\DeclareSymbolFontAlphabet{\mathfrak}{boondoxfrak}

\begin{document}

{\small $\mathfrak{m}$}
$\mathfrak{m}$

\end{document}
12
  • Perfectly clear. You explained my problem (which has nothing to do with the building of the TOC by the way) and find a workaround.
    – brunoh
    Jul 25, 2015 at 21:24
  • 1
    @brunoh I added a possibly cleaner workaround
    – egreg
    Jul 25, 2015 at 21:36
  • 1
    @brunoh The new workaround allows loading amsfonts.
    – egreg
    Jul 25, 2015 at 21:38
  • 1
    Or do you need to switch for later reasons...?
    – cfr
    Jul 26, 2015 at 1:35
  • 1
    thankyouthankyouthankyou!!! this is definitely something we will need to be aware of with the new latex in tex live 2015. please send me any other incompatibilities you encounter with the new latex. Jul 26, 2015 at 10:11
2

The error has nothing to do with TikZ. It appears to be an incompatibility between mathalfa, amsart, \scriptsize $something$.... This is not a complete diagnosis but it narrows it down a bit. (At least we can eliminate TikZ.)

Minimal example I can get to reproduce the error:

\documentclass{amsart}% substitute article for working code
\usepackage
  [
    frak=boondox
  ]{mathalfa}% remove frak option for working code

\begin{document}

\tableofcontents% remove for working code

{\scriptsize% remove \scriptsize for working code
  abc $a$ }% remove $a$ for working code

\section{$\mathfrak{m}$}% use text or non-frak maths here for working code
\end{document}

EDIT

Yesterday, I established that copying the relevant lines to configure \mathfrak from mathalfa.sty allowed the code to compile.

\documentclass{amsart}% substitute article for working code
\makeatletter
\def\mathalfa@frakscaled{s*[1.0]}
  \DeclareFontFamily{U}{BOONDOX-frak}{\skewchar \font =45}
  \DeclareFontShape{U}{BOONDOX-frak}{m}{n}{
    <-> \mathalfa@frakscaled  BOONDOX-r-frak}{}
  \DeclareFontShape{U}{BOONDOX-frak}{b}{n}{
    <-> \mathalfa@frakscaled  BOONDOX-b-frak}{}
  \DeclareMathAlphabet{\mathfrak}{U}{BOONDOX-frak}{m}{n}
  \SetMathAlphabet{\mathfrak}{bold}{U}{BOONDOX-frak}{b}{n}
  \DeclareMathAlphabet{\mathbfrak} {U}{BOONDOX-frak}{b}{n}
\makeatother

\begin{document}

\tableofcontents% remove for working code

{\scriptsize% remove \scriptsize for working code
  abc $a$ }% remove $a$ for working code

\section{$\mathfrak{m}$}% use text or non-frak maths here for working code
\end{document}

The above works fine. But notice that I'm using exactly the commands from mathalfa.sty. That is, I'm using \DeclareMathAlphabet. So, it does not appear to be necessary to substitute \DeclareSymbolFontAlphabet as egreg does.

What puzzled me yesterday - and still puzzles me now - is that copying this code does not allow me to reproduce the error. So I think the incompatibility must lie elsewhere.

EDIT EDIT

The code above also allows loading the mathalfa package with other options e.g. cal=boondox except for the definition of \mathbfrak. In order to use that line, you need to undo the existing definition first:

\usepackage[cal=boondox]{mathalfa}
\makeatletter
\def\mathalfa@frakscaled{s*[1.0]}
  \DeclareFontFamily{U}{BOONDOX-frak}{\skewchar \font =45}
  \DeclareFontShape{U}{BOONDOX-frak}{m}{n}{
    <-> \mathalfa@frakscaled  BOONDOX-r-frak}{}
  \DeclareFontShape{U}{BOONDOX-frak}{b}{n}{
    <-> \mathalfa@frakscaled  BOONDOX-b-frak}{}
  \DeclareMathAlphabet{\mathfrak}{U}{BOONDOX-frak}{m}{n}
  \SetMathAlphabet{\mathfrak}{bold}{U}{BOONDOX-frak}{b}{n}
  \let\mathbfrak\relax
  \DeclareMathAlphabet{\mathbfrak} {U}{BOONDOX-frak}{b}{n}
\makeatother

But I'm not at all sure that any of this should work this way - either the bits which work or the bits which don't!

20
  • I am very grateful for your answer and your edit. It saves me hours of work ! The cause of the problem is quite narrowed now, even if it is yet not perfectly explained. Nevertheless I accept your answer as such. I choose not to change too much my initial MWE to show the progress made by your analysis, not by me.
    – brunoh
    Jul 25, 2015 at 8:36
  • @brunoh -- what is the actual problem? if mathalfa is incompatible with amsart, i would like to be able to document this for other users of ams document classes. Jul 25, 2015 at 9:45
  • @barbarabeeton Compilation fails with the error given in the question. Changing font size, typesetting something in maths mode and then using \mathfrak in the argument to \section causes the error. It is quite specific: I can't get a more minimal example than the one I posted. But it does not need to be \scriptsize: \small also fails. \normalsize is fine, though. But issuing \normalsize doesn't help if I've used \scriptsize first. Switching to article resolves the problem - but so does any of the other changes mentioned in my comments on the code.
    – cfr
    Jul 25, 2015 at 13:09
  • @cfr -- i'm not able to test or to look into either amsart.cls or mathalfa.sty from where i am. however, on thinking about where i've seen the reported error message, i would try inserting \protect before \mathfrak. the math font changing commands in the ams packages are (unfortunately) not robust, and \section has a moving argument. so this may be the problem (and it has nothing to do with mathalfa; amsmath and amsfonts are automatically loaded by amsart). the \scriptsize problem is something different though. Jul 25, 2015 at 13:20
  • 1
    @brunoh I am even more puzzled now...
    – cfr
    Jul 26, 2015 at 1:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .