Re: Draws a line above footnotes (issue4167063)

[Mike Solomon]

On Feb 22, 2011, at 7:17 PM, address@hidden wrote:

> On 2011/02/22 15:23:00, MikeSol wrote:
>> On 2011/02/22 01:05:49, joeneeman wrote:
>> > Why not make the separator a (stencil-valued) property of the
> paper-book?
> 
>> I could, but currently, this patch employs its current stencil kludge
> for the
>> following (perhaps-unfounded) reason.  Please let me know if I am
> correct in
>> worrying about this.
> 
>> The page spacer, when it is calculating rod_height_, takes into
> account the
>> height of footnotes in the current patch.  However, it also needs to
> take into
>> account the height of the footnote separator.  If the height and
> padding of this
>> separator is encoded in the paper-book, there will be no way for the
> page spacer
>> to have access to this information (I think...).  Is there a good way
> to get the
>> spacer this info w/o more kludgery?
> 
> If you give Page_breaking a public accessor for its paper-book, then you
> can access it in Page_spacing. For performance (because
> Page_spacing::calc_force gets called a lot), it's probably best to
> access the stencil and cache its height in Page_spacing's constructor.
> 
>> On 2011/02/22 01:05:49, joeneeman wrote:
>> > Have you checked the performance of this? This part is linear and so
> it makes
>> > break_into_pieces quadratic. Also, you can make it simpler by
> iterating
>> through
>> > "all-elements" instead of recursing through "elements".
> 
>> I've made the change to iterate through all-elements, but I still need
> to
>> measure the performance of the algorithm.  How would I do this?
> 
> The change to all-elements was just for simplicity; I still think it
> will be quadratic. You can do a profiling build with
> ./configure --enable-conf=prof --enable-profiling --disable-optimising
> make conf=prof
> (and the binary will be out-prof/bin/lilypond). You can also just time
> lilypond on a largish score (ie. multiple minutes of processing time).
> You can find such scores on the mailing list if you don't have one; Hu
> Haipeng often sends them. Or you can try Valentin's opera, but that's
> more like multiple hours of processing time...
> 

You're right - it takes a long time :(

Perhaps it'd be wise to make a footnote switch that allows users to opt-out of 
this slowness.

The problem is that I'm having trouble drafting a footnote engraver because 
said engraver would (in theory) need to access grobs' systems, which are not 
available when translation happens.

Alternatively, is there a grob that I can acknowledge during the translation 
process that will always exist and will be easily accessible from the systems?  
If so, I can just use the pointer group interface to create a grob array of 
footnoted grobs.

Cheers,
MS