Re: setting the number of pages for a score

[Joe Neeman]

Han-Wen Nienhuys wrote:

> [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).

The problem with this is that having a huge bonus effectively forces a 
page break. I set allowPageTurn to have a penalty of -1 because I don't 
want to force a break -- I only want to allow the possibility of a 
break. Having just manually page-broken 6 string quartets, it is very 
time-consuming to actually look through the piece for possible page 
turns and decide which ones to use (especially because if you change an 
earlier page turn, it messes up subsequent turns).

How about:
- Possible (but not explicitly marked) page turns will be recorded 
(with penalties depending on how good they are).
- The page breaker will start off by only including manual page turns 
and very highly scored automatic turns.
- If the page breaker cannot find suitable breaking, it will gradually 
start introducing less highly scored automatically marked turns.

I want to avoid assigning large penalties to anything because that might 
encourage the breaker to add pages just to get the penalties. I want to 
save penalties for places where there absolutely must be a break.

> > 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.

The problem I'm more worried about is if the system-height is hard to 
predict. An orchestral score, for example, has widely varying system 
height if blank staves are removed. This will completely throw the 
page-breaker.

Maybe I can refactor or rewrite the old page breaker so it uses a lot of 
the same code as this breaker. It could get the typeset systems, put a 
potential page turn at the end of each system, and run those systems 
through the new page breaker.

> 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 :)

There should be a way of combining at least some of the code. I'll think 
about this...