Re: Implements footnotes in LilyPond (issue4245062)
On Mar 5, 2011, at 10:43 AM, Neil Puttock wrote: > On 5 March 2011 14:38, Mike Solomon wrote: > >> Done - thanks for bearing with me as I learn about break-visibility. It is >> a corner of the code that I never had to deal with directly, so I'm still >> getting my sea legs. > > I suggest you remove the fallback value from > inherit-x-parent-visibility (or if you prefer, add another callback > for y-parent visibility without a default) otherwise grobs which don't > care about break-visibility (such as noteheads) will lose their > footnotes. > >> If you feel this is too hackish, I could make this direction-only (LEFT, >> CENTER, RIGHT) with CENTER defaulting to LEFT and have the footnote only >> apply to the first and last spanner. But, for long spanners, this seems >> less than ideal. As always, your suggestions are welcome! > > I'm afraid I'm at a loss to suggest anything better, so I'll have to > put up with it (unless anybody else can think of a better way. The first half has been pushed with everything changed save this one caveat that you bring up. If after a week people have better suggestions after having played around with these footnotes, I'll incorporate that into push 2/2. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements footnotes in LilyPond (issue4245062)
On 5 March 2011 14:38, Mike Solomon wrote: > Done - thanks for bearing with me as I learn about break-visibility. It is a > corner of the code that I never had to deal with directly, so I'm still > getting my sea legs. I suggest you remove the fallback value from inherit-x-parent-visibility (or if you prefer, add another callback for y-parent visibility without a default) otherwise grobs which don't care about break-visibility (such as noteheads) will lose their footnotes. > If you feel this is too hackish, I could make this direction-only (LEFT, > CENTER, RIGHT) with CENTER defaulting to LEFT and have the footnote only > apply to the first and last spanner. But, for long spanners, this seems less > than ideal. As always, your suggestions are welcome! I'm afraid I'm at a loss to suggest anything better, so I'll have to put up with it (unless anybody else can think of a better way. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements footnotes in LilyPond (issue4245062)
On Sat, Mar 5, 2011 at 11:57 PM, Mike Solomon wrote: > On Mar 5, 2011, at 7:19 AM, Joe Neeman wrote: > > On Sat, Mar 5, 2011 at 10:18 PM, Mike Solomon wrote: > >> Hey all, >> >> After a bit of back and forth w/ Han Wen, I have drummed up a way to split >> this up such that it can be part of LilyPond in two phases. It follows his >> suggestion to push all of the non-balloon-related stuff first, and to push >> that second. It will set the stencil property of FootnoteItem and >> FootnoteSpanner to #f in define-grobs.scm. This means that whatever people >> write for the annotation part of the footnote will be swallowed up and not >> used, whereas the note part on the bottom of the page will be printed. >> >> If anyone has arguments for pushing this whole thing in its entirety, let >> me know. I am in favor of that for the reasons I stated in my previous >> e-mail, but I also realize that big chunks of code pushed all at once can >> make bug tracking interminable. >> >> If not, the plan is to push the non-balloon-related stuff today, let it >> simmer for a few days, and then push the balloon related stuff used for the >> in-document annotations. I will make a nice long commit message detailing >> this so that, hopefully, experimental users don't waste hours figuring out >> what happened to their non-appearing annotations. Alternatively, if anyone >> feels that I should split this up but that I am splitting it up the wrong >> way, please let me know. >> > > That sounds fine to me. Do you have a patch showing the part you are going > to push first? I was happy with the spacing-related code up until your > break-visibility changes, but if you're going to include anything since > then, I'd like to have another quick look (I have to catch a plane in 12 > hours; if you put up your patch before then, I'll have a look right away). > > Cheers, > Joe > > > Patch attached. The stuff that comes from your comments regarding > break-visibility is implemented in Balloon_interface::is_visible. > I find the return value of Balloon_interface::is_visible strange (first of all, the name suggests that it should just be bool). For example, it returns BEGINNING_OF_LINE if the footnote is visible and in the middle of the line (but only if the parent has a break-visibility property). I might be missing something, but it looks to me like you can get rid of this function, and just set FootnoteItem 'break-visibility to (lambda (grob) (let ((parent (ly:grob-parent grob X)) (par-vis (ly:grob-property parent 'break-visibility)) (parent-visibility (if (vector? par-vis) par-vis #(#t #t #t (vector (vector-ref parent-visibility 0) (vector-ref parent-visibility 1) (and (vector-ref parent-visibility 2) (not (vector-ref parent-visibility 0)) (There's still a corner case here, because you need the footnote to be visible if it is in the first column of the score...) I don't like the interpolation stuff for spanner-placement. Why not just restrict the valid values to -1 and 1? It seems that any other value doesn't really have user-predictable behaviour anyway... I think you have a bug in system.cc:281, because there is no guaranteed order between the grobs whose rank is the ending column. In particular, the one that appears at the beginning of the next line might appear first, and then you will break prematurely. Maybe something like: bool end_of_line_visible = true; if (Spanner *s ...) ... if (Item *item ...) { end_of_line_visible = (LEFT == item->break_status_dir ()); ... } if (pos < (int)start) continue; if (pos > (int)end) break; if (pos == (int)end && !end_of_line_visible) continue; ... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements footnotes in LilyPond (issue4245062)
On 5 March 2011 12:57, Mike Solomon wrote: > Patch attached. The stuff that comes from your comments regarding > break-visibility is implemented in Balloon_interface::is_visible. > The patch currently represents about 85% of the original, omitting the 15% > that Han Wan had previously identified as hold-off-on-able for a first push > (the actual annotations). These are relatively painless to add back in. > I realize that this is not a "small" chunk, but if I shaved anything else > off, the footnotes wouldn't work. > I'm running regtests now & will report back if anything breaks. > Cheers, > MS > P.S. The original patch resides at http://codereview.appspot.com/4245062 I think there are several parts to this patch which should be removed: 1) the break-visibility code in balloon.cc You've implemented something which looks suspiciously like a callback, but you've also added a function to output-lib.scm which you call instead via scm_call_1 () (you shouldn't need to do this for a grob). All this code should be part of a callback for FootnoteItem #'break-visibility. This code doesn't work very well in some cases: \new Staff \with { \consists Footnote_engraver } \relative c' { \footnoteGrob #'Clef #'(0 . 2) foo bar c1 } -> no footnote \new Staff \with { \consists Footnote_engraver } \relative c' { c1 \footnoteGrob #'Clef #'(0 . 2) foo bar c1 } -> no footnote (good!), but suicided clefs are still accounted for (all three) in account_for_footnotes () \new Staff \with { \consists Footnote_engraver } \relative c' { c1 \break \footnoteGrob #'Clef #'(0 . 2) foo bar c1 } -> two footnotes, account_for_foonotes () still thinks there are three For all these cases setting FootnoteItem #'break-visibility to `inherit-x-parent-visibility' produces better results. 2) all the code related to `spanner-placement' This is a really bad interface for selecting the correct spanner. I'd much prefer something which would index the broken_intos_ (though I guess this would run into the same problem you're having with the footnote height calculations). @@ -1237,7 +1277,7 @@ Page_breaking::space_systems_with_fixed_number_per_page (vsize configuration, while (system_count_on_this_page < systems_per_page_ && line < cached_line_details_.size ()) { - Line_details const &cur_line = cached_line_details_[line]; + Line_details &cur_line = cached_line_details_[line]; looks like it's left over from a previous patch Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements footnotes in LilyPond (issue4245062)
On Sat, Mar 5, 2011 at 10:18 PM, Mike Solomon wrote: > Hey all, > > After a bit of back and forth w/ Han Wen, I have drummed up a way to split > this up such that it can be part of LilyPond in two phases. It follows his > suggestion to push all of the non-balloon-related stuff first, and to push > that second. It will set the stencil property of FootnoteItem and > FootnoteSpanner to #f in define-grobs.scm. This means that whatever people > write for the annotation part of the footnote will be swallowed up and not > used, whereas the note part on the bottom of the page will be printed. > > If anyone has arguments for pushing this whole thing in its entirety, let > me know. I am in favor of that for the reasons I stated in my previous > e-mail, but I also realize that big chunks of code pushed all at once can > make bug tracking interminable. > > If not, the plan is to push the non-balloon-related stuff today, let it > simmer for a few days, and then push the balloon related stuff used for the > in-document annotations. I will make a nice long commit message detailing > this so that, hopefully, experimental users don't waste hours figuring out > what happened to their non-appearing annotations. Alternatively, if anyone > feels that I should split this up but that I am splitting it up the wrong > way, please let me know. > That sounds fine to me. Do you have a patch showing the part you are going to push first? I was happy with the spacing-related code up until your break-visibility changes, but if you're going to include anything since then, I'd like to have another quick look (I have to catch a plane in 12 hours; if you put up your patch before then, I'll have a look right away). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements footnotes in LilyPond (issue4245062)
Hey all, After a bit of back and forth w/ Han Wen, I have drummed up a way to split this up such that it can be part of LilyPond in two phases. It follows his suggestion to push all of the non-balloon-related stuff first, and to push that second. It will set the stencil property of FootnoteItem and FootnoteSpanner to #f in define-grobs.scm. This means that whatever people write for the annotation part of the footnote will be swallowed up and not used, whereas the note part on the bottom of the page will be printed. If anyone has arguments for pushing this whole thing in its entirety, let me know. I am in favor of that for the reasons I stated in my previous e-mail, but I also realize that big chunks of code pushed all at once can make bug tracking interminable. If not, the plan is to push the non-balloon-related stuff today, let it simmer for a few days, and then push the balloon related stuff used for the in-document annotations. I will make a nice long commit message detailing this so that, hopefully, experimental users don't waste hours figuring out what happened to their non-appearing annotations. Alternatively, if anyone feels that I should split this up but that I am splitting it up the wrong way, please let me know. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel