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. Jean
