Dear All,
Regarding vertical stretching of staves, have you looked at Trevor Bača's
"Controlling vertical spacing exactly - mini HOWTO"
in which he says:
1. First, it seems that there are two *different* models for
controlling vertical spacing, which we might term "permissive" and
"strict", respectively. The first model corresponds roughly to chapers
11.3.1 and 11.3.3, and concerns overrides to VerticalAxisGroup and
settings in the paper block like
\override Staff.VerticalAxisGroup #'minimum-Y-extent = #'(-3 . 3)
\paper {
between-system-space = 1.5\cm
between-system-padding = #1
ragged-bottom=##f
ragged-last-bottom=##f
}
My analysis of this type of vertical spacing control is that what
we're really doing here is mostly setting *padding* in different
guises. We're not really saying "this staff should be so far away from
this other staff; and then this system should be so far away from this
other system further down the page". Instead we're saying "I want at
least this much padding between these staves or between these systems;
beyond those padding specifications, just let Lily figure out what to
do." So we might term this padding-based way of thinking about
vertical spacing something like "permissive". And an interesting
characteristic of this way of tweaking vertical spacing is that -- I
think -- you can *not* cause staves or systems to *overlap*. And this
relates to the primary disadvantage of using VerticalAxisGroup
overrides (and paper and margin adjustments) to control vertical
spacing: it can sometimes seem frustratingly difficult to draw staves
or systems close enough together.[1]
[1] Feel free to contradict me here; Is it possible to cause staff- or
system-overlaps using the commands given in 11.1 and 11.3? And maybe I
was alone in my experience of feeling frustrated trying to game
VerticalAxisGroup to move staves closer together.
The second model for controlling vertical spacing centers around
NonMusicalPaperColumn line-break-system-details, is very lightly
touched on in 11.4, and concerns commands like:
\overrideProperty
#"Score.NonMusicalPaperColumn"
#'line-break-system-details
#'((alignment-offsets . (0 -5 -20)))
\overrideProperty #"Score.NonMusicalPaperColumn"
#'line-break-system-details #'((Y-offset . 20)
(alignment-offsets . (0 -15)))
\overrideProperty
#"Score.NonMusicalPaperColumn"
#'line-break-system-details
#'((fixed-alignment-extra-space . 15))
These overrides to line-break-system-details might be termed the
"strict" (or "control freak") approach to vertical spacing (as opposed
to the traditional, more "permissive" approach) because what we're
doing with these settings is saying "I want control here; start this
staff at exactly this vertical offset and then start this staff at
this vertical offset and finally put this staff at this vertical
offset; the vertical spacing that results is whatever results and I
don't even care if there are overlaps; just do what I say; oh and same
with the systems, too". If we want to be precise, we might even point
out that these overrides to line-break-system-details don't so much
control the spacing *between* staves and systems so much as the exact
vertical *positions at which* staves and systems begin on the page
(with the vertical spacing just a side-effect of these explicit
positioning commands).
The advantages and disadvantages to the line-break-system-details
approach to vertical spacing are pretty much what we would expect
versus the VerticalAxisGroup approach: line-break-system-details makes
it extremely easy to draw staves and system quite close to each other
but does indeed allow for staff or system overprinting.
So, to sum up this first point: it seems to me that there are two
different approaches to controlling vertical spacing: by
VerticalAxisGroup + paper settings or else by
line-break-system-details. These two methods aren't so much at odds
with each other as in a kind of cascade relationship: you can make
whatever VerticalAxisGroup + paper settings you want, but any
overrides to line-break-system-dettails will have the last say. Seems
relatively important to keep the relationship between these
"permissive" and "strict" approaches in mind to see what your vertical
spacing tweaks are really doing in any one particular score.
(One last parenthetical distinction is this: overrides to
VerticalAxisGroup will almost always be context-global and appear in
the with-block whereas overrides to line-break-system-details will
almost always appear inter alia in the middle of music input just
after an explicit \break command. So this suggests that maybe
"permissive" and "strict" might also be termed "global" and "local"
... but that pair of terms seems much less descriptive somehow.)
Second major concept running through the vertical spacing stuff is the
PianoStaff / nonPianoStaff dichotomy.
There's another thread active right now on the topic of whether
PianoStaff really needs to be special with regards to vertical spacing
at all. But for now PianoStaff is special with regards to vertical
spacing. This complicates the vertical spacing docs simply because
PianoStaff overrides introduce a new set of properties, viz 11.3.2 and
11.3.4:
\override VerticalAlignment #'forced-distance = #7
\overrideProperty
#"Score.NonMusicalPaperColumn"
#'line-break-system-details
#'((fixed-alignment-extra-space . 15))
(IMO, possibly the best reason to remove the specialness of PianoStaff
with regards to fixed spacing is to clean up this part of the docs.)
So these are the two different dichotomies I see in the background of
any decisions (or docs) on vertical spacing: which "method" to use
(either "permissive" with VerticalAxisGroup or "strict" with
line-break-system-details) and then PianoStaff / nonPianoStaff. The
dichotomies are completely orthogonal: whether you decide to use
"permissive" or "strict" vertical spacing, you still must be
constantly aware of whether you're setting spacing for a PianoStaff or
not and select properties to override accordingly.
* * *
So I guess my point in all this is to see if anyone resonates with
this way of looking at user control of vertical spacing. Perhaps all
this is quite obvious, but it certainly took me a good while to figure
out.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
