On Dec 15, 2007, at 5:54 PM, Richard Fateman wrote:
Hi Richard,
> John Foderaro wrote a program to break up expressions in Macsyma for
> use by
> "eqn" (a predecessor to the TeX equation processor). It is not
> clear you
> are aware of it (1978, "photot").
I was not - thank you for bringing it to my attention. My na?ve search
on Google only brought up references to it so I have asked my
librarian to work some magic.
> You may perhaps think it is not relevant
> since it did not take TeX to TeX, but the same issues of automatic
> layout
> were addressed.
There are many tricky parts in the implementation of breqn but the
real problems are with choosing layouts automatically. I wrote my
bachelor's thesis on this subject earlier this year and when I started
pondering the issues, I found myself raising more questions than I
answered. :-)
> The time taken for breqn's algorithm would be of some interest -- is
> it
> potentially exponential in the size of the expression?
I have not done an analysis of this but there is certainly potential
(no pun intended) for something bad happening to the runtime of the
algorithm, especially if a large fragment comes last so that the
layout has to change from step ladder to straight ladder. I am in the
process of changing the data structures within the package so that it
can perhaps be possible to detect some things without having to do
oodles of trial typesetting passes. We shall see...
There is also a somewhat weak point in the algorithm when choosing
whether one should go for a straight ladder or drop/skew ladder
layout. Currently the lhs is allowed to take up a factor of the
available line width. One thing is to choose this factor but one
should IMO also have an absolute length involved just as there is both
\delimitershortfall and \delimiterfactor for \left-\right.
> Fallback results might also be of interest. if an expression cannot
> be
> broken at an OP and gets too long, what happens?
> Just overly-long lines? Too long for the paper?
If all else fails, e.q., there is a rhs fragment of size larger than
\textwidth, it'll just stick out in the margin. When it does this, it
is because there where no binary operations or that they were wrapped
up in a fraction or square root or similar. I have thought about
splitting such square roots up into two lines in those cases if
possible. In most cases the problem can be solved by inserting a
discretionary multiplication.
> The idea of imaxima is attractive to me, but I have hesitated to use
> it
> because of early experience with breqn (when it did not work well at
> all).
> Perhaps it is time to try the new breqn and imaxima.
It works now except there is a problem with equation number placement
(vertically). I will fix this asap.
Best,
Morten
Maintainer email for questions regarding the "mh" packages
on CTAN: breqn, empheq, mathtools, etc.