Jonas Hahnfeld <[email protected]> writes: > Nope, that was a red herring: The reason is that the footnote creation > process in footnote-volta-spanner.ly messes with (point-stencil), which > is used by skyline-point-extent.ly and also the BendSpanner. As far as > I understand the Stencil class, its objects are not immutable... > > One of the following two changes fixes the problem in my local test > scenario: > > --- > diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly > index 13f5c37811..17f14b1f07 100644 > --- a/ly/music-functions-init.ly > +++ b/ly/music-functions-init.ly > @@ -538,7 +538,7 @@ to the preceding note or rest as a post-event with > @code{-}.") > 'X-offset (car offset) > 'Y-offset (cdr offset) > 'automatically-numbered (not mark) > - 'text (or mark (make-null-markup)) > + 'text (or mark (ly:make-stencil "" '(0 . 0) '(0 . 0))) > 'footnote-text footnote))) > (once (propertyTweak 'footnote-music mus item)))) > > diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm > index f7280f7a58..1ab6eaafe3 100644 > --- a/scm/define-markup-commands.scm > +++ b/scm/define-markup-commands.scm > @@ -1379,7 +1379,8 @@ An empty markup with extents of a single point. > \\null > } > @end lilypond" > - point-stencil) > + ;; Create a new point-stencil every time, it might get modified... > + (ly:make-stencil "" '(0 . 0) '(0 . 0))) > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > ;; basic formatting. > --- > > My gut feeling is that we should fix null-markup because nothing should > ever translate / rotate / modify the global point-stencil, thoughts?
To me that seems crazy. Instead \footnote should not modify the stencil generated from its argument in place. If it needs something with different dimensions, it needs to create a new stencil, copying the stencil expression and changing the dimensions. ly:stencil-set-extent! has been removed in 2.5.17. Extents are not intended to be mutable as far as I can discern, so if our C++ code does violate that assumption, it is that code we should fix instead of giving up on behavior guaranteed from the Scheme side of things. -- David Kastrup
