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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
