[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: new vertical layout engine
From: |
Reinhold Kainhofer |
Subject: |
Re: RFC: new vertical layout engine |
Date: |
Mon, 15 Jun 2009 20:05:02 +0200 |
User-agent: |
KMail/1.11.3 (Linux/2.6.28-11-generic; KDE/4.2.3; i686; ; ) |
-----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).
That's really great news, because the vertical stretching of orchestral scores
was the main thing that didn't look professional in LilyPond!
> This should
> give better default behaviour than the current code and it should also
> allow easier and more useful overrides. I plan to merge the code after 2.14
> is released, so it should appear in the 2.16 stable version. The code is
> currently in the dev/jneeman git branch. It basically works (I hope), but
> it is missing a lot of previously existing functionality. I'm interested in
> hearing from people who like to override vertical spacing stuff (even more
> so if they can compile from git and test things): what sort of overrides do
> you use and what sort of overrides would you like to have available? Also,
> are there any "high-level" overrides that would free you from having to
> position systems manually?
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:
- -) 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..
- -) 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. Of course, for very high skylines,
the staff distance to the staff above should be a bit larger.
As an example see the following sample score:
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/equal_spacing.pdf
Clearly, the alto and tenor staves are spaced too much, compared to the other
vocal staves. Ideally, all vocal staves inside a group should have more or
less the same distance between the center staff lines...
Or in other words: The stretching should first pad staves with a small skyline,
until all staves are equally spaced. I tried solving this by using the
distance between the center-staff-lines as springs and the skylines as rods,
but this didn't return the correct results....
- -) 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
- -) 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 did lots of sample files a while ago showing the current bad results with
these issues, but I can't find most of these test files now. I've uploaded
those
that I found and described their problems above. For all the lilypond scores I
cite above, the lilypond code can be found on the server, too:
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/
(the *oly*.ly files need the orchestrallily package; git repo is at
repo.org.gz, see in particular http://repo.or.cz/w/orchestrallily.git)
Cheers,
Reinhold
PS: Shouldn't your mail also go to lilypond-devel for develop input?
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFKNo1OTqjEwhXvPN0RAvXCAJ48Z8tEHsS+Uu6VeeV5VJgH6YnOJQCgnCOT
6tH/omsPwNfsuBQaQ20Q390=
=90xj
-----END PGP SIGNATURE-----
Re: RFC: new vertical layout engine, Jonathan Kulp, 2009/06/15
Re: RFC: new vertical layout engine, Cameron Horsburgh, 2009/06/16