[prev in list] [next in list] [prev in thread] [next in thread]
List: lilypond-user
Subject: Re: Vertical Stretching of Groups
From: "=?UTF-8?Q?Trevor_Ba=C4=8Da?=" <trevorbaca () gmail ! com>
Date: 2008-07-29 22:31:17
Message-ID: d21bce00807291531q17c70eadw4cc8c47f31456122 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
2008/6/15 Frederick Dennis <frederickdennis@googlemail.com>
>
>
> 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.
Hi Frederick,
Your summary of the vertical spacing possibilities certainly makes sense to
me. I especially like your mention of the idea of a settings cascade. If we
ask which of the two settings-types applies first, the answer would have to
be the "strict" settings governed by line-break-system-details. Thereafter,
lily uses "permissive" / padding-based settings for any decisions that
remain to be made. In the case that the user specifies no "strict" /
line-break-system-details settings (which is almost always the case,
especially for new / normal users of the system), then the "permissive" /
padding-based settings are the only settings which will factor into the
spacing problem.
So, that makes me think that it would be possible to present the vertical
spacing docs in that order: "strict" and then "permissive", following the
order of the settings cascade.
But the only thing that's weird about that is that the "strict" settings are
-- I think -- the more exotic settings. So it might be strange to lead the
chapter on vertical spacing with those more exotic settings first.
And Joe's point about PianoStaff's specialness going away is a good thing
and the vertical spacing docs shoudl change to reflect that.
--
Trevor Bača
trevorbaca@gmail.com
[Attachment #3 (text/html)]
<div dir="ltr"><br><br><div class="gmail_quote">2008/6/15 Frederick Dennis <span \
dir="ltr"><<a href="mailto:frederickdennis@googlemail.com">frederickdennis@googlemail.com</a>></span><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <br><br>Dear All,<br>Regarding vertical stretching of \
staves, have you looked at Trevor Bača's "Controlling vertical spacing \
exactly - mini HOWTO"<br>in which he says:<br>1. First, it seems that there are \
two *different* models for<br>
controlling vertical spacing, which we might term "permissive" \
and<br>"strict", respectively. The first model corresponds roughly to \
chapers<br>11.3.1 and 11.3.3, and concerns overrides to VerticalAxisGroup and<br>
settings in the paper block like<br><br> \override Staff.VerticalAxisGroup \
#'minimum-Y-extent = #'(-3 . 3)<br><br> \paper \
{<br> between-system-space = \
1.5\cm<br> between-system-padding = \
#1<br> ragged-bottom=##f<br>
ragged-last-bottom=##f<br> }<br><br>My analysis of \
this type of vertical spacing control is that what<br>we're really doing here is \
mostly setting *padding* in different<br>guises. We're not really saying \
"this staff should be so far away from<br>
this other staff; and then this system should be so far away from this<br>other \
system further down the page". Instead we're saying "I want at<br>least \
this much padding between these staves or between these systems;<br>
beyond those padding specifications, just let Lily figure out what to<br>do." So \
we might term this padding-based way of thinking about<br>vertical spacing something \
like "permissive". And an interesting<br>
characteristic of this way of tweaking vertical spacing is that -- I<br>think -- you \
can *not* cause staves or systems to *overlap*. And this<br>relates to the primary \
disadvantage of using VerticalAxisGroup<br>overrides (and paper and margin \
adjustments) to control vertical<br>
spacing: it can sometimes seem frustratingly difficult to draw staves<br>or systems \
close enough together.[1]<br><br>[1] Feel free to contradict me here; Is it possible \
to cause staff- or<br>system-overlaps using the commands given in 11.1 and 11.3? And \
maybe I<br>
was alone in my experience of feeling frustrated trying to game<br>VerticalAxisGroup \
to move staves closer together.<br><br>The second model for controlling vertical \
spacing centers around<br>NonMusicalPaperColumn line-break-system-details, is very \
lightly<br>
touched on in 11.4, and concerns commands like:<br><br> \
\overrideProperty<br> \
#"Score.NonMusicalPaperColumn"<br> \
#'line-break-system-details<br> \
#'((alignment-offsets . (0 -5 -20)))<br>
<br> \overrideProperty \
#"Score.NonMusicalPaperColumn"<br> \
#'line-break-system-details #'((Y-offset . 20)<br>(alignment-offsets . (0 \
-15)))<br><br> \
\overrideProperty<br> \
#"Score.NonMusicalPaperColumn"<br>
\
#'line-break-system-details<br> \
#'((fixed-alignment-extra-space . 15))<br><br>These overrides to \
line-break-system-details might be termed the<br>"strict" (or "control \
freak") approach to vertical spacing (as opposed<br>
to the traditional, more "permissive" approach) because what \
we're<br>doing with these settings is saying "I want control here; start \
this<br>staff at exactly this vertical offset and then start this staff at<br>
this vertical offset and finally put this staff at this vertical<br>offset; the \
vertical spacing that results is whatever results and I<br>don't even care if \
there are overlaps; just do what I say; oh and same<br>with the systems, too". \
If we want to be precise, we might even point<br>
out that these overrides to line-break-system-details don't so much<br>control \
the spacing *between* staves and systems so much as the exact<br>vertical *positions \
at which* staves and systems begin on the page<br>(with the vertical spacing just a \
side-effect of these explicit<br>
positioning commands).<br><br>The advantages and disadvantages to the \
line-break-system-details<br>approach to vertical spacing are pretty much what we \
would expect<br>versus the VerticalAxisGroup approach: line-break-system-details \
makes<br>
it extremely easy to draw staves and system quite close to each other<br>but does \
indeed allow for staff or system overprinting.<br><br>So, to sum up this first point: \
it seems to me that there are two<br>different approaches to controlling vertical \
spacing: by<br>
VerticalAxisGroup + paper settings or else by<br>line-break-system-details. These two \
methods aren't so much at odds<br>with each other as in a kind of cascade \
relationship: you can make<br>whatever VerticalAxisGroup + paper settings you want, \
but any<br>
overrides to line-break-system-dettails will have the last say. Seems<br>relatively \
important to keep the relationship between these<br>"permissive" and \
"strict" approaches in mind to see what your vertical<br>
spacing tweaks are really doing in any one particular score.<br><br>(One last \
parenthetical distinction is this: overrides to<br>VerticalAxisGroup will almost \
always be context-global and appear in<br>the with-block whereas overrides to \
line-break-system-details will<br>
almost always appear inter alia in the middle of music input just<br>after an \
explicit \break command. So this suggests that maybe<br>"permissive" and \
"strict" might also be termed "global" and "local"<br>
... but that pair of terms seems much less descriptive somehow.)<br><br><br>Second \
major concept running through the vertical spacing stuff is the<br>PianoStaff / \
nonPianoStaff dichotomy.<br><br>There's another thread active right now on the \
topic of whether<br>
PianoStaff really needs to be special with regards to vertical spacing<br>at all. But \
for now PianoStaff is special with regards to vertical<br>spacing. This complicates \
the vertical spacing docs simply because<br>PianoStaff overrides introduce a new set \
of properties, viz 11.3.2 and<br>
11.3.4:<br><br> \override VerticalAlignment #'forced-distance = \
#7<br><br> \overrideProperty<br> \
#"Score.NonMusicalPaperColumn"<br> \
#'line-break-system-details<br> #'((fixed-alignment-extra-space . \
15))<br>
<br>(IMO, possibly the best reason to remove the specialness of PianoStaff<br>with \
regards to fixed spacing is to clean up this part of the docs.)<br><br>So these are \
the two different dichotomies I see in the background of<br>
any decisions (or docs) on vertical spacing: which "method" to \
use<br>(either "permissive" with VerticalAxisGroup or "strict" \
with<br>line-break-system-details) and then PianoStaff / nonPianoStaff. The<br>
dichotomies are completely orthogonal: whether you decide to \
use<br>"permissive" or "strict" vertical spacing, you still must \
be<br>constantly aware of whether you're setting spacing for a PianoStaff or<br>
not and select properties to override accordingly.<br><br>* * *<br><br>So I guess my \
point in all this is to see if anyone resonates with<br>this way of looking at user \
control of vertical spacing. Perhaps all<br>this is quite obvious, but it certainly \
took me a good while to figure<br>
out.</blockquote><div><br><br>Hi Frederick,<br><br>Your summary of the vertical \
spacing possibilities certainly makes sense to me. I especially like your mention of \
the idea of a settings cascade. If we ask which of the two settings-types applies \
first, the answer would have to be the "strict" settings governed by \
line-break-system-details. Thereafter, lily uses "permissive" / \
padding-based settings for any decisions that remain to be made. In the case that the \
user specifies no "strict" / line-break-system-details settings (which is \
almost always the case, especially for new / normal users of the system), then the \
"permissive" / padding-based settings are the only settings which will \
factor into the spacing problem.<br> <br>So, that makes me think that it would be \
possible to present the vertical spacing docs in that order: "strict" and \
then "permissive", following the order of the settings cascade.<br><br>But \
the only thing that's weird about that is that the "strict" settings \
are -- I think -- the more exotic settings. So it might be strange to lead the \
chapter on vertical spacing with those more exotic settings first.<br> <br>And \
Joe's point about PianoStaff's specialness going away is a good thing and the \
vertical spacing docs shoudl change to reflect that.<br><br><br></div></div><br><br \
clear="all"><br>-- <br>Trevor Bača<br><a \
href="mailto:trevorbaca@gmail.com">trevorbaca@gmail.com</a><br>
</div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic