bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setting max-stretch to a high value still leaves some space at the b


From: Reinhold Kainhofer
Subject: Re: setting max-stretch to a high value still leaves some space at the bottom
Date: Sat, 14 Jun 2008 21:54:15 +0200
User-agent: KMail/1.9.9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag, 14. Juni 2008 schrieb Nicolas Sceaux:
> Le 14 juin 08 à 15:11, Reinhold Kainhofer a écrit :
> > Does anyone know how to fix this problem, or at least where to look
> > in the
> > code?
>
> You can have a look at scm/layout-page-layout.scm, function
> stretch-and-draw-page, in particular around line 88, where there is a
> comment explaining what happens.

Ah, thanks for the hint, I only looked in lily/, because I didn't think that 
it would be implemented in scheme.

Looking at the code, I get the feeling that I'm looking at one of the the dark 
corners of lilypond... It reserves 10% (!!!) of the whole page for 
rounding/estimation errors and distributes this space across all 
between-system spacings. That's okay for 10 systems per page or so (+3mm 
additional spacing between the systems, so lilypond does not even correctly 
obey the padding/spacing settings in this case, but that's hardly noticable). 
If you have only two systems per page, that unfortunatly means that the 
spacing between the two systems will always be widened by ~3cm (and this 
space will NOT be used for stretching, which it rather should!) and there is 
nothing one can do about this. The result is ugly-looking scores like:
   http://www.fam.tuwien.ac.at/~reinhold/temp/two-systems-page.pdf
Please note that I have stretching enabled, and lilypond still does not 
stretch the two systems, but leaves that huge space in the middle of the 
page.

If there is only one system per page, it's even worse: lilypond can't 
distribute that space between the systems and simply adds a huge space at the 
bottom.

I suppose that the reserved space should not be a fixed 10% of the height, but 
at least dependent on the number of systems. Ideally, of course, the vertical 
extents of the systems should be calculated exactly!

The other issue I see is that Lilypond does not really try to make the staves 
evenly distributed, but rather the space between the staves (which makes a 
huge difference if the skyline goes far above/below the staff). An example is 
the lower bass staff in the two-systems example above, which optically looks 
like it belongs to the first organ rather than the choir staff, because the T 
and B staves are spaced much more than the B and first organ staves...

I'm not sure if I can fix these problems, but at least I'll have a look at the 
code and see if I can find a simple solution/workaround.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIVCHrTqjEwhXvPN0RAoDkAJ43JSkwzZRL9uuAoLt6IRGd2I1bcwCg1fj0
tU62noXdCF/0LgOe9bV/+EQ=
=OX1Y
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]