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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
