[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quoted tuplet bracket within staff

From: Jean Abou Samra
Subject: Re: quoted tuplet bracket within staff
Date: Fri, 26 Nov 2021 18:43:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1

Le 26/11/2021 à 16:19, Lukas-Fabian Moser a écrit :
I never really understood the outside-staff behaviour, to be honest.

If it seems complicated, that's because it is. There
are two mechanisms for general collision avoidance,
incarnated in the side-position-interface and the
outside-staff-interface. First, LilyPond places all
grobs according to how they define their coordinates.
Side-positioned grobs compute theirs according to
padding and horizon-padding relative to their support
elements. The set of support elements is defined in a
specific way for each grob. Thus padding (and horizon-padding)
is basically a way to ask for a default padding
in the normal case, e.g. the padding of a
MultiMeasureRestScript from its MultiMeasureRest.
The staff-padding property addresses a frequent case,
which is keeping objects from the staff symbol.
side-position-interface callbacks thus add the
staff symbol as support automatically with a special
padding, which is the value of staff-padding. The
story does not end here, however. Once all grobs
have been placed, LilyPond will look at all those
having outside-staff-priority and review their placement
and outlines. If there are any collisions, or if
there are grobs with a lower outside-staff-priority
placed above grobs with a higher outside-staff-priority
(I think this is the criterion but I am not sure),
it will shift around grobs. This is the process that
uses the values of outside-staff-padding and
outside-staff-horizon-padding. These conceptually define
the small gap that you want LilyPond to insert between
colliding grobs when the staff is crowded.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]