Re: Doc: NR 4.4.1: Rewrite. (issue2642043)

[joeneeman]

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1662
Documentation/notation/spacing.itely:1662:
@code{after-last-staff-spacing}).
On 2010/10/29 04:12:45, Keith wrote:
> On 2010/10/27 08:44:41, Mark Polesky wrote:
> > What's a better way to word it?
> "... leave this property unset, because if set it will be used instead
of any
> StaffGrouper property that would have otherwise applied."

There are some situations where you might want to override this, so I'm
not sure if the docs have such a blanket statement. The point is that
all of the logic involving StaffGrouper and its spacing variables is
contained in the default callback associated with next-staff-spacing
(ly:axis-group-interface::calc-next-staff-spacing). If you override that
default callback, you will disable that logic for the relevant staff.

However (and this is the source of my original comment) you will not
actually override any of the properties in StaffGrouper, as the
following example demonstrates:

\new StaffGroup <<
% The override doesn't change the value of anything in
% StaffGrouper. You can see this because the original
% value of between-staff-spacing is used for all staves
% but the first. Also, you can't achieve this effect by
% changing 'default-next-staff-spacing, which shows that it
% is sometimes useful to override 'next-staff-spacing.
\new Staff \with { \override VerticalAxisGroup #'next-staff-spacing
#'space = #30 } { c'1 }
\new Staff { c'1 }
\new Staff { c'1 }


The above is probably an excessively long explanation for the docs. I
would suggest something like "...since setting it will prevent
StaffGrouper variables (such as ...) from having any effect on the
current staff."

http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1679
Documentation/notation/spacing.itely:1679: either side.  Adjacent
staff-like contexts should have
On 2010/10/27 08:44:41, Mark Polesky wrote:
> On 2010/10/26 22:28:16, joeneeman wrote:
> > I'm not sure how precise you want to be here, but this
> > isn't quite true: if the upper staff, for example, has a
> > very low note then a lyrics line with CENTER affinity
> > might be placed closer to the lower staff.
> >
> > Also, by "equidistant between the ... staves," you mean
> > "equidistant between the refpoints of the staves," right?

> That's what I meant, but based on your previous statement, I
> assume even that would be incorrect.  In fact, this is
> clearly wrong, since the refpoints of the staves are the
> midlines, right?  So is it centered between the skylines?

It is "centered" between refpoints in the sense that its desired
position is for its refpoint to be exactly centered between the
refpoints of the surrounding staves. But it may not achieve this desired
position due to other constraints like collisions or minimum-distances.

http://codereview.appspot.com/2642043/