Comment #69 on issue 2801 by [email protected]: Patch: Approximates
cross-staff slurs in VerticalAxisGroup vertical-skylines.
http://code.google.com/p/lilypond/issues/detail?id=2801
It is more complicated than that for a couple reasons:
1) If grobs with outside staff priority are placed above the cross-staff
slur (like a tempo indication), they will need to be re-placed as well.
2) If the cross staff slur happens on the interior of a system (say from
staves 2 to 3 in a 4-staff system), then the staves on either side will
need respacing. Furthermore, if another cross-staff slur exists from staff
1 to 4, it will depend on the height of the interior one.
Neither of these are prohibitively difficult but they require a
sophisticated sort of rewinding mechanism so that the solutions to the
spring-and-rods problem used in Page_layout_problem::find_system_offsets
can become the new heights off of which a new round of calculations are
based. Objects whose Y-offsets depend on the slur (stuff with
outside-staff-priority or stuff with avoid-slur set to outside or around
come to mind) and objects that depend on these objects need to have their
offsets and extents wiped, their original callback functions restored, and
the calculations redone. Of course, if any of this becomes more
complicated through user tweaks (i.e. if the color of a grob depends on the
extent of a cross-staff-slur) these need to be redone as well. So a system
would need to be put in place where property-dependency was completely
accounted for and any property dependent on the Y-offset of a cross-staff
grob could be reset.
You'd then have to run this however many times such that the values in the
solution_ vector of the Page_layout_problem diverge by less than epsilon
between successive runs. Of course this risks becoming cyclic, so LilyPond
would need to perhaps say that if after X runs the spacing hasn't been
found, use the widest spacing generated so far.
