Re: Trouble getting my page layout just right

[Joe Neeman]

On Thu, 2008-10-30 at 21:53 +1100, Cameron Horsburgh wrote:
> In short, I'm stumped!
> 
> Any ideas?

So I had a look at the file you sent off-list and it turns out that the
unevenness is being caused by poor extent-estimates. A workaround is to
set VerticalAxisGroup #'minimum-Y-extent to #'(-4 . 4). You might also
want to edit scm/layout-page-layout.scm, line 89, by increasing the
number "10.0" to something like "20.0" or "25.0". I'll probably do this
in the official sources soon, because there have already been other
complaints about it.

A full description of the problem follows, partly in case anyone cares
and partly so I can refer to it later.

The estimated extent of a system is calculated without the use of
skylines. That is, we assume that each staff in the system is just an
axis-aligned box. This is necessary because we need to calculate the
extent-estimates before we do horizontal spacing, but it tends to
overestimate the distance that must be placed between staves because the
more accurate skyline outlines allow grobs from staves to "mesh." The
difference is usually not dramatic, though.

A treble clef extends above the staff by a couple of staff spaces. If we
calculate the skyline accurately, the clef usually does not influence
the minimum distance to the staff above; that is usually determined by
some low-hanging notes and dynamics attached to the staff above. When we
use the rougher box approximation, however, then the treble clef forces
the staves farther apart. Have a look at some printed scores: if you
draw a horizontal line that touches the top of a treble clef, it will
usually intersect with low-hanging stuff the staff above. The amount of
that intersection is the amount of overestimation that the treble clef
causes.

When you have a system with many staves and many treble clefs, these
small amounts of overestimation add up. However, the overestimation
tends to be the same for most pages, so it doesn't cause much
unevenness; it only makes the pages so that they aren't filled up. On
page 4 of Cameron's example, there are no suddenly no dynamics and only
a few notes that extend below the staff. On that page, the treble clefs
_are_ the limiting factor for the positioning of the staves, so the
estimates _are_ accurate. This causes the system to be stretched by the
correct amount, which looks odd because the other pages are not
stretched enough. The minimum-Y-extent workaround works because the
larger minimum-Y-extent boxes are large enough to cover up the treble
clefs and eliminate the inaccuracies that they cause.

In the long term, the proper solution is not to use extent estimates for
deciding how much to stretch systems. Instead, we should use the
per-staff skylines (which are available at that stage, because we have
already decided on a page-breaking). These aren't completely accurate
because they don't include cross-staff objects, but they're pretty
close. In particular, they are much better than the box approximations.
It would be nice to do this along with a larger page-layout rewrite that
expresses each page as a large rod-and-spring problem with a spring for
every staff, not just every system.

In the shorter term, extent-estimates can be made more precise by
computing, for every staff, 2 extent-estimates: a "prefatory matter"
estimate and a "rest of the staff" estimate. The prefatory matter
estimate should be cheap to compute because it only depends on the
starting-point of a line. The "rest of the staff" estimate would be only
a minor modification of what the code we already have.

Joe