lilypond-devel
[Top][All Lists]
Advanced

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

Re: Adds automatic numbering to footnotes. (issue4244064)


From: address@hidden
Subject: Re: Adds automatic numbering to footnotes. (issue4244064)
Date: Thu, 10 Mar 2011 11:06:32 +0100

On Mar 9, 2011, at 10:17 PM, address@hidden wrote:

> Hi Mike,
> 
> I've only given this a quick look so far, but it's looking great. :)
> 
> Here are a few thoughts:
> 
> The patch doesn't apply without rebasing `paper-defaults-init.ly'.

Fixed (I think).

> 
> Does `annotation-whiteout' do anything special?  If not, the existing
> property `whiteout' should suffice.
> 

It puts a whiteout only around the annotation instead of whiting out the entire 
grob (line + annotation).

> `reset-footnotes-on-new-page' appears to be broken:
> 
> \paper {
>  reset-footnotes-on-new-page = ##f
> }
> 
> \relative c' {
>  \autoFootnoteGrob #'NoteHead #'(0 . -1) "first head"
>  c1
> }
> 
> \pageBreak
> 
> \relative c' {
>  \autoFootnoteGrob #'NoteHead #'(0 . -1) "second head"
>  c1
> }
> 
> -> "1", "1first head"
> -> "1", "2second head"
> 

Fixed.

> `footnote-auto-numbering.ly' also counts the toplevel markup on the
> second page as "5", continuing the marker sequence on the grobs with
> "2", "3" etc.

Fixed (same problem).

> 
> The random hash you're creating is quite complicated; would a simple
> (gensym "footnote") suffice?
> 

It would indeed - I had no idea gensym existed!

> If a footnote reaches double digits on a toplevel markup, it messes up
> the superscript alignment for all toplevel markup footnotes.
> 

This problem seems unsolvable for footnotes that reset at page breaks (the page 
breaks are calculated, perhaps slightly widening the width of a footnote in a 
justify markup, which pushes this markup to the next line, which changes the 
ideal page breaks, which requires new footnotes, etc.).  I get the sense that, 
if footnotes persist throughout a document, the numbering can be done farther 
upstream, which could potentially solve the problem.  However, even this seems 
difficult: the width of top-level markups is calculated in the "Processing 
graphical objects" stage, while the cached_line_details_ are created for the 
first time during the "Finding the ideal number of pages" stage, meaning that 
I'd need to find a list of all systems in order farther downstream.  I did a 
little digging, and I don't see an easy way to do this without triggering a 
load of unwanted side effects.

Thanks for your help!

New patch posted on-line.

Cheers,
Mike


reply via email to

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