On Mar 19, 2011, at 11:58 AM, Han-Wen Nienhuys wrote: > On Sat, Mar 19, 2011 at 12:06 PM, m...@apollinemike.com > <m...@apollinemike.com> wrote: > >>> On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com >>> <m...@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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
