[Top][All Lists]

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

Re: stemlength II

From: Phil Holmes
Subject: Re: stemlength II
Date: Thu, 14 Apr 2011 13:00:51 +0100

"David Kastrup" <address@hidden> wrote in message news:address@hidden
"Phil Holmes" <address@hidden> writes:

AFAICS it's not a bug.  The stem is lengthened to avoid a collision
with a stem in another voice.  Unfortunately it didn't collide in the
first place. To allow this to be corrected, Mike allowed the collision
avoidance code to be turned on and off with the override, and using
this override with the above code produces good output.  I guess we
could argue that lengthening a stem to avoid a collision that isn't a
collision is a bug, but I wouldn't do so without Mike's input.

Hm?  A bug with an explanation and a workaround is still a bug as far as
I can see.  Mike's input may be needed in order to decide whether to
postpone a fix, due to required effort and/or upcoming changes that
would address it anyway.  As a consequence of such postponement, one
might decide to document the workaround as a workaround in such

But if Lilypond does something wrong, whether or not we know perfectly
well why it does that, it is an issue and should be registered as such
without requiring further input.

Things are different if the result is deficient, and one can prove that
it is physically impossible to do better than that, given the task
specified by the input.

I have an automated system for typesetting nested layers of footnotes in
TeX, and due to the nesting, the _order_ of lower footnote blocks
depends on the page break decisions in higher blocks.

For every new volume subjected to this system, I get about 10 bug
reports per 1000 pages that amount to "half the page is left blank!  Why
doesn't the system put more lines on the previous page?".  And the
answer is usually something "if I move one more line from the main text
to the previous page, this makes the layer 2 footnote in this line to
the previous page as well.  Now we already have a layer 2 footnote
anchored in a layer 1 footnote anchored in the main text.  Since this
layer 2 footnote is anchored in a layer 1 footnote, it will move
_behind_ the layer 1 footnote we got moved over from the next page.  But
since only the last footnote in one layer can be broken across pages,
the layer 1 footnote we moved over from the previous page must appear
completely.  It takes 3 quarters of a page, and even if we split the
last footnote in layer 1 (which was on this page to start with), we
don't get enough free space to bring the whole of that footnote over."

In short: impossible to do better, even though it looks glaringly wrong,
and glaringly trivial to fix.  Until you actually try doing so in
detail.  Not because of algorithmic deficiencies, but because the
defined task is physically impossible to do better.

Even in such a case (which we don't have here as far as I can see), it
is a good idea to register an issue, and mark it as invalid with an
explanation of the reason.  Because it will come up again every month,
and it makes sense to point to the invalid issue and the explanation.

But if we refuse registering an existing or even an apparent issue, the
information about what makes this issue invalid or postponed or whatever
else is going to get lost, and needs to be rewritten every time the
question appears again.

David Kastrup

OK.  http://code.google.com/p/lilypond/issues/detail?id=1613

Phil Holmes
Bug Squad

reply via email to

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