On 10/5/10 12:09 PM, "Mark Polesky" <markpole...@yahoo.com> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel