Hi Keith, 2013/11/16 Keith E OHara <k-oh...@oco.net>: > I'm fixing a bug involving the ragged-bottom setting (issue 3281). By > default, ragged-last-bottom=##t so the last page can have blank space at the > bottom. Currently, "ragged-bottom" is implemented to *always* under-fill > the page, *never* compressing to fit one more system. > > As a default, that is wrong, because all the other pages are best-fit, while > the last page is under-filled. The situation has caused me quite a lot of > confusion: wondering why LilyPond likes to put the last system on its own > page, decreasing the staff-size, or trying page-turn-breaking -- and then > wondering why so much material moved back to earlier pages, so that the last > page is again the least full.
Very interesting observation! > So 'ragged-last-bottom' should allow a gap at the bottom of the last page, > but let the page fill as the others are filled. But I do not know what > 'ragged-bottom' should do. This is the option that applies to all pages. > Werner sees some sense in 'ragged-bottom' meaning that pages are neither > stretched nor compressed vertically, but cannot think of an example where > this behavior is useful. > > So for what kind of music do you use ragged-bottom=##t ? Here's one case: i want to analyze a lot of small examples, and i put them into documents as mini-scores: { c d e f } { d e f g } { e f g a } etc. And i have multiple documents, each containing multiple examples. Let's say in one document examples don't fill the page, so they are spaced "naturally", while in the other document there is a lot of examples and more than one page is filled. When comparing these documents I want the examples to align vertically - so, i don't want the examples in the longer document neither stretched nor compressed vertically. Does this make sense? By the way, ragged-right seems to work exactly the same as ragged-bottom now. When laying measures with ragged-right, lilypond will always move a measure to the next line if it won't fit in the current line without compression. Even if it the necessary compression would be minimal. In general, i believe that it would be best to change the current interface. Instead of "ragged-something" (i think this word is not very intuitive), we could have properties named "horizontal-fitting" etc. with the following possible values: - ragged (i.e. spaced naturally, no compressing or stretching allowed) - justified (stretched or compressed to fit the margins) - allow compressing, but not stretching (this would do what you suggest) - allow stretching, but not compressing If we want to be extra-awesome, we could allow to specify how much stretching and compressing is allowed. And btw, i think that it would be good if we had separate stretchability and compressability properties. For example, when i have a SATB choral piece and vertical spacing is cramped, the distances between staves should be compressed more than the distances between systems (because it's very important that the systems remain visually separate). However, when there is a lot of vertical space, it's the distances between systems that should stretch more than distances between staves (as we don't want to have "airy" systems). So, system-system distances should have high stretchability but low compressability compared to staff-staff distances. hth, Janek _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user