[Top][All Lists]
[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-----