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
