Adds automatic numbering to footnotes.

Adds automatic numbering to footnotes.

[Bertrand Bordage, 2011-03-09 17:38:01]

Hi Mike,

Nice job, as usual !

However, I noticed some obvious problems. You probably already know them.

Here, the padding :
\markup {
  \footnote b c
  \footnote e f
}

Here, the horizontal space between markup and number :
\markup {
  \footnote d e
  \footnote f g
}

Also : why are in-text numbers 0.75\mm higher than footnotes numbers ?

To conclude, this horizontal spacing bug (3 spacing bugs in 1) :
\markup {
  \footnote a a \footnote a a \footnote a a
  \footnote a a \footnote a a \footnote a a
  \footnote a a \footnote a a \footnote a a
  \footnote a a
}


Now, some suggestions :

Can you create another "footnote-numbering-function" that prints "1. blablabla"
instead of the raised numbers ? Maybe with an argument to define whether there
should be a space after the dot.
Optionally another that handles "[1] " notation.
And maybe a property to change font-series and font-shape for these numbers
(those that are in the notes). Indeed, some editors use bold "1. " while others
use italic raised numbers.

There is often a no-break thin space between a word and its note number in
french editions (Flammarion, Le livre de poche, etc).

It would be great if we could this input :
\markup \footnote a { bla bla bla bla bla bla [many others] bla bla bla bla bla
bla }
instead of :
\markup \footnote a \justify { bla bla bla bla bla bla [many others] bla bla bla
bla bla bla }

And it would be even greater if we could use :
\markup a \footnote { bla bla }
instead of :
\markup \footnote a { bla bla }

I know this last issue is very tricky... And it has a low priority.

And again, great job !

Regards,
Bertrand

[mike_apollinemike.com, 2011-03-09 19:13:20]

Thanks for the helpful comments!  Responses inlined below.

On Mar 9, 2011, at 6:38 PM, bordage.bertrand@gmail.com wrote:

> Hi Mike,
> 
> Nice job, as usual !
> 
> However, I noticed some obvious problems. You probably already know
> them.
> 
> Here, the padding :
> \markup {
>  \footnote b c
>  \footnote e f
> }
> 
> Here, the horizontal space between markup and number :
> \markup {
>  \footnote d e
>  \footnote f g
> }
> 

This is not untrue...I'll need to study the code a bit more to know if this is
elegantly modifiable.  And by "I" I mean "hopefully not just I."
If it is not elegantly modifiable, I think that the best way to handle this (as
annoying as it would be) would be to take every common glyph in the alphabet and
figure out the ideal spacing between it and a footnote.

> Also : why are in-text numbers 0.75\mm higher than footnotes numbers ?
> 

No good reason, but I'd be amenable to changing it to whatever.

> To conclude, this horizontal spacing bug (3 spacing bugs in 1) :
> \markup {
>  \footnote a a \footnote a a \footnote a a
>  \footnote a a \footnote a a \footnote a a
>  \footnote a a \footnote a a \footnote a a
>  \footnote a a
> }
> 

Yikes...I'll get on that!


> 
> Now, some suggestions :
> 
> Can you create another "footnote-numbering-function" that prints "1.
> blablabla" instead of the raised numbers ? Maybe with an argument to
> define whether there should be a space after the dot.
> Optionally another that handles "[1] " notation.

Yup!  I'll work on that tomorrow.

> And maybe a property to change font-series and font-shape for these
> numbers (those that are in the notes). Indeed, some editors use bold "1.
> " while others use italic raised numbers.

Ditto - I'll make a collection of useful functions.

> 
> There is often a no-break thin space between a word and its note number
> in french editions (Flammarion, Le livre de poche, etc).
> 

I'll look into that (I have Dalloz Code de l'Urbanisme in front of me right
now...ugh....).

> It would be great if we could this input :
> \markup \footnote a { bla bla bla bla bla bla [many others] bla bla bla
> bla bla bla }
> instead of :
> \markup \footnote a \justify { bla bla bla bla bla bla [many others] bla
> bla bla bla bla bla }
> 

Yes, but this hits upon a bigger problem: LilyPond does not handle text very
well.  At a certain point, it may be better to use LilyPond book and use LaTeX's
native text functionalities.

> And it would be even greater if we could use :
> \markup a \footnote { bla bla }
> instead of :
> \markup \footnote a { bla bla }
> 
> I know this last issue is very tricky... And it has a low priority.
> 

True - I'll look into it, though.

> And again, great job !

Thanks!
~Mike

[Colin Campbell, 2011-03-09 21:14:08]

On 2011/03/09 19:13:20, mike_apollinemike.com wrote:
> Thanks for the helpful comments!  Responses inlined below.

Hi, Mike! Part-time patch helper Colin here.

Mike, this patch has somehow poisoned the doc build and also the make test
functionality, neither of which work since the patch was pushed.
Also, I gather this patch is part of your work on issue, so I'll update the
issue and set the status to "Patch needs work".

[Neil Puttock, 2011-03-09 21:17:32]

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'.

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

`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"

`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.

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

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

Cheers,
Neil

[mike_apollinemike.com, 2011-03-10 07:57:50]

On Mar 9, 2011, at 10:14 PM, ColinPKCampbell@gmail.com wrote:

> On 2011/03/09 19:13:20, mike_apollinemike.com wrote:
>> Thanks for the helpful comments!  Responses inlined below.
> 
> Hi, Mike! Part-time patch helper Colin here.
> 
> Mike, this patch has somehow poisoned the doc build and also the make
> test functionality, neither of which work since the patch was pushed.
> Also, I gather this patch is part of your work on issue, so I'll update
> the issue and set the status to "Patch needs work".
> 

Hey Collin,
When you say "pushed," do you mean to say that the auto-numbering patch was
pushed to the master branch?  I don't believe it was...I am looking at my
current master and don't see it, but let me know if I'm wrong!

Also, to respond to your other e-mail, all of my regtests work just fine:
symbol-footnotes is defined in scm/output-lib and gets the desired result. 
Could you try it again and let me know if that works out?

Thanks for your help!

Cheers,
Mike

[mike_apollinemike.com, 2011-03-10 10:06:41]

On Mar 9, 2011, at 10:17 PM, n.puttock@gmail.com 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

[mike_apollinemike.com, 2011-03-10 10:24:52]

On Mar 9, 2011, at 6:38 PM, bordage.bertrand@gmail.com wrote:

> Hi Mike,
> 
> Nice job, as usual !
> 
> However, I noticed some obvious problems. You probably already know
> them.
> 
> Here, the padding :
> \markup {
>  \footnote b c
>  \footnote e f
> }
> 

This is kinda sorta fixed.

> Here, the horizontal space between markup and number :
> \markup {
>  \footnote d e
>  \footnote f g
> }
> 

This is not really fixed and needs some expert tweaking from a font guru.

> Also : why are in-text numbers 0.75\mm higher than footnotes numbers ?
> 
> To conclude, this horizontal spacing bug (3 spacing bugs in 1) :
> \markup {
>  \footnote a a \footnote a a \footnote a a
>  \footnote a a \footnote a a \footnote a a
>  \footnote a a \footnote a a \footnote a a
>  \footnote a a
> }
> 
> 

10 is the magic threshold for cataclysmic footnote failure.  There is currently
no sure fire way to get LilyPond to anticipate a footnote's eventual width and
to deal w/ it accordingly.

I don't think this is a prohibitive gotchya, but it is super annoying.  If
anyone knows how LaTeX deals with this, I'd be interested in hearing about it!

> Now, some suggestions :
> 
> Can you create another "footnote-numbering-function" that prints "1.
> blablabla" instead of the raised numbers ? Maybe with an argument to
> define whether there should be a space after the dot.
> Optionally another that handles "[1] " notation.
> And maybe a property to change font-series and font-shape for these
> numbers (those that are in the notes). Indeed, some editors use bold "1.
> " while others use italic raised numbers.
> 

At a certain point, it may be more useful to suggest some of these things in the
docs rather than include them in LilyPond.

For example, try:

\version "2.13.54"

\paper {
footnote-numbering-function = #(lambda (layout props int) (interpret-markup
layout props (markup #:tiny #:concat ("[" (number->string int) "]"))))
footnote-number-raise = #1.0
}

\markup {
\override #'(raise . 2) {
\footnote b c
\footnote e f \footnote q r }
}

You need a couple tweaks to make this work, and thus, it is difficult to
prepackage it w/o doing a lot of fancy footwork.

> There is often a no-break thin space between a word and its note number
> in french editions (Flammarion, Le livre de poche, etc).
> 

I'm reading "Et que la vaste monde poursuive sa course folle" (Belfond) that
has, on page 184, the footnote:

1.  Le "rendez-vous des chasseurs."

No change of font size, big space between note & text, & the footnote is aligned
downwards.

I'll add something to account for this in the not-too-distant future.

Cheers,
Mike

[Bertrand Bordage, 2011-03-10 11:02:36]

There is still a vertical spacing bug in the footnotes :
\markup {
  \footnote e e
  \footnote e ef
}
There should be a fixed distance between the baseline and the number.

For the thin space, I meant in-text words and numbers :
Cromorne ²
Which is more elegant than :
Cromorne ²
or
Cromorne²

Regards,
Bertrand

[mike_apollinemike.com, 2011-03-10 11:11:56]

On Mar 10, 2011, at 12:02 PM, bordage.bertrand@gmail.com wrote:

> There is still a vertical spacing bug in the footnotes :
> \markup {
>  \footnote e e
>  \footnote e ef
> }
> There should be a fixed distance between the baseline and the number.
> 

The problem is that Lilypond processes graphical objects before it processes
pagination, making it impossible to know exactly how much space a footnote will
take up when the graphical object is processed.

One solution to this problem would be to reprocess all top-level markups with
correct footnotes after having done the pagination, then redo the pagination and
see if all the footnotes stay the same.  If so, keep the current configuration. 
Otherwise, rinse & repeat.  This actually seems kinda sorta doable, although I'd
have to do some homework on how these markups are stored internally and figure
out to what extent these internal representations survive downstream into the
pagination phase.

Cheers,
Mike

[mike_apollinemike.com, 2011-03-11 10:41:56]

On Mar 10, 2011, at 12:11 PM, mike@apollinemike.com wrote:

> On Mar 10, 2011, at 12:02 PM, bordage.bertrand@gmail.com wrote:
> 
>> There is still a vertical spacing bug in the footnotes :
>> \markup {
>> \footnote e e
>> \footnote e ef
>> }
>> There should be a fixed distance between the baseline and the number.
>> 
> 
> The problem is that Lilypond processes graphical objects before it processes
pagination, making it impossible to know exactly how much space a footnote will
take up when the graphical object is processed.
> 
> One solution to this problem would be to reprocess all top-level markups with
correct footnotes after having done the pagination, then redo the pagination and
see if all the footnotes stay the same.  If so, keep the current configuration. 
Otherwise, rinse & repeat.  This actually seems kinda sorta doable, although I'd
have to do some homework on how these markups are stored internally and figure
out to what extent these internal representations survive downstream into the
pagination phase.
> 
> Cheers,
> Mike

Hey all,

I posted a sketch for a two-pass footnote automatic numbering spacing algorithm
to issue 4244064.

I just need to figure out a better way to name the output file (you'll see it's
current name in the patch), but it addresses Bertrand's concern about spacing in
the grand majority of cases so long as people compile the same file twice
back-to-back.

Cheers,
MS

[mike_apollinemike.com, 2011-03-16 15:44:20]

On Mar 11, 2011, at 5:41 AM, mike@apollinemike.com wrote:

> On Mar 10, 2011, at 12:11 PM, mike@apollinemike.com wrote:
> 
>> On Mar 10, 2011, at 12:02 PM, bordage.bertrand@gmail.com wrote:
>> 
>>> There is still a vertical spacing bug in the footnotes :
>>> \markup {
>>> \footnote e e
>>> \footnote e ef
>>> }
>>> There should be a fixed distance between the baseline and the number.
>>> 
>> 
>> The problem is that Lilypond processes graphical objects before it processes
pagination, making it impossible to know exactly how much space a footnote will
take up when the graphical object is processed.
>> 
>> One solution to this problem would be to reprocess all top-level markups with
correct footnotes after having done the pagination, then redo the pagination and
see if all the footnotes stay the same.  If so, keep the current configuration. 
Otherwise, rinse & repeat.  This actually seems kinda sorta doable, although I'd
have to do some homework on how these markups are stored internally and figure
out to what extent these internal representations survive downstream into the
pagination phase.
>> 
>> Cheers,
>> Mike
> 
> Hey all,
> 
> I posted a sketch for a two-pass footnote automatic numbering spacing
algorithm to issue 4244064.
> 
> I just need to figure out a better way to name the output file (you'll see
it's current name in the patch), but it addresses Bertrand's concern about
spacing in the grand majority of cases so long as people compile the same file
twice back-to-back.
> 
> Cheers,
> MS

I think (hope) that this is a safe way of going about i/o that will work on all
systems (see file-cache.scm).  Let me know if it's problematic.

http://codereview.appspot.com/4244064/

Cheers,
MS

[hanwenn, 2011-03-19 15:01:43]

On Wed, Mar 16, 2011 at 12:44 PM, mike@apollinemike.com
<mike@apollinemike.com> wrote:
> The problem is that Lilypond processes graphical objects before it processes
> pagination, making it impossible to know exactly how much space a footnote
> will take up when the graphical object is processed.
>
> One solution to this problem would be to reprocess all top-level markups
> with correct footnotes after having done the pagination, then redo the
> pagination and see if all the footnotes stay the same.  If so, keep the
> current configuration.  Otherwise, rinse & repeat.  This actually seems
> kinda sorta doable, although I'd have to do some homework on how these
> markups are stored internally and figure out to what extent these internal
> representations survive downstream into the pagination phase.
>

Overall comment: I think we should avoid 2 pass solutions if we can
help it.  Have you thought of setting a fixed width/height for the
number and later filling it in?

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[mike_apollinemike.com, 2011-03-19 15:06:47]

On Mar 19, 2011, at 11:01 AM, Han-Wen Nienhuys wrote:

> On Wed, Mar 16, 2011 at 12:44 PM, mike@apollinemike.com
> <mike@apollinemike.com> wrote:
>> The problem is that Lilypond processes graphical objects before it processes
>> pagination, making it impossible to know exactly how much space a footnote
>> will take up when the graphical object is processed.
>> 
>> One solution to this problem would be to reprocess all top-level markups
>> with correct footnotes after having done the pagination, then redo the
>> pagination and see if all the footnotes stay the same.  If so, keep the
>> current configuration.  Otherwise, rinse & repeat.  This actually seems
>> kinda sorta doable, although I'd have to do some homework on how these
>> markups are stored internally and figure out to what extent these internal
>> representations survive downstream into the pagination phase.
>> 
> 
> Overall comment: I think we should avoid 2 pass solutions if we can
> help it.  Have you thought of setting a fixed width/height for the
> number and later filling it in?


That's what I do on line 1862 of define-markup-commands.com.  This uses a seed
of 0 (line 1861) on the first pass, and then uses the actual value on the second
pass (line 1860).  The seed of 0 works well for one digit numbers, but breaks
down on larger #s.

Cheers,
Mike

[hanwenn, 2011-03-19 15:58:39]

On Sat, Mar 19, 2011 at 12:06 PM, mike@apollinemike.com
<mike@apollinemike.com> wrote:

>> On Wed, Mar 16, 2011 at 12:44 PM, mike@apollinemike.com
>> <mike@apollinemike.com> wrote:
>>> The problem is that Lilypond processes graphical objects before it processes
>>> pagination, making it impossible to know exactly how much space a footnote
>>> will take up when the graphical object is processed.
>>>
>>> One solution to this problem would be to reprocess all top-level markups
>>> with correct footnotes after having done the pagination, then redo the
>>> pagination and see if all the footnotes stay the same.  If so, keep the
>>> current configuration.  Otherwise, rinse & repeat.  This actually seems
>>> kinda sorta doable, although I'd have to do some homework on how these
>>> markups are stored internally and figure out to what extent these internal
>>> representations survive downstream into the pagination phase.
>>>
>>
>> Overall comment: I think we should avoid 2 pass solutions if we can
>> help it.  Have you thought of setting a fixed width/height for the
>> number and later filling it in?
>
>
> That's what I do on line 1862 of define-markup-commands.com.  This uses a seed
of 0 (line 1861) on the first pass, and then uses the actual value on the second
pass (line 1860).  The seed of 0 works well for one digit numbers, but breaks
down on larger #s.

But if you format the number to be flushed with space in a box for 2
digits, you should be fine, right?

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[mike_apollinemike.com, 2011-03-19 16:07:47]

On Mar 19, 2011, at 11:58 AM, Han-Wen Nienhuys wrote:

> On Sat, Mar 19, 2011 at 12:06 PM, mike@apollinemike.com
> <mike@apollinemike.com> wrote:
> 
>>> On Wed, Mar 16, 2011 at 12:44 PM, mike@apollinemike.com
>>> <mike@apollinemike.com> wrote:
>>>> The problem is that Lilypond processes graphical objects before it
processes
>>>> pagination, making it impossible to know exactly how much space a footnote
>>>> will take up when the graphical object is processed.
>>>> 
>>>> One solution to this problem would be to reprocess all top-level markups
>>>> with correct footnotes after having done the pagination, then redo the
>>>> pagination and see if all the footnotes stay the same.  If so, keep the
>>>> current configuration.  Otherwise, rinse & repeat.  This actually seems
>>>> kinda sorta doable, although I'd have to do some homework on how these
>>>> markups are stored internally and figure out to what extent these internal
>>>> representations survive downstream into the pagination phase.
>>>> 
>>> 
>>> Overall comment: I think we should avoid 2 pass solutions if we can
>>> help it.  Have you thought of setting a fixed width/height for the
>>> number and later filling it in?
>> 
>> 
>> That's what I do on line 1862 of define-markup-commands.com.  This uses a
seed of 0 (line 1861) on the first pass, and then uses the actual value on the
second pass (line 1860).  The seed of 0 works well for one digit numbers, but
breaks down on larger #s.
> 
> But if you format the number to be flushed with space in a box for 2
> digits, you should be fine, right?
> 

Doable, but that causes the reverse problem - namely, too much space between the
footnote and the next markup in a line for single-digit notes.  Given that the
majority of notes in most documents will be single-digit, it makes sense (to me)
to have a single digit as the seed.

One way to avoid a two-pass system is to redo the way that top-level markups are
stashed in LilyPond.  If LilyPond can re-evaluate these markups after page
breaking is calculated, it can scan to see if their vertical extent is the same
as the original.  If so, keep the page breaking configuration.  If not,
re-calculate page breaking, taking the new vertical extents into account.  Then
re-update the footnotes.  Do this as a loop until the new extent equal the old
extent for every text markup.

However, this seems like it'd take a few hundred lines of code to get up and
running & should be the object of a new patch.

Cheers,
MS

[hanwenn, 2011-03-19 16:14:44]

On Sat, Mar 19, 2011 at 1:07 PM, mike@apollinemike.com
<mike@apollinemike.com> wrote:

> One way to avoid a two-pass system is to redo the way that top-level markups
are stashed in LilyPond.  If LilyPond can re-evaluate these markups after page
breaking is calculated, it can scan to see if their vertical extent is the same
as the original.  If so, keep the page breaking configuration.  If not,
re-calculate page breaking, taking the new vertical extents into account.  Then
re-update the footnotes.  Do this as a loop until the new extent equal the old
extent for every text markup.

You realize that you may end up in an infinite loop for (rare)
degenerate cases, right? If anything, you should stop after the 2nd
pass.

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[mike_apollinemike.com, 2011-03-19 16:20:14]

On Mar 19, 2011, at 12:14 PM, Han-Wen Nienhuys wrote:

> On Sat, Mar 19, 2011 at 1:07 PM, mike@apollinemike.com
> <mike@apollinemike.com> wrote:
> 
>> One way to avoid a two-pass system is to redo the way that top-level markups
are stashed in LilyPond.  If LilyPond can re-evaluate these markups after page
breaking is calculated, it can scan to see if their vertical extent is the same
as the original.  If so, keep the page breaking configuration.  If not,
re-calculate page breaking, taking the new vertical extents into account.  Then
re-update the footnotes.  Do this as a loop until the new extent equal the old
extent for every text markup.
> 
> You realize that you may end up in an infinite loop for (rare)
> degenerate cases, right? If anything, you should stop after the 2nd
> pass.

Good point - I can make the # of passes in the loop a variable w/ the default as
2.

However, for now, would you agree that the two-pass solution is better than the
alternative (too-wide / too-narrow spacing)?  Although I don't have much
feedback for where this would be useful, the one person who has given this code
a spin (Bertrand) and who is pretty invested in all things footnote seems to
like this system over a one-pass alternative (I'm not putting words into your
mouth, am I, Bertrand?).

Cheers,
Mike

[hanwenn, 2011-03-19 16:27:24]

On Sat, Mar 19, 2011 at 1:20 PM, mike@apollinemike.com
<mike@apollinemike.com> wrote:
>> You realize that you may end up in an infinite loop for (rare)
>> degenerate cases, right? If anything, you should stop after the 2nd
>> pass.
>
> Good point - I can make the # of passes in the loop a variable w/ the default
as 2.
>
> However, for now, would you agree that the two-pass solution is better than
the alternative (too-wide / too-narrow spacing)?  Although I don't have much
feedback for where this would be useful, the one person who has given this code
a spin (Bertrand) and who is pretty invested in all things footnote seems to
like this system over a one-pass alternative (I'm not putting words into your
mouth, am I, Bertrand?).

Technically I much prefer the 1 pass solution, although it requires
constraints on how the marks are formatted (with padding space for
small numbers.)

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[Bertrand Bordage, 2011-03-22 15:28:16]

Of course, I agree that we should get rid of the two-pass algorithm. But it's
really tricky to do it the clean way :o\

As the issues I pointed out need deep changes, I think the two-pass algorithm is
better than nothing.

For the moment, we can also avoid these issues by displaying footnotes another
way.
For instance (without using this numbering patch) :

\markup \footnote \line { a \raise #0.5 \tiny 1 } \line { 1. b }
\markup \footnote \line { c \raise #0.5 \tiny 14 } \line { 14. d }

This seems to be a good solution. We can even use this syntax instead :

\markup { a \footnote \raise #0.5 \tiny 1 \line { 1. b } }

I'm no specialist, I may be wrong. But I worked on footnotes a few month ago and
I met the same problems. The only solution I found to avoid them is the way I
wrote before.

http://codereview.appspot.com/4244064/diff/40002/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

http://codereview.appspot.com/4244064/diff/40002/scm/define-markup-commands.s...
scm/define-markup-commands.scm:1856: (markup-y-ext (ly:stencil-extent
markup-stencil Y))
Why is this defined ? I can't find its use.

[Neil Puttock, 2011-03-22 23:35:18]

On 10 March 2011 10:06, mike@apollinemike.com <mike@apollinemike.com> wrote:
> On Mar 9, 2011, at 10:17 PM, n.puttock@gmail.com wrote:

>> 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).

You're only using it for automatic numbering, so it could be
incorporated into the markup command instead.

If you still think it's necessary though, you need to rethink the way
the whiteout's being applied; currently, you're applying
`stencil-whiteout' to the evaluated markup, then setting 'text to the
new value.  You can't do this since it's a property type mismatch:
'text expects markup, not a stencil.

Cheers,
Neil

[mike_apollinemike.com, 2011-03-23 10:46:36]

On Mar 22, 2011, at 11:28 AM, bordage.bertrand@gmail.com wrote:

> Of course, I agree that we should get rid of the two-pass algorithm. But
> it's really tricky to do it the clean way :o\
> 

I will jump on the bandwagon here in saying that I too strongly dislike the
two-pass algorithm, but I dislike scrunched footnotes even more.  To me, the
question is: is it worth it to have a 40ish-line kludgy implementation of
something as a placeholder for a better implementation, or should one hold out
until the better implementation?  Given that the better implementation here will
require revamping how and when top-level markups are calculated (if not markups
in general), which will effect more than just footnotes (it'll have a benefit
for \on-the-fly as well), and given that most users will likely want automatic
numbering, I think it's important to get this in LilyPond before tackling the
markup problem.

> As the issues I pointed out need deep changes, I think the two-pass
> algorithm is better than nothing.
> 

Agreed (see above).

> For the moment, we can also avoid these issues by displaying footnotes
> another way.
> For instance (without using this numbering patch) :
> 
> \markup \footnote \line { a \raise #0.5 \tiny 1 } \line { 1. b }
> \markup \footnote \line { c \raise #0.5 \tiny 14 } \line { 14. d }
> 
> This seems to be a good solution. We can even use this syntax instead :
> 
> \markup { a \footnote \raise #0.5 \tiny 1 \line { 1. b } }
> 

You're absolutely right.  For someone who wants linear footnotes, this is
relatively easy to keep tabs on.  For someone who wants footnotes to reset when
pages reset, if they are absolutely certain that a given footnote will fall on
page X, this is doable by hand as well.

>
http://codereview.appspot.com/4244064/diff/40002/scm/define-markup-commands.scm
> File scm/define-markup-commands.scm (right):
> 
>
http://codereview.appspot.com/4244064/diff/40002/scm/define-markup-commands.s...
> scm/define-markup-commands.scm:1856: (markup-y-ext (ly:stencil-extent
> markup-stencil Y))
> Why is this defined ? I can't find its use.

It's vestigial - I'll scrub it.

*Parting Shot*

My approach to footnotes is heavily influenced by my work as a composer, so I
have implemented them based on a way that is useful in contemporary music scores
(I'm thinking Ligeti's Nouvelles aventures).  For critical editions, there are
manifold improvements that should be made, such as:

1)	The ability for the same symbol in several different places on a page to
apply to the same footnote.
2)	As Bertrand previously suggested, the ability for footnotes to be laid out
more compactly.
3)	The ability for in-line annotations to be typeset differently (i.e. as a
markup above a note), which is likely doable 100% from scheme and may be more
LSR work than source work.

However, in thinking about all of these things, LilyPond verges dangerously
close on duplicating a lot of functionality that is already part of LaTeX.  If
someone wants floats, tables, and equations in their score as well, then at a
certain point, trying to incorporate these things into LilyPond stops making
sense (not unlike David Byrne).

To me, the big question seems: to what extent is it worth it for LilyPond to
implement robust markup functions that make text behave more like it would/could
in TeX-based languages, and if it is worth it, are there any libraries that will
save us the hassle of implementing all this stuff?

Cheers,
MS

[mike_apollinemike.com, 2011-03-23 10:55:53]

On Mar 22, 2011, at 7:35 PM, Neil Puttock wrote:

> On 10 March 2011 10:06, mike@apollinemike.com <mike@apollinemike.com> wrote:
>> On Mar 9, 2011, at 10:17 PM, n.puttock@gmail.com wrote:
> 
>>> 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).
> 
> You're only using it for automatic numbering, so it could be
> incorporated into the markup command instead.
> 
> If you still think it's necessary though, you need to rethink the way
> the whiteout's being applied; currently, you're applying
> `stencil-whiteout' to the evaluated markup, then setting 'text to the
> new value.  You can't do this since it's a property type mismatch:
> 'text expects markup, not a stencil.

A workaround would be to create a markup in page-layout-problem.cc, in which
case my question would be: is there a clean way to create markups on the C++
side, or should I create a public scheme function & call it from the C++ side?

Cheers,
MS