On 2010-10-09 17:46, Mark Polesky wrote:
CURRENT NAME PROPOSED NAME ------------ ------------- top-system top-system top-title top-markup between-title markup-markup after-title markup-system between-system system-system before-title system-markup bottom-system system-bottom between-scores-system score-system
Huh. Sorry that I missed the weekend discussion; in general I support these names. I'm not quite sure if they will be clearer to the "everyday user" who mainly thinks in terms of titles and scores, headers and footers, though, and probably won't have a bunch of settings for all of these, but rather uses the default for everything but what used to be 'after-title-spacing. [1] But since the new names are consistent and I definitely lack to come up with something more clever, I'm satisfied. (At least until GLISS, that is.)
[1] I tried to figure out what's the buzz with scoreTitleMarkups and bookTitleMarkups. From a user's POV, both of them are top-level-markups, right? Is there anything different because one belongs to the score and the other to the book (aka "real" top-level)? I think after-title and between-title are the perfect identifiers for the spacing between those, but the whole naming system gets messed up if you include custom markups. /Perhaps/ I'd like aliases, but I don't want to think about this until GLISS. And, essentially, aliases are ugly anyway, so encapsulating headers in a separate category (score - markup - headerMarkup?) may be better, or... Not something to discuss now.
By the way, right now it isn't possible to change spacing /in between/ of a book environment, is it? It's reasonable to think that the very main header (and the very first music line) will need a different spacing than all other markup-system-pairs, even if a scoreTitleMarkup is absent. So it'd be cool to allow changing the spacing variables inside the book block, or have some LaTeX-\vfill-like command with the four spacing variables as arguments: \vspace #'((spacing . 5) (stretchability . 20)), ... you get the point. But again, this looks like a major (read: postponed) change is necessary.
Cheers, Alexander _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
