+@noindent
+Let's see if this works in our previous example:
+
+@lilypond[quote,fragment,ragged-right,verbatim,relative=2]
+\dynamicUp
+\override DynamicText #'extra-spacing-width = #'(0 . 0)
+a4\f b\mf c\mp b\p
+@end lilypond
+
+@noindent
+Well, it has certainly stopped the dynamic marks being
+displaced, but two problems remain. The marks should be
+spaced a little further apart and it would be better
+if they were all the same distance from the staff.
+We can solve the first problem easily. Instead of making
+the @code{extra-spacing-width} zero we could add a little
+more to it. The units are the space between two staff
+lines, so moving the left edge half a unit to the left and the
+right edge half a unit to the right should do it:
+
+@lilypond[quote,fragment,ragged-right,verbatim,relative=2]
+\dynamicUp
+% Extend width by 1 staff space
+\override DynamicText #'extra-spacing-width = #'(-0.5 . 0.5)
+a4\f b\mf c\mp b\p
+@end lilypond
+
+@noindent
+This looks better, but maybe we would prefer the dynamic marks
+to be aligned along the same baseline rather than going up and
+down with the notes. The property to do this is
+@code{staff-padding} which is covered in the following section.
+
+
+@node Collisions of objects
+@section Collisions of objects
+
+@menu
+* Moving objects::
+* Fixing overlapping notation::
+* Real music example::
+@end menu
+
+@node Moving objects
+@subsection 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:
+
+@enumerate
+@item
+The @strong{direction} of one of the overlapping objects may
+be changed using the predefined commands listed above for
+within-staff objects (see @ref{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.
+
+@item
+The @strong{object properties}, which LilyPond uses
+when positioning layout objects, may be modified using
+@code{\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:
+@itemize
+
+@item
+@code{direction}
+
+This has already been covered in some detail -- see
+@ref{Within-staff objects}.
+
+@item
+@code{padding}, @code{left-padding},
+@code{right-padding}, @code{staff-padding}
+
+@cindex left-padding property
+@cindex padding property
+@cindex right-padding property
+@cindex staff-padding property
+As an object is being positioned the value of its @code{padding}
+property specifies the gap that must be left between itself and
+the nearest edge of the object against which it is being
+positioned. Note that it is the @code{padding} value of the object
+@strong{being placed} that is used;
+the @code{padding} value of the object which is already placed is
+ignored. Gaps specified by @code{padding} can be applied
+to all objects which support the @code{side-position-interface}.
+
+Instead of @code{padding}, the placement of groups of accidentals
+is controlled by @code{left-padding} and @code{right-padding}.
+These properties are to be found in the @code{AccidentalPlacement}
+object which, note, lives in the @strong{staff} context. Because
+accidentals are always positioned after and to the left of
+note heads only the @code{right-padding} property has any effect.
+
+The @code{staff-padding} property is closely related to the
+@code{padding} property: @code{padding}
+controls the minimum amount of space between any object which
+supports the @code{side-position-interface} and the nearest
+other object (generally the note or the staff lines);
+@code{staff-padding} applies only to those objects which are always
+set outside the staff -- it controls the minimum amount of space
+that should be inserted between that object and the staff. Note
+that @code{staff-padding} has no effect on objects which are
+positioned relative to the note rather than the staff, even though
+it may be overridden without error for such objects -- it is simply
+ignored.
+
+To discover which padding property is required for the object
+you wish to reposition, you
+need to return to the IR and look up the object's properties.
+Be aware that the padding properties might not be located in the
+obvious object, so look in objects that appear to be related.
+
+All padding values are measured in staff spaces. For most
+objects, this value is set by default to be around 1.0 or less
+(it varies with each object). It may be overridden if a larger
+(or smaller) gap is required.
+
+@item
+@code{self-alignment-X}
+
+@cindex self-alignment-X property
+This property can be used to align the object to the left, to
+the right, or to center it with respect to the parent object's
+reference point. It may be used with all objects which support
+the @code{self-alignment-interface}. In general these are objects
+that contain text. The values are @code{LEFT}, @code{RIGHT}
+or @code{CENTER}. Alternatively, a numerical value between
+@code{-1} and @code{+1} may be specified, where @code{-1} is
+left-aligned, @code{+1} is right-aligned, and numbers in between
+move the text progressively from left-aligned to right-aligned.
+Numerical values greater than @code{1} may be specified to move
+the text even further to the left, or less than @code{-1} to
+move the text even further to the right. A change of @code{1}
+in the value corresponds to a movement of half the text's length.
+
+@item
+@code{extra-spacing-width}
+
+@cindex extra-spacing-width property
+This property is available for all objects which support the
+@code{item-interface}. It takes two numbers, the first is added
+to the leftmost extent and the second is added to the rightmost
+extent. Negative numbers move the edge to the left, positive to
+the right, so to widen an object the first number must be negative,
+the second positive. Note that not all objects honor both
+numbers. For example, the @code{Accidental} object only takes
+notice of the first (left edge) number.
+
+@item
+@code{staff-position}
+
+@cindex staff-position property
+@code{staff-position} is a property of the
+@code{staff-symbol-referencer-interface}, which is supported by
+objects which are positioned relative to the staff. It specifies
+the vertical position of the object relative to the center line
+of the staff in half staff-spaces. It is useful in resolving
+collisions between layout objects like multi-measure rests, ties
+and notes in different voices.
+
+@item
+@code{force-hshift}
+
+@cindex force-hshift property
+
+Closely spaced notes in a chord, or notes occurring at the same
+time in different voices, are arranged in two, occasionally more,
+columns to prevent the note heads overlapping. These are called
+note columns, and an object called @code{NoteColumn} is created
+to lay out the notes in that column.
+
+The @code{force-hshift}
+property is a property of a @code{NoteColumn} (actually of the
+@code{note-column-interface}). Changing it permits a note column
+to be moved in units appropriate to a note column, viz. the note
+head width of the first voice note. It should be used in
+complex situations where the normal @code{\shiftOn} commands (see
+@ref{Explicitly instantiating voices}) do
+not resolve the note conflict. It is preferable to the
+@code{extra-offset} property for this purpose as there is no need
+to work out the distance in staff-spaces, and moving the notes
+into or out of a @code{NoteColumn} affects other actions such as
+merging note heads.
+
+@end itemize
+
+@item
+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:
+
+@table @code
+@item extra-offset
+@cindex extra-offset property
+This property applies to any layout object
+supporting the @code{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.
+
+@item positions
+@cindex positions property
+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 @qq{looks best}. If the @code{positions}
+property has been overridden the slur that is closest to the
+requested positions is selected from the list.
+@end table
+
+@end enumerate
+
+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.
+
+@multitable @columnfractions .5 .5
+@headitem Object type @tab Object name
+@item Articulations @tab @code{Script}
+@item Beams @tab @code{Beam}
+@item Dynamics (vertically) @tab @code{DynamicLineSpanner}
+@item Dynamics (horizontally) @tab @code{DynamicText}
+@item Fingerings @tab @code{Fingering}
+@item Rehearsal / Text marks @tab @code{RehearsalMark}
+@item Slurs @tab @code{Slur}
+@item Text e.g. @code{^"text"} @tab @code{TextScript}
+@item Ties @tab @code{Tie}
+@item Tuplets @tab @code{TupletBracket}
+@end multitable