Unfortunately, I'm about to go out of town for the weekend, so I don't
have time right now to follow this up properly. But I've left a couple
of hints below.
On Fri, 2010-03-19 at 11:05 -0400, Boris Shingarov wrote:
> On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
>
> > It's nice to see someone else touching the page-breaking code
>
> The more I dig into it, the more questions I have.
> Back in January, we talked about vertical space estimation in the case of
> Prob (i.e. markup); now I am investigating vertical space estimation for the
> case of Grob (i.e. score). The problem is that when the user tries to fit
> more systems on the page by decreasing the spacing/padding, the final page
> layout does take it into account, but it has no effect on the estimations at
> the page-breaking stage. The visual result is that the lines do get closer
> together, but the number of lines per page still remains the same, leaving a
> big empty gap at the bottom of the page.
>
> This problem is caused by the calculation of ext_len in the "for (i=...)"
> cycle in Page_breaking::min_page_count().
> For illustration, I have attached two examples: simple-nolyrics.ly, and the
> same score with added lyrics, simple-lyrics.ly. When there are no lyrics,
> the estimation works as expected. The ext_len in this case is 7.947, and the
> specified padding of 1.2 causes the systems to be nicely squeezed together.
> Now if we add lyrics, the final spacing and the estimation start to diverge
> dramatically. In the final layout of the page, the lyrics do not cause a
> significant change to the distance between the systems: the lyrics just sit
> in the gap which was already there. But the estimator, during the page
> breaking, get confused: for each line, the rod is lengthened by ext_len
> padding, and ext_len in this case is as much as 10.203. So the page breaker
> thinks that the systems are much taller than they will finally prove to be
> when the final spacing is done.
The estimated height for the whole system _should_ take into account the
fact that the lyrics can be squeezed between the systems. Have a look at
the comment in align-interface.cc:104 (which should get called as a
result of sys->pure_height()). The begin_of_line_extent should be zero
for lyrics, which should allow the lines to be close together in the
height-estimation procedure.
> Trying to do something about this ext_len problem, I traced the origin of
> the ext-len back to the Y-ext of the Grob (fill_line_details() calls
> sys->pure_height(), which calls get_property_data("Y-extent")). Bien sûr,
> the Y-extent includes the whole height of the lyrics.
>
> I am not sure what can be done to reconcile the estimator with the actual
> spacing, so that users can get tight spacing. My understanding is that the
> final spacing actually tries to avoid skyline collisions; the page breaker
> ignores the actual shape of the skyline and treats the systems as solid
> rectangular blocks. So the only possible workarond would be to manually
> indicate the ext_len to the page breaker (something like, a block variable in
> the score layout) -- extremely ugly, and I would only opt for that if I knew
> for sure that all other options were exhausted.
There is a workaround, but it's hacky: do something like
\paper {
page-breaking-between-system-spacing #'padding = #'-5.0
}
The page-breaking-between-system-spacing variable was added exactly for
this situation, so that you can override the page breaker's estimations
in case they're off. But you only get to plug in a single value for the
whole \book.
Cheers,
Joe
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
