Joe Neeman <[email protected]> writes:

> On Fri, 2010-01-15 at 09:06 +0100, David Kastrup wrote:

[...]

> The main issue with the page-breaking code is that finding the actual
> outlines of systems is too expensive, so we use estimates which aren't
> (and will probably never be) perfect.

Estimates need not be perfect, but they may not be too optimistic.

> The recent overfull-page issues stem from the fix for 496 (which fixed
> a height overestimation issue and therefore exposed some height
> underestimation issues). 4906be555c is an exception: it was caused by
> a somewhat subtle bug that had been around for a while. But the fix
> made sense, in that it fixed a genuine bug rather than papering over
> something.

[...]

>> 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.
>
> That depends. If the "local" patches fix mistakes without adding
> complexity, I don't think they make the code harder to understand.

As long as they fix mistakes rather than symptoms (namely: one can see
where the _code_ went wrong, not just that the _result_ is wrong), I
have no problem.

> I believe that my last 3 patches to the page layout code (0f9645def2,
> fcfbd212006 and 2bed451f9a) fall under this category.

[...]

> There may well be sign errors in the current code (there certainly
> were some previously in the new layout code). However, I don't think
> there is a single, glaring mistake underlying the recent page-layout
> bugs since I don't believe that I've been pushing any "mysterious,"
> "covering-things-up" kind of patches. But if you find examples, I'm
> happy to be corrected.

I don't have the resources for that kind of research right now, so I
just contributed my more or less keyword-triggered queasiness.  Which is
not a fair substitute.

-- 
David Kastrup



_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to