lilypond-devel
[Top][All Lists]
Advanced

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

Re: Another vertical page layout issue


From: David Kastrup
Subject: Re: Another vertical page layout issue
Date: Fri, 15 Jan 2010 09:06:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux)

Reinhold Kainhofer <address@hidden> writes:

> Hi again, The attached file contains two almost identical scores (just
> the lenght of them varies) without any special settings. However, the
> vertical layout of both scores with identical settings is radically
> different: -) The first, 6-measure score is placed on 6 (!!!) pages,
> with one measure per page. Due to RemoveEmptyStaffContext, some pages
> contain only one system with two staves, stretched VERY, VERY wide.
> -) Strangely, the second, 16-measure score is normally stretched, with
> 2-4 systems per page, resulting in only 5 pages for this score...
>
> Is this yet another problem in the vertical layout code?

>From the reports so far I get the impression that the new vertical
layout code is fundamentally broken, and the last fixes to it have
mostly been skirting the issue, in the class of "I don't know why this
would happen, but we can fix it this way".  As more and more utterly
wrong cases get patched away, the issue gets hidden more and more.  The
result being wrong decisions that get ameliorated by "fixes" until the
most glaring cases are masked.

When the real problem may be something like "<" being used somewhere
instead of ">", or a similar problem.

Joe, would you say that the bad cases you fixed so far had "a right" to
occur before your fixes, in that one could naturally see how they would
arise as a consequence of the chosen algorithm and its design goals?

If that's the case, one should likely reconsider the design goals and
the basic algorithm rather than patching it up.

If it's not the case, there is an implementation problem, and patching
around locally is going to make it harder to understand the code and to
find the real issue.

I've written global page break optimization code (in the context of TeX
programming) myself, and gone through similar experiences where I
recoded and recoded and a rather glaring sign error that should have
wrecked things rather obviously managed to stay around for at least a
year because it was masked in many cases.

And the current series of reports reminds me more than comfortable of
that experience, with symptoms looking even worse than in my case.

-- 
David Kastrup





reply via email to

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