lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's with the spacing code?


From: Joe Neeman
Subject: Re: What's with the spacing code?
Date: Sat, 2 Oct 2010 19:28:15 -0700



On Sat, Oct 2, 2010 at 5:56 AM, David Kastrup <address@hidden> wrote:
David Kastrup <address@hidden> writes:

> With the current code, a score that used to take 5 pages now takes 8,
> really really spaced out.
>
> I don't see that we can release a version of Lilypond that takes up
> horrifically more space than the previous not-skyline-based code.
>
> Making use of the skyline instead of the bounding box should never lead
> to results taking _more_ space.

The recent checkin makes for somewhat better results.  Obviously, the
assumption of non-overlap now leads to a reverse problem:

\repeat unfold 480 { c'^\markup { longword anotherone } }

This contrived example shows two more issues: issue 1 is that we are
estimating too short right now.

Ok, but the heights here are impossible to estimate accurately because we don't know how much overlap there will be unless we do the horizontal spacing. One possible improvement would be to assume overlap only if the markups are in the same Paper column.

Issue 2 is more disconcerting: even if things worked like intended, the
visual relationship between Note and markup gets lost.

Issue 1 could be addressed by improving the coarse pre-pagebreak
estimate: make sure that the total _area_ of markups fits on the page.
With the sort of juggling achieved by markup positioning, that could
actually be not all too far from the truth.

The problem is that this sort of optimally dense packaging is
detrimental to making the score understandable.  There is a point in
time where instead of juggling with the markup stacking, one needs to
bite the bullet and push the notes somewhat more apart.

Sure, but writing down a good algorithm for deciding when to do this doesn't seem easy. At some point, I think it's reasonable to ask the user for a little manual help (eg. extra-spacing-width).
 
The latter is likely not material for a release soon, as the mode of
operation is pretty much "working as intended".  But improving the
bounds of height estimate would seem desirable.

Sure, but the bigger priority is to get the existing estimates working with RehearsalMarks.

Joe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]