Re: RFC: new vertical layout engine

[Andrew Hawryluk]

On Tue, Jun 16, 2009 at 3:52 AM, Joe Neeman<address@hidden> wrote:
> On Mon, Jun 15, 2009 at 9:05 PM, Reinhold Kainhofer <address@hidden>
> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 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
>> > pass
>> > (ie. positioning and stretching the systems simultaneously).
>>
>> Since I have also attempted to improve the vertical stretching of
>> orchestral
>> (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
>> Bärenreiter edition:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Schubert_StabatMater_0050.pdf
>> Current bad lilypond results (with huge stretching) are:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_largestretch.pdf
>>
>> 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):
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_vocalstaves.pdf
>>
>> 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:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Partitur_Breitkopf1897-
>> Seite2.pdf
>> Compare this to the current LilyPond output:
>>
>> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_vocalstaves.pdf
>
> 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?).

Could there be a property that specifies whether the non-spaceable are to be
a) centered bewteen the neighboring lines,
b) positioned as close to the upper line as possible, or
c) positioned as close to the lower line as possible?

This would cover (a) piano-centered dynamics and lyrics between choral
staves, (b) lyrics below single staves and figured bass, and (c)
chords and lyrics above single staves (rare, but seen in choral works
with divisi).

>> - -) 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
>> stretching above).
>>
>>
>> - -) 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.
>
> Cheers,
> Joe
>
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>

Question about ragged last pages: would it be possible to find out how
much 'stretching' force was required to space the springs & staves on
the penultimate page and then apply the same stretching force to the
final page? Currently, LilyPond does a nice distribution of staves on
full pages and then leaves the final page as compressed as possible,
rather than leaving the last page comparably spaced.

Sorry I don't have a solution to the property problem - that seems
like the biggest hurdle. If it's any help, I was thinking about this a
while back and found that in most of my engraved scores the spacing
above the first violin is 1.2 to 1.75 times the size of the normal
inter-staff spacing (measured on pages where there is enough space
that the skylines are not touching and only the relative stretchiness
of the springs comes into effect).

As far as hara-kiri staves go, the stretchiness ('compliance' for
physicists/engineers) of the spring across a hara-kiri'd gap should be
the maximum of all the springs that would have been inside that gap if
none of the staves had been removed. All we need now is a way to
assign a compliance to each of those springs based on the staff
groupings.

Thanks for taking this up. I'd hoped to get smart enough to do it, but
at this rate we will all be very old before I am up to it!

Andrew