Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

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
share|improve this question
3  
Have you tried contacting the maintainer of the package? Perhaps it is a bug. –  pmav99 Apr 7 '11 at 13:44
    
@Bruno There is a version of breqn on CTAN that is newer than this question. Does it fix the problem? –  Seamus Jul 1 '11 at 14:45
1  
@Seamus: I just installed TeX Live 2011, and it doesn't seem to be fixed. –  Bruno Le Floch Jul 27 '11 at 11:44
    
@Seamus: actually, it seems that the version of breqn on CTAN is v0.98a, from 2009. However, the mh bundle (containing breqn) was updated. Maybe you mistook this update for an update of breqn (its modification date is indeed very recent)? –  Bruno Le Floch Jul 28 '11 at 8:03
    
@Bruno yes looking at this, I think you are right. It seems like the mh bundle being updated gave a newer upload date to the same breqn version. Have you tried contacting the author as pmav99 suggested? This could well be a bug... –  Seamus Jul 28 '11 at 11:00

1 Answer 1

up vote 15 down vote accepted

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.

enter image description here

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.

enter image description here

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:

enter image description here

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.

enter image description here

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

enter image description here

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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