Re: setting the number of pages for a score

[Han-Wen Nienhuys]

Joe Neeman wrote:

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

Sorry, I misunderstood you; I gathered that allowPageTurn was a 
hard-coded obligatory break.

> 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 don't understand what you're saying here; we can just compute the 
optimal solution, can't we? Then manual turns can be made more desirable
than automatic ones, and the optimal solution will balance out even 
spacing with desirable page turns. Are you proposing to add even more 
stages into the algorithm?

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

Yes, I know. But that's a different problem. Let's get a sensible 
breaking algorithm for piano music first. Predicting system-height is 
something that can be done if we have a "copy formatting problem" routine.

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

Yes, but what problem would that solve?



--
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen