On Sat, Oct 2, 2010 at 5:56 AM, David Kastrup <d...@gnu.org> wrote:
> David Kastrup <d...@gnu.org> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
