bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lyrics break estimation of vertical spacing


From: Joe Neeman
Subject: Re: Lyrics break estimation of vertical spacing
Date: Fri, 19 Mar 2010 13:39:36 -0700

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]