Re: attachment points for vertical spacing dimensions
On 2010-10-07 04:11, Joe Neeman wrote: On Wed, Oct 6, 2010 at 1:26 AM, Mark Polesky markpole...@yahoo.com mailto:markpole...@yahoo.com wrote: Joe Neeman wrote: I would argue that the baseline is more natural then the bottom. Moreover, using the baseline as a reference point will result in more even spacing of multiple consecutive lines of markup. Okay, that's a good point, so I agree -- baseline is better than bottom. But do you agree with Carl and Trevor that we should always use the same reference point for markups? I was specifically proposing to use the bottom of the upper markup and the top of the lower markup for between-title-spacing, but Carl argued eloquently against it. Carl's argument is probably much more solid than mine, but just for the record, what do you think? I don't care so much about one versus two reference points (although the current code only works with one), but I do think that the reference points should not depend on any ascenders or descenders. Hm, I'm not sure. The baseline in some sense is the natural place to attach references to - that's how it's done in most applications I can think of. On the other, hand, these typically deal with single lines on their own... For a markup placed /above/ a staff (or another markup, by the same argument), the baseline of the lowest line of the markup is a sensible reference (even better than the bottom corner, since, as you pointed out, this does not depend on an ascender). However, this is a poor choice for markups (like footer) /below/ a staff - if you add a line here, you'd have to redo spacing. Using the baseline of the top-most line would be better, but looks far harder to code. Furthermore, both baselines don't allow a good handling of the case of non-character markups (a score - What's the baseline there? The middle line of some staff? -, a figure, whatever) which has larger height than a letter of the default font. And font sizing doesn't change the baseline, but the ascender and descender height. Honestly, I don't think it's worth the hassle. IMHO, we should try to give reasonable definitions, but not to deal with each and every possible use case; the user needs to tweak, and he probably won't find the optimal values for all these spacing variables by anything but trial-and-error. Let's not complicate this by overcluttering with a huge bunch of options. As for fonts, it's not too hard to guess the extent of a line, especially since baseline-skip is given in staff units. The topmost point as anchor works fine in many cases, and padding additionally is there to avoid trouble. The only point the current layout does not work well for me is tweaking the pages s.t. the topmost and bottommost (center lines of) staves align over all pages, but even there I can perfectly live with a manual positioning of the footer and, optionally, a \with-dimension #'(0 . 0) #'(0 . 0) there. And if the very last line of a score is slightly above the others, I don't feel it disturbs the overall impression. Things are easier for the top, since the first page has the book header, and the page number has the same extent on all the others. I've noticed that in many traditionally-engraved scores, [...] For example, say score1 has title/subtitle/etc. in the usual place (top center), and piece/opus also in the usual place (flush left and flush right just above the top system), and the top system has no protruding skyline. Now score2 has all the same titling but the top system has a really high note just before the rightmost barline. To prevent a collision between the last note and the opus, LilyPond will shift the first system down. Fine. But what I've noticed in the classic scores is that in this situation, the top system is not shifted down, but rather the opus is shifted *up*. This is an important difference! It means that the placement of the top system is determined by the bookTitleMarkup, and the scoreTitleMarkup is determined by the top system. And it usually looks better this way (and more consistent from score to score). [...] I won't say it's more trouble than it's worth, but I don't think it's trivial. In lilypond-spacing-backend terms, I think you want to treat the opus markup as a loose line. Now, that'd be an feature... Even assuming that we'd have to take opus out of the header tags - can one manually add loose lines besides Lyrics? Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
Mark Polesky wrote Tuesday, October 05, 2010 7:09 PM http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00070.html Let me know what you guys think; it would be nice to achieve consensus on this one. I'm with Carl on this. I agree with all his comments. Further to my suggestion to leave the renaming to GLISS, so far there have been only comments supporting the renaming, even from Joe. Since no discussion seems to be necessary, do you think it might be better to change the names before 2.14? That way users would only have to understand one change in the stable releases rather than two. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
Well, so many extensive replies to respond to! It's great, but it makes for a long post, and I do hope the thread participants read to the end; there's a lot of relevant stuff for everyone here. Thanks. * * * * * * * * * * Joe Neeman wrote: I would argue that the baseline is more natural then the bottom. Moreover, using the baseline as a reference point will result in more even spacing of multiple consecutive lines of markup. Okay, that's a good point, so I agree -- baseline is better than bottom. But do you agree with Carl and Trevor that we should always use the same reference point for markups? I was specifically proposing to use the bottom of the upper markup and the top of the lower markup for between-title-spacing, but Carl argued eloquently against it. Carl's argument is probably much more solid than mine, but just for the record, what do you think? 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. This is not actually true (even if we change the refpoint to the bottom) because minimum-distance measures the distance from the refpoint of the markup to the *refpoint* of the next system, while padding measures the distance to the *top* of the next system. Now I see my error, thanks. Personally, I think we should add a new variable to control the spacing between a markup and the bottom margin. We could call it bottom-markup-spacing for now, but see this post for my proposed variable renaming: This is easy enough to add (and the naming seems fine to me). Carl, are you opposed to bottom-markup-spacing (or markup-bottom-spacing in the new naming system) for any reason? * * * * * * * * * * Alexander Kobel wrote: I regularly use 'minimum-distance and a large negative 'padding in bottom-system-spacing to align the last staves to the same Y-offset, regardless of single note descenders or similar. Also, this is a case where I actually wish the reference point of the markup were on the opposite side, i.e. the bottom of the markup (or top of the bottom margin), s.t. any copyright or tagline really stays inside the footer and does not destroy the alignment of the staves on the page. That'd amount to introducing a new last-staff-to-bottom-margin-spacing and leaving bottom-system-spacing as is, or - functionally equivalent, but somehow irritatingly - shifting the attachment point of bottom-system-spacing to the bottom of the markup and adding last-staff-to-top-of-markup-spacing. @ Mark: is the latter what you meant with your idea from above? No, I don't think so, my idea was not so sophisticated. What I meant with bottom-markup-spacing was to split the current action of bottom-system-spacing into two variables, one to control the spacing above the bottom-margin when a system is the lowest printed item, and one to control the spacing above the bottom-margin when a markup is the lowest printed item. That being said, your more intricate suggestions are definitely interesting, and while I'm probably a little too tired to comment on them right now, I hope the others share their thoughts on them. However, this reminds me of yet another issue (and IMO a significant one) that I keep forgetting to mention: I've noticed that in many traditionally-engraved scores, the distance from the bookTitleMarkup baseline to the first system seems to be *independent* of the distance from the scoreTitleMarkup baseline to the first system. For example, say score1 has title/subtitle/etc. in the usual place (top center), and piece/opus also in the usual place (flush left and flush right just above the top system), and the top system has no protruding skyline. Now score2 has all the same titling but the top system has a really high note just before the rightmost barline. To prevent a collision between the last note and the opus, LilyPond will shift the first system down. Fine. But what I've noticed in the classic scores is that in this situation, the top system is not shifted down, but rather the opus is shifted *up*. This is an important difference! It means that the placement of the top system is determined by the bookTitleMarkup, and the scoreTitleMarkup is determined by the top system. And it usually looks better this way (and more consistent from score to score). I guess I wouldn't be surprised if Joe says that this would be more trouble than it's worth*, since it seems to go against the whole pattern of the current spacing algorithm, but I think it would be a big step towards fully professional-quality scores. *and if he says it would be easy, well that would just make my day... Joe? * * * * * * * * * * Trevor Daniels wrote: Further to my suggestion to leave the renaming to GLISS, so far there have been only comments supporting the renaming, even from Joe. Since no discussion seems to be
Re: attachment points for vertical spacing dimensions
Mark Polesky: Personally, I think we should add a new variable to control the spacing between a markup and the bottom margin. We could call it bottom-markup-spacing for now, but see this post for my proposed variable renaming: Joe Neeman: This is easy enough to add (and the naming seems fine to me). Mark: Carl, are you opposed to bottom-markup-spacing (or markup-bottom-spacing in the new naming system) for any reason? I think I'd just prefer a single variable last-item-bottom-spacing that would apply to the last item, whether it's a system or a markup. I think having two separate variables complicates the issue. But I don't feel strongly about this, and I could be easily swayed by a counter-argument. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
On Wed, Oct 06, 2010 at 08:50:20AM +0100, Trevor Daniels wrote: Further to my suggestion to leave the renaming to GLISS, so far there have been only comments supporting the renaming, even from Joe. Since no discussion seems to be necessary, do you think it might be better to change the names before 2.14? That way users would only have to understand one change in the stable releases rather than two. I don't quite understand that final sentence, but I agree with the rest -- especially since GLISS (1) will almost certainly not be discussing property names. Since we're changing the vertical spacing for 2.14 anyway, let's change the spacing names as well. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
On Wed, Oct 6, 2010 at 1:26 AM, Mark Polesky markpole...@yahoo.com wrote: Well, so many extensive replies to respond to! It's great, but it makes for a long post, and I do hope the thread participants read to the end; there's a lot of relevant stuff for everyone here. Thanks. * * * * * * * * * * Joe Neeman wrote: I would argue that the baseline is more natural then the bottom. Moreover, using the baseline as a reference point will result in more even spacing of multiple consecutive lines of markup. Okay, that's a good point, so I agree -- baseline is better than bottom. But do you agree with Carl and Trevor that we should always use the same reference point for markups? I was specifically proposing to use the bottom of the upper markup and the top of the lower markup for between-title-spacing, but Carl argued eloquently against it. Carl's argument is probably much more solid than mine, but just for the record, what do you think? I don't care so much about one versus two reference points (although the current code only works with one), but I do think that the reference points should not depend on any ascenders or descenders. I've noticed that in many traditionally-engraved scores, the distance from the bookTitleMarkup baseline to the first system seems to be *independent* of the distance from the scoreTitleMarkup baseline to the first system. For example, say score1 has title/subtitle/etc. in the usual place (top center), and piece/opus also in the usual place (flush left and flush right just above the top system), and the top system has no protruding skyline. Now score2 has all the same titling but the top system has a really high note just before the rightmost barline. To prevent a collision between the last note and the opus, LilyPond will shift the first system down. Fine. But what I've noticed in the classic scores is that in this situation, the top system is not shifted down, but rather the opus is shifted *up*. This is an important difference! It means that the placement of the top system is determined by the bookTitleMarkup, and the scoreTitleMarkup is determined by the top system. And it usually looks better this way (and more consistent from score to score). I guess I wouldn't be surprised if Joe says that this would be more trouble than it's worth*, since it seems to go against the whole pattern of the current spacing algorithm, but I think it would be a big step towards fully professional-quality scores. *and if he says it would be easy, well that would just make my day... I won't say it's more trouble than it's worth, but I don't think it's trivial. In lilypond-spacing-backend terms, I think you want to treat the opus markup as a loose line. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
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
Re: attachment points for vertical spacing dimensions
On Tue, Oct 5, 2010 at 11:09 AM, 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 would argue that the baseline is more natural then the bottom. Moreover, using the baseline as a reference point will result in more even spacing of multiple consecutive lines of markup. 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. This is not actually true (even if we change the refpoint to the bottom) because minimum-distance measures the distance from the refpoint of the markup to the *refpoint* of the next system, while padding measures the distance to the *top* of the next system. 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. 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). Personally, I think we should add a new variable to control the spacing between a markup and the bottom margin. We could call it bottom-markup-spacing for now, but see this post for my proposed variable renaming: This is easy enough to add (and the naming seems fine to me). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
On 2010-10-05 21:53, Carl Sorensen wrote: On 10/5/10 12:09 PM, Mark Poleskymarkpole...@yahoo.com wrote: 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. I regularly use 'minimum-distance and a large negative 'padding in bottom-system-spacing to align the last staves to the same Y-offset, regardless of single note descenders or similar. Also, this is a case where I actually wish the reference point of the markup were on the opposite side, i.e. the bottom of the markup (or top of the bottom margin), s.t. any copyright or tagline really stays inside the footer and does not destroy the alignment of the staves on the page. That'd amount to introducing a new last-staff-to-bottom-margin-spacing and leaving bottom-system-spacing as is, or - functionally equivalent, but somehow irritatingly - shifting the attachment point of bottom-system-spacing to the bottom of the markup and adding last-staff-to-top-of-markup-spacing. Personally, I think we should add a new variable to control the spacing between a markup and the bottom margin. We could call it bottom-markup-spacing for now @ Mark: is the latter what you meant with your idea from above? Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
