Thanks for all the help! First I post some rationale, then my real question, which is targeted at the developers I guess.

The behaviour I am after is a thing I really do want: it is visually confusing if the 'a tempo' comes halfway the 'poco rit.)' when it is clearly meant to be after it.

I am afraid that solutions involving staff-padding are not general enough; if I try to move the \markup{a tempo} in my example to the beginning of its bar, there is no value for right.text padding or staff-padding that lets it be both visible and at the same vertical position. And even then I am unsure if it will work for all 14 instrument parts (the tempo indications are needed in all), the skyline can be wildly different.

OK... Now for the real question.

I am really unenlightened why the right.text (or for that matter, both left.text and right.text if the padding is chosen sufficiently large) disappears for largish values of padding. After all, the padding is intended to stretch outside the texts, isn't that correct?

For a quick attempt to see if things crash or whatever if this test is disabled, I cloned git and built on my Ubuntu, verified quickly that the unmodified install works, then commented out that test (line 329 in lily/ and ran again. Lo and behold, everything looks OK in my first quick tests.

I am not familiar with Lilypond internals, so this raises my question: what is this test for? What problems does it guard against? Should it only hold for other spanners than text spanners? Or for right-broken text spanners? Etc. Or is it just a bug/feature silently living on from the past?


P.S. Building lilypond on my (up-to-date-ish but certainly not killer-class) PC take some minutes, not those tens of hours that the list spoke about lately.

On 10/12/2016 09:56 PM, David Nalesnik wrote:
On Wed, Oct 12, 2016 at 2:04 PM, Rutger Hofman <> wrote:
On 10/12/2016 06:17 PM, David Nalesnik wrote:

On Wed, Oct 12, 2016 at 8:48 AM, David Nalesnik
<> wrote:


On Wed, Oct 12, 2016 at 8:13 AM, Thomas Morley <>

in this thread
you researched the cause for problems while attaching TextSpanner to
spacers using custom-scheme-engravers.

May it be possible the problem is present in the original .cc-coded as

At least I don't see any problem with attached TextSpanners as soon as
I change a spacer to a real note-event in Rutger's code:

It appears to be related to the X-position of the right-bound text:
if it's too far to the left, it won't be printed.

Change the right-padding override in your example to 10, and the text
will also disappear.

ly:line-spanner::print considers the properties left-bound-info and
right-bound-info.  It returns '() if the sum of left.padding and
right.padding is greater than the distance between the left and right
ends of the spanner (as determined from "X" and "Y" stored in
bound-details).  I can't say I follow the thinking, but that's what
causes nothing to be printed when right.padding is set too high.

(The variable for padding is confusingly named "gaps" in the code, by the


For starters: thanks to you all for thinking along, and searching for an
analysis (and hopefully fix).

The 'solution' of suppressing the spanner under these conditions doesn't
sound immediately logical to me. And this suppression only struck my eye for
spanners that cross a line break; which doesn't imply that it cannot occur
otherwise of course.

The point I'm making is that the spanner was only suppressed in your
original example because the value you chose for right.padding was too
large -- large enough to put the right text before the left endpoint,
which roughly is why the program gave you nothing.  If you use

\override TextSpanner.bound-details.right.padding = #2

the text is moved out from under the TextScript.  You can then
override TextScript.staff-padding and TextSpanner.staff-padding to
force an alignment.  As far as I know, you will have to align them
yourself this way because the TextSpanner and TextScript are not
grouped.  The inner-texts enhancement does offer a grouping of sorts.


lilypond-user mailing list

Reply via email to