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 [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
