[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setting the number of pages for a score

From: Han-Wen Nienhuys
Subject: Re: setting the number of pages for a score
Date: Wed, 15 Feb 2006 00:40:58 +0100
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)

[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 - address@hidden -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]