[I'm taking the liberty of CC-ing the devel list.]
Joe Neeman wrote:
If I understand corrrectly, your page breaker tries to put everything
on one page by unless you say \allowPageBreak, which does not seem
like a sensible default.
Two pages, actually, but yes. I think this is the only possible default
(but of course it should handle problems more gracefully). If you
actually want to restrict the position of possible page turns (to a
small number, usually), I think the only possibility is to assume that
page turns are not allowed unless explicitly marked (or determined
automatically as being possible turns if there is a good way of doing
that).
Can't we use some sort of penalty mechanism, where allowPageBreak is a
huge bonus, so it automatically has the effect of forcing a page-break
where specified (and disallowing in the vicinity, since two page-breaks
in close succession lead to very stretched pages).
Then we could automatically assign bonuses to rests, depending on their
length. If you want to be tempo-independent, you could take the length
relative to the average or longest rest in the piece.
Since enabling this page-breaker requires user intervention anyway, I
think it's ok to require them to also mark possible page turns.
Maybe it wasn't clear, but I don't propose this page breaker to
_replace_ the original page breaker. This one is designed to do page
turns nicely and I can think of many examples of music where bad page
turns don't matter (anything where you have your hands free, for
example) and the original page-breaker would be faster and more suitable.
Maybe I wasn't clear, but experience shows that solutions that aren't
switched on by default get used seldom. Consequently they develop
bit-rot and bugs as we refactor the rest of the code around it. That's
why we make sure that we don't duplicate code. If performance is a
problem, we should devise some sort of fall back mode, which does use
the same code, but takes some more efficient short-cuts.
Come to think of it, the current page-breaking and line-breaking
algorithms are actually two instances of the same problem, and if we can
unify their code, I'm all for it. If we do that, adding a
restrained breaker would give us restrained page-breaking for free :)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
