Next: , Up: Collisions of objects


4.5.1 Moving objects

This may come as a surprise, but LilyPond is not perfect. Some notation elements can overlap. This is unfortunate, but in fact rather rare. Usually the need to move objects is for clarity or aesthetic reasons – they would look better with a little more or a little less space around them.

There are three main approaches to resolving overlapping notation. They should be considered in the following order:

  1. The direction of one of the overlapping objects may be changed using the predefined commands listed above for within-staff objects (see Within-staff objects). Stems, slurs, beams, ties, dynamics, text and tuplets may be repositioned easily in this way. The limitation is that you have a choice of only two positions, and neither may be suitable.
  2. The object properties, which LilyPond uses when positioning layout objects, may be modified using \override. The advantages of making changes to this type of property are (a) that some other objects will be moved automatically if necessary to make room and (b) the single override can apply to all instances of the same type of object. Such properties include:
  3. Finally, when all else fails, objects may be manually repositioned relative to the staff center line vertically, or by displacing them by any distance to a new position. The disadvantages are that the correct values for the repositioning have to be worked out, often by trial and error, for every object individually, and, because the movement is done after LilyPond has placed all other objects, the user is responsible for avoiding any collisions that might ensue. But the main difficulty with this approach is that the repositioning values may need to be reworked if the music is later modified. The properties that can be used for this type of manual repositioning are:
    extra-offset
    This property applies to any layout object supporting the grob-interface. It takes a pair of numbers which specify the extra displacement in the horizontal and vertical directions. Negative numbers move the object to the left or down. The units are staff-spaces. The extra displacement is made after the typesetting of objects is finished, so an object may be repositioned anywhere without affecting anything else.
    positions
    This is most useful for manually adjusting the slope and height of beams, slurs, and tuplets. It takes a pair of numbers giving the position of the left and right ends of the beam, slur, etc. relative to the center line of the staff. Units are staff-spaces. Note, though, that slurs and phrasing slurs cannot be repositioned by arbitrarily large amounts. LilyPond first generates a list of possible positions for the slur and by default finds the slur that “looks best”. If the positions property has been overridden the slur that is closest to the requested positions is selected from the list.

A particular object may not have all of these properties. It is necessary to go to the IR to look up which properties are available for the object in question.

Here is a list of the objects which are most likely to be involved in collisions, together with the name of the object which should be looked up in the IR in order to discover which properties should be used to move them.

Object type Object name
Articulations Script
Beams Beam
Dynamics (vertically) DynamicLineSpanner
Dynamics (horizontally) DynamicText
Fingerings Fingering
Rehearsal / Text marks RehearsalMark
Slurs Slur
Text e.g. ^"text" TextScript
Ties Tie
Tuplets TupletBracket

This page is for LilyPond-2.11.58 (development-branch).

Report errors to http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs.

Your suggestions for the documentation are welcome.

Other languages: français, español, deutsch.