On 05/20/2014 03:14 AM, Waldek Hebisch wrote:
> TeX exposens enough primitives to do this in a macro. One can try to
> optimize breakpoints, for examples associating penalty with each
> breakpoint (say, more nested operator has bigger penalty), but this
> may be much more crude than for text (because no one expects formulas
> to line up with margin). I do not know why breqn has such problems.
I think, that is exactly what breqn is doing, but it's a bit more
complicated. Things like \left(...\right) are usually internally put
into an unbreakable \hbox by TeX (or LaTeX). breqn must count \left's
and \right's so that these expressions possibly are kept together. You
cannot simply put an equal penalty on every + to find a reasonable
breakpoint.
However, it's not even that easy. Think of something like
a + \frac{b}{c} + \frac{d}{e} + f
By which rule would you go if the denominator of c is too long to fit
a + \frac{b}{c}
onto one line, but if you break up c into 3 lines, say, and the
numerator d into 3 lines then even f would fit into the line, i.e. best
looking would be an expression that breaks inside the fractions.
Breaking up c into only two lines would not achieve this.
Fortunately, we don't have something like that in the output for the
book, but I find the above problem hard to solve no matter whether in
TeX or TeXFormat.
Ralf
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
