I didn't even know, that it is possible to have a mathematical environment inside of a float environment, which might explain why I never tested it.
Putting an autonum-enabled math environment inside of other non-trivial environments is always a bit of a problem, as the outer environment sometimes needs to support autonum in order to get a correctly working inner environment.
As math environments can contain other math environments, the autonum package already contains two solutions for this sub-problem.
- You can make a zero-argument environment aware of autonum by calling
\autonum@patchFullEnvironment
directly after \begin{document}
using the environment name as a parameter.
- For environments with a mandatory argument
\autonum@patchParametrizedFullEnvironment
should be used instead.
For your needs putting
\makeatletter
\autonum@patchParametrizedFullEnvironment{figure}%
\makeatother
directly after \begin{document}
works with your example as it compiles without errors and the output seems to be correct.
However, when implementing that functionality, I never had in mind to use it for a non-math environment. So to be honest I was even a bit surprised, that this worked out of the box and I am not sure that this does anything remotely useful in corner cases or in a real world document making excessive use of the involved environments in various combinations.
That said, an even bigger problem is, that figure's argument normally is optional and has now become mandatory (which raises all sorts of questions regarding the use of []
and {}
and if the arguments even are correctly used), so it won't compile if you omit figure's optional argument somewhere in your whole document.
It probably would be possible to add a patch command capable of handling an environment with an optional argument, too, but I wonder if that is the best way. As all the patch commands support math environments, they contain a bit of overhead, which is not needed, when patching a non-math environment. This is probably not so much a performance problem but more a compatibility problem, as there are all sorts of environments in the wild and the less patching needed, the higher are the chances that autonum does not break anything.
I have to dig into the code to see if it is possible to implement a simple patch command which can only handle non-math environments. Yet, I am not sure, when I'll find the time to do this due to other commitments, so do not expect a solution too soon.
autonum
do? Commenting that package and uncommenting all the rest makes it work. More weirdly, commenting out the second figure makes it work, too, even withautonum
.autonum
; the loop appears to be caused by the equation numbers in the firstfigure
.