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
