Below is a better MWE, including a new markup command. (It is my first time
defining a new markup command, so please let me know if I can improve
anything there!)
Summary of problems:
1. Regarding
Lyrics.VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding — The
default value of #0.5 causes collisions (even in measure 17), and
increasing it to #2.5, as I have done in this MWE, also causes a problem:
The lyrics uppercase F (m. 32) through uppercase Z (m. 52) are too far
below their related staves.
2. LilyPond is not “seeing” the obvious collision in measure 25 between
the note head and the long fermata and padding appropriately. Why?
I will appreciate your help!
%%% SNIPPET BEGINS
\version "2.24.4"
\layout {
\override Lyrics.VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding
= #2.5
}
#(define-markup-command (squaremata layout props text) (markup?)
"Place a long fermata (scripts.ulongfermata) centered above the given
text,
with baseline-skip of 2.2."
(interpret-markup layout props
(markup
#:override (cons 'baseline-skip 2.2)
#:override (cons 'direction 1) ; equivalent to ,UP
#:dir-column
(#:center-align text
#:center-align
(#:with-dimensions-from #:null ; % removing this line pushes lyrics
too far below their relatedstaff
#:musicglyph "scripts.ulongfermata")))))
<<
\relative {
\repeat unfold 4 { c'1 } \break
\repeat unfold 4 { c1 } \break
\repeat unfold 5 { f } \break
\repeat unfold 3 { f } \break
\repeat unfold 4 { g } \break
\repeat unfold 4 { g } \break
g, f'
\repeat unfold 100 { f }
}
\new Lyrics { \lyricmode {
a
\markup \squaremata b
c d e f g h i j k
\markup \squaremata l
\markup \squaremata m
n o p
\markup \squaremata q
r s t u v w x
\markup \squaremata y
z A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
}
}
>>
%%% SNIPPET ENDS
On Wed, 7 Jan 2026, Gabriel Ellsworth wrote:
> I think that what I’m seeking is a way to get LilyPond to recognize the
> need for some distance/padding between lyrics and the lowest note head
> linked to a staff (even if it is on a ledger line below said staff),
> rather than to the staff (i.e., bottom staff line) of “relatedstaff.”
>
> Or, actually, it’s really just about avoiding collisions in output, as
> shown in measure 39 of the below MWE, where I have no problem with the long
> fermata over the word “word” (it is fine as it is).
>
