bug-lilypond
[Top][All Lists]
Advanced

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

Re: stemlength II


From: David Kastrup
Subject: Re: stemlength II
Date: Thu, 14 Apr 2011 12:50:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

"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
situations.

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




reply via email to

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