On Wed, 2010-04-21 at 20:37 -0400, Boris Shingarov wrote:
> What makes me really depressed about the situation with pure-height, is
> that we have fixed a number of "reasonable" bugs in this area
> (intersystem begin/rest, overridden stem length, deprecated space,
> padding of markup -- these are the ones that I did in the immediate
> past, -- the slur fix from Joe yesterday, and I also recall a bunch of
> other fixes in this area in the last few months), but we are not only
> not closer to having reasonable trouble-free page layout, but starting
> to look at page overfill/underfill problems which are very deeply
> rooted in the nature of pure-height estimation.
>
> So much so that I am starting to think that sacrificing the benefit of
> linebreaking/pagebreaking integration in the sake of always running
> real (non-pure) height, would be the path to having a reasonable layout
> for our book. That is, calculate the line breaks disregarding page
> breaking; calculate tallness of all lines; then run the page breaking
> algorithm.
>
You are welcome to add a variable in the paper block to allow this sort
of behaviour. It used to be that setting system-count would fall back to
non-estimated heights, but people complained (see bug 325) because it
stopped vertical stretching from happening, which is a deal-breaker for
orchestral and choral scores. You also wouldn't be able to get good page
turns (which was my original motivation for integrating the page- and
line-breaking).
You might want to modify the page-breaker to accept skylines. As far as
I remember, the page-breaker has always been extent-based (even when
those extents were not estimated) whereas the page layout is
skyline-based, so it can space things more tightly.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
