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
