On Mon, Jun 15, 2009 at 9:05 PM, Reinhold Kainhofer <address@hidden>
-----BEGIN PGP SIGNED MESSAGE-----
Am Montag, 15. Juni 2009 17:25:54 schrieb Joe Neeman:
> I've started working on a new system for doing vertical layout in one passSince I have also attempted to improve the vertical stretching of orchestral
> (ie. positioning and stretching the systems simultaneously).
(choir + full orchestra) full scores (but failed, since I couldn't get the
springs-and-rods problem to return any useful solution), I spend a while
thinking about what should be done:
Those are some comprehensive comments, thanks! Some remarks/questions below...
- -) Being able to set stretching factors on a StaffGroup-level. In particular,
for full scores there are staff groups for woodwind, brass, vocal voices,
strings etc. When the whole system is stretched vertically, there is more
space in printed scores between the groups than between the staves inside the
individual groups (i.e. the instrumental staff groups use a different spring
constant than the staff group for the whole system). See e.g. a modern
Current bad lilypond results (with huge stretching) are:
This is really necessary for full scores for the conductor to get a quick
overview over the instrument groups. In particular, look at the
stretching_oly_vocalstaves.pdf file (current results with lilypond!), hide the
group brackets at the left and try to guess which staves belong together...
Sample file (with hardly any stretching):
You would never guess which staves belong together..
This will certainly the possible in the layout code, but I don't see how to make it nicely accessible through properties. Currently, the information about staff groups doesn't make it as far as the backend. If I can't find a nice way to do this, the functionality will be available anyway by setting 'previous-space on the first staff and 'next-space on the last staff of a staff group.
- -) The stretching should not be done by simply inserting the same space
between all the staves, since then staves with a high skyline (e.g. one staff
has some dynamic signs, while other don't) will be spaced too much compared to
staves with a low skyline. The stretching should rather attempt to space the
center-line of the staves (almost) equally.
This is already done (assuming it works; I haven't checked carefully).
- -) For staves with lyrics it might give better results to almost ignore the
lyrics for spacing and then squeeze in the lyrics in the remaining space.
Otherwise the vocal staves with lyrics will be spaced way too much compared to
e.g. the strings section. For a hand-engraving, see e.g. the 1897 Breitkopf
edition of Schubert's Stabat mater:
Compare this to the current LilyPond output:
Ok, I was planning anyway to divide VerticalAxisGroups into "spaceable" (eg. staves) and "non-spaceable"
(eg. dynamics in a piano staff) categories. The "spaceable" lines will participate in the layout algorithm (ensuring that space is reserved for the non-spaceable lines) and then the non-spaceable lines will be distributed somehow in between the spaceable ones. This is how I intend to do centered dynamics for piano staves; I could do something similar for lyrics (maybe for figured bass also?).
- -) It should be possible to keep one context (in particular FiguredBass) as
close as possible to another staff (yes, we have that already by disabling
- -) Fixed positioning of staves/contexts should be possible, even if some
contexts are killed (in particular, when there are several measures where a
vocal voice is quiet, the lyrics context is automatically killed meanwhile and
the explicit positioning is messed up right now.
I'm not sure exactly what you mean by this. Do you mean that 'alignment-offsets in 'line-break-system-details should include the position of dead staves as well as live ones? That's easy enough to achieve. In fact, this can be fixed before 2.14.