Breaking equations with breqn

Question

I am new to using the breqn package. It looks good, but I get an odd behaviour when an equation can almost fit in the page but not quite: the alignment gets completely wrong. Is there a way to fix this?

For the example, I used the minipage environment at various sizes. \fbox is only there to show the borders.

Compiling the example below gives good results for small sizes and big sizes, but for 15em, 16em and 17em,the second equation gets out of the box.

\documentclass{article}
\usepackage{breqn}

\newcommand{\myequation}[1]{
  \fbox{
    \begin{minipage}{#1}
      Size #1:
      \begin{dgroup*}
        \begin{dmath*}
          (x+\cdots+y+\cdots + z) - (x+\cdots + z) = 0
        \end{dmath*}
        \begin{dmath*}
          A = 0 
        \end{dmath*}
      \end{dgroup*}
      Text
    \end{minipage}
  }
}

\begin{document}

\myequation{5em} \qquad \myequation{6em} \qquad \myequation{9em} \\
\myequation{13em} \qquad \myequation{15em} \\
\myequation{16em} \\
\myequation{17em} \\
\myequation{18em} \\
\myequation{30em}

\end{document}

With some versions of breqn and the expl3 bundle, the following code may need to be added to the preamble:

\ExplSyntaxOn
\cs_set_eq:NN \intexpr_eval:w \int_eval:w
\cs_set_eq:NN \intexpr_eval_end: \int_eval_end:
\ExplSyntaxOff

Answer 1

To understand what is happening here, I cleaned the code a bit and used colored rules than fboxes. I have also used a loop to typeset the various boxes. This way it was easier to modify the widths and see what is happening at the transition points.

Firstly, we view a typeset box that has an adequate width to handle the equations. We see that it correctly typesets these, aligning them at the equal sign and centering them.

Now what happens when we change the width of the box? TeX starts squeezing the first equation to fit within the width constraints. For the second equation though, since it fits it will keep the width of the box constant. Oops! the two equations do not align anymore, but have small differences until about 185pt when the first equation is stretched to what TeX thinks is a good equation display.

Next we view the logical issues in the breqn algorithm by forcing a break at a 160pt width and typesetting the following boxes to have some visual clues:

It is obvious that the original good position marked to break the equation and at which the second equation is aligned is based on the unstretched  first equation. This should have gone through another iteration and be checked against the new position of the equal sign or a trigger should have been switched to let TeX take over and position the second equation at its natural position. A bad combination of hsize and the type of equations entered can also create a problem that is intractable and will just produce a badly typeset box Q.E.D?

Here is a new MWE:

\documentclass{article}
\usepackage{flexisym}
\usepackage{xcolor,lipsum}
\usepackage{breqn}
\overfullrule1pt
\fboxsep=0.4pt
\def\myequation#1{%
     \hbox to 0pt{\color{orange}\rule{#1}{2pt}}   
       \hsize#1
        Size #1:%
      \begin{dgroup*}[frame={0.4pt},framesep=0pt,compact]
         \begin{dmath*}
          (x+\cdots+y+\cdots + z) - (x+\cdots +2) = 0
        \end{dmath*}
        \begin{dsuspend}
          and
       \end{dsuspend}
        \begin{dmath*}[frame={0pt}]
         a=0
        \end{dmath*}
      \end{dgroup*}
    \hbox to 0pt{\color{orange}\rule{#1}{2pt}} 
}
\parindent0pt
\begin{document}
\makeatletter
\@for\next:=160pt,165pt,190pt\do{%
   \hsize\next
    \myequation\next\par
 }
\end{document}

To fix it, requires manual intervention (just for the problematic ones), modify as follows:

  \begin{dmath*}[frame={0pt}]
    $a=0$
  \end{dmath*}

to left align or \hbox to 91pt {\hfill $a=0$} to align, the 91pt was found by trial and error.

You can use Patrick's \usepackage{lua-visual-debug} to see the final boxing:

Note the box has been drawn with the corrected parameters, as explained above.