Andrew Bernard <andrew.bern...@gmail.com> writes: > Thanks David. > > I built 2.21.0 on Ubuntu 19.04. Running gdb, sure enough, it's the familiar > tuple bracket issue: > > Drawing systems...lilypond: > /home/andro/lilypond-git/flower/include/interval.hh:227: T > Interval_t<T>::center() const [with T = double]: Assertion `!is_empty ()' > failed. > > Program received signal SIGABRT, Aborted. > __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) backtrace > #0 0x00007ffff76bfed7 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007ffff76a1535 in __GI_abort () at abort.c:79 > #2 0x00007ffff76a140f in __assert_fail_base > (fmt=0x7ffff782f588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", > assertion=0x55555594ab94 "!is_empty ()", file=0x55555594abb8 > "/home/andro/lilypond-git/flower/include/interval.hh", line=227, > function=<optimised out>) at assert.c:92 > #3 0x00007ffff76b1012 in __GI___assert_fail > (assertion=assertion@entry=0x55555594ab94 "!is_empty ()", > file=file@entry=0x55555594abb8 > "/home/andro/lilypond-git/flower/include/interval.hh", line=line@entry=227, > function=function@entry=0x55555595c560 <Interval_t<double>::center() > const::__PRETTY_FUNCTION__> "T Interval_t<T>::center() const [with T = > double]") at assert.c:101 > #4 0x00005555556d93c7 in Interval_t<double>::center() const > (this=<optimised out>) at > /home/andro/lilypond-git/lily/include/lily-guile-macros.hh:70 > #5 0x00005555556d93c7 in Tuplet_number::calc_x_offset(scm_unused_struct*) > (smob=<optimised out>) at /home/andro/lilypond-git/lily/tuplet-number.cc:293 > > Last time this arose Aaron provided this code for me: > > \override TupletBracket.X-positions = #(lambda (grob) > (let ((xpos (ly:tuplet-bracket::calc-x-positions grob))) > (if (> (car xpos) (cdr xpos)) > (let ((mid (/ (+ (car xpos) (cdr xpos)) 2))) > (format #t "\nwarning: Fixing invalid X-positions ~a" xpos) > (cons mid mid)) > xpos))) > > Adding that prints a warning, and works around the issue, and I can, > thankfully go on. > > But since this keeps coming up, is it something that should be reported as > a bug, so as to eventually get fixed?
I am looking at this code right now and it is not clear to me that break-overshoot is used consistently. Its usual settings are something like (break-overshoot ,number-pair? "How much does a broken spanner stick out of its bounds?") Examples of this property are Documentation/ly-examples/cary-layout.ily: \override Beam.break-overshoot = #'(-0.5 . 1.0) input/regression/beam-outside-beamlets.ly: \override Beam.break-overshoot = #'(-0.5 . 0.5) input/regression/spanner-break-overshoot.ly: \override Beam.break-overshoot = #'(1.0 . 2.0) input/regression/spanner-break-overshoot.ly: \override TupletBracket.break-overshoot = #'(1.0 . 2.0) so it's sometimes positive, sometimes negative. The default code in lily/tuplet-bracket.cc does if (connect_to_other[d]) { Interval overshoot (robust_scm2drul (me->get_property ("break-overshoot"), Interval (-0.5, 0.0))); if (d == RIGHT) x_span[d] += d * overshoot[d]; else x_span[d] = (bounds[d]->break_status_dir () ? Axis_group_interface::generic_bound_extent (bounds[d], commonx, X_AXIS)[-d] : robust_relative_extent (bounds[d], commonx, X_AXIS)[-d]) - overshoot[LEFT]; } so the default value is negative which moves the left end of the span to the _right_ since the left overshoot is subtracted. The comparable code for beams does if (on_line_bound && me->get_bound (event_dir)->break_status_dir ()) { current.horizontal_[event_dir] = (Axis_group_interface::generic_bound_extent (me->get_bound (event_dir), commonx, X_AXIS)[RIGHT] + event_dir * break_overshoot[event_dir]); } which again puts in a factor of -1 for the left bound, also using a default value of -0.5 . Is this negative break_overshoot (which reduces the extent on the left side, possibly until the interval becomes empty) as intended or is this a consequence of confusion? -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond