Minimal Example that demonstrates the problem:


%%% variable declaration:

%%% conditional stroke \Fconditional[content]{consequent}{antecedent}:
    \rule{0pt}{\baselineskip}% this is a strut
    \rule[-0.3\baselineskip]{0pt}{0.3\baselineskip}% this is a strut


This command does exactly what it is supposed to do as called in in-line maths mode like so:


Thanks to the comment about removing definitions from the macro, the command now also works nested in itself like so:


However if I call the same command within an align* environment like so:


I get the following error message:

! Misplaced alignment tab character &.
\math@cr@@@ ->&
\omit \global \advance \row@ \@ne \ifst@rred \nonumber \fi \i...
l.51 \end{align*}

This happens regardless of whether I actually use any & characters in the align* environment. Ignoring the error produces part of the output.

Sorry I did not include a proper minimal example earlier.

  • 2
    AMS environments are executed twice so that things get measured so all your \new... will generate errors the second internal run. It is almost always a bad idea to have \newsavebox and \newlength inside macros as that means you allocate new registers each time, the intended usage is that you allocate the registers you need at the start and re-use the same registers. Jul 13, 2012 at 15:27
  • OK if you need further help please edit the question so it is a complete document using ams alignment and generating the error. Jul 13, 2012 at 15:42
  • sorry, what you used, I just meant any of align or align* or alignedat etc from amsmath package. But don't just say you get an error in that case, make a document that shows the error. Jul 13, 2012 at 15:54
  • So... moving the \new... commands outside the macro has fixed half the problem. I have updated the question to reflect this, and included a minimal working example. Jul 13, 2012 at 16:40

1 Answer 1


The use of \\ in


makes no sense. There is no "context" there to give meaning to a newline.

Consequently, the \\ is "captured" by the align environment, leading to the error.

I assume you want \temp to assume the maximum width of \Fconsequent and \Fantecedent. Replacing the \settowidth expression by the TeX construct


will do the job. I assume there are more elegant, more LaTeXy ways...

  • That makes sense. And yes, I want \temp to take on the width of the wider of \Fconsequent and \Fantecedent whichever that is. If somebody does still know how to that in a "LaTeXy" way, I would appreciate it... I will have a think about it myself. Jul 13, 2012 at 18:20
  • One not so elegant way to solve the problem that does not rely on pure TeX, is to measure the width of \usebox{\Fconsequent} and \usebox{\Fantecedent} separately using \settowidth{}{} and then placing both lengths as vertical struts into a \makebox{} the height of which is determined by it's contents and can be measured with \settoheight{}{}... Jul 14, 2012 at 0:28
  • You could also use \settowidth{\temp}{\shortstack{\usebox{\Fconsequent}\\\usebox{\Fantecedent}}}% to get a solution which is nearer to your original idea. Furthermore, the ifthen package provides a means to compare lengths in a LaTeXy way. Jul 14, 2012 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.