Am Sa., 23. März 2019 um 21:41 Uhr schrieb Aaron Hill <lilyp...@hillvisions.com>: > > On 2019-03-23 6:46 am, Andrew Bernard wrote: > > What calls calc_x_offset for Tuplet Number? > > This likely may be coming from Scheme. If you look at the Internals > reference, you will see that the X-offset property for TupletNumber is > by default set to ly:tuplet-number::calc-x-offset. > > That means that if you were to call (ly:grob-property grob 'X-offset) > against a TupletNumber, it will end up consulting the specified > procedure which is in this case implemented in C++. > > > Any assistance would be greatly appreciated. My string quartet is going > > nowhere but I am learning a lot about debugging lilypond. > > Are you able to share your .ly that exhibits this behavior? Without a > failing case on my side, I am left to only guess what might be > triggering the behavior.
I'd like to second. > That said, I have found a few things in the > code that *could* be problematic. > > For instance, would you try adding this to your project: > > %%%% > \override TupletBracket.X-positions = #(lambda (grob) > (let ((xpos (ly:tuplet-bracket::calc-x-positions grob))) > (if (> (car xpos) (cdr xpos)) > (format #t "\nwarning: Inverted X-positions ~a" xpos)) We have `ordered-cons´ for: > (cons (min (car xpos) (cdr xpos)) (max (car xpos) (cdr xpos))))) > %%%% > > This will emit a warning when it detects that the calculated X-positions > are inverted, but it also patches the issue by making the interval > valid. > > -- Aaron Hill It's worth checking LigatureBracket as well, they share the same procedures for stencil/X-offset. HorizontalBracket probably too (same procedure for `connect-to-neighbor´), although this is unlikely to trigger the problem, imho. Cheers, Harm _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond