Re: attachment points for vertical spacing dimensions

[Carl Sorensen]

On 10/5/10 12:09 PM, "Mark Polesky" <address@hidden> wrote:

> WRT the flexible vertical spacing dimensions, the upper
> attachment points for 'space and 'minimum-distance currently
> align with the Y-coordinate of the origin (0,0) of the upper
> item.  For systems this is the middle line of the nearest
> staff, and for markups this is the highest point of the
> markup.  In the newest docs (NR 4.1.2 as of yesterday),
> these are called "reference points".
> 
> I think that most of the resulting dimensions are what the
> user would naturally expect them to be, except when the
> upper item is a title/markup.  In these cases, I think the
> most natural attachment point would be the *bottom* of the
> upper markup.

I actually think that the top reference is more consistent with the staff
behavior, in that the spacing doesn't take into account the extent of the
object.

Spacing between staves doesn't look at how high or low the contents of the
staff go; it just looks at the space between the reference points.  Once we
understand that meaning, it's very consistent.

top-markup-spacing is the spacing between the top of the page and the markup
(title) that is the first thing on the page.  Markup-system-spacing is the
spacing between that markup and the first system on the page.  And it uses
the reference points for both.

Similarly, spacing between markups shouldn't look at the size of the markup;
it should define a desired spacing.

The desire to keep items separate should be accomodated by padding, which is
used to guarantee a minimum amount of whitespace.

By moving the reference point to the bottom of the markup, you are making
the size of the top markup part of the page layout size.  I can see that
this is desirable in one sense, because we are concerned about the space
between the bottom of the markup and the top of the score.  But it's
undesirable in another sense, because our spacing can't account for all of
the space on the page.

In the current setup, all of the space on the page is accounted for in the
spacing settings, and we can manage the space between elements with the
padding settings.

I think using it as it is with a correct understanding due to the excellent
documentation you're preparing, and with the new names you're proposing, is
the right way to do it.

> 
> This applies to 3 of the 8 flexible vertical dimensions:
>   * after-title-spacing
>   * between-title-spacing
>   * bottom-system-spacing
> 
> The proposed change to after-title-spacing needs no comment.
> 
> For between-title-spacing however, I should mention that if
> the upper attachment point (of 'space and 'minimum-distance)
> is moved to the bottom of the upper markup, then the
> 'padding value is basically rendered redundant.  In that
> case, 'padding would only influence the spacing if it were
> larger than 'minimum-distance, and making 'padding larger
> than 'minimum-distance is generally pointless since that in
> turn would render 'minimum-distance redundant.  That being
> said, I don't think this is a problem; the spacing behavior
> would still be more natural IMO.  And a simple explanation
> for this unique case could be added to the docs.

As I mentioned above, I *like* the idea that spacing is between reference
points, and padding is between skylines.  Keeping it as-is would make this
behavior consistent across the board.


> 
> Of the three, bottom-system-spacing is slightly more
> complicated, since it currently controls the spacing below
> systems *and* markups, when either is the last on a page.
> So the natural attachment point for systems would remain the
> same, but would be shifted to the lowest Y-coordinate for
> markups (ideally).


Again, I like the name last-item-spacing, which would apply to whatever is
the final layout item and the bottom margin.

Again, with proper understanding of padding, I think everything works
properly.

As I now understand things, I think that I would be unlikely to use
minimum-distance for anything.  I think I'd just use space and padding.


Thanks,

Carl