After analyzing horizontal spacing, it’s time to move to another dimension and talk about vertical spacing 😉 which has its own, quite different set of difficulties. The basic problem here is getting objects close enough, but not too close: on one hand, we want to avoid situations where systems are very tall because all objects have abundant space between them, but on the other hand we don’t want to cramp everything as closely as possible. The goal is to have a certain amount of space between objects – no more and no less.
When we started the project in spring 2012, Mike Solomon has been working on his huge “skyline” patch (see issue 2148 in LilyPond’s issue tracker), which vastly improved vertical spacing produced by LilyPond (before this patch, LilyPond treated objects like rectangles – now the actual shape of the objects is approximated with detailed outlines, which result in much better object placement). We saw that Mike’s work improved LilyPond’s output, and that with his patch creating publication-quality scores will be easier for us. For example, here’s an excerpt from op. 8 No. 2 – first without skylines:
You can see that the piano staves are too far apart for no good reason. With Mike’s patch, the output looked like this:
Much better! There was just one difficulty: when we started, the patch was still in development, and it wasn’t included in any official relase of the program. Therefore, in order to use it we had to build our own version of LilyPond from the source code. This is not a difficult task, but since Urs didn’t have experience with doing this, for some time only I was able to compile the “official” scores. It was quite inconvenient, but that’s the price one has to pay for living on the cutting edge of technology! 🙂
However, even with Mike’s patch the vertical spacing was often not perfect yet. Usually this was because of some cross-staff objects (for example when a passage of notes beamed together changed staves in the middle, the resulting kneed beam was often wrong), or because of dynamics. In piano music, dynamics that apply to both hands should be placed between the staves – LilyPond can do this, but their exact positions usually need adjustments.
Fortunately, when you move an object that is placed between the staves, Lily will adjust how the staves themselves are placed. For example, the default staff placement can look like this:
After moving some of the dynamics, LilyPond repositions the staves closer to each other:
Sometimes moving a few dynamics was enough to get the staves positioned nicely, but sometimes the distance was still wrong and I had to override it manually. This is a tedious process, as it’s hard to guess the appropriate value – one has to use trial-and-error, which takes significant amounts of time since the score has to be recompiled after each guess. Since any such adjustments are closely tied to the current layout of the score (if the line breaking changes, they have to be redone), adjusting staff distances must be done quite late in the score preparation process.
Such manual staff positioning was necessary in 62 cases (approximately 17% of all systems).
I think that it would be interesting if LilyPond determined the distance between staves based on the actual size of the white area between them (currently it just measures the distance between fixed reference points, and makes sure that there is no overlap. Here’s an illustration of this idea:
Considering that we already have Mike’s skylines, implementing this shouldn’t be very much work… In fact, there exists a proof-of-concept implementation made by Joe Neeman, and I plan to expand it when I’ll have some spare time.