Originally created by: *anonymous
Originally created by: pnorcks@gmail.com
This is a regression between 2.13.24 and 2.13.25.
Original report: http://lists.gnu.org/archive/html/bug-lilypond/2010-06/msg00424.html
%%%%%%%%%%
\version "2.13.25"
\include "english.ly"
thenotesI = \relative g' {
g2( af)
}
thenotesII = \relative af {
[r8] af( df ef f2)
}
\score {
\new Staff << \thenotesI \\ \thenotesII >>
}
%%%%%%%%%%
Originally posted by: frederic...@gtempaccount.com
I am starting git bisect to find where it comes from.
Originally posted by: frederic...@gtempaccount.com
Here is the guilty commit: [ree0488f3aa19e0060b6e17c46a4d88cb9d57c489]
commit [ree0488f3aa19e0060b6e17c46a4d88cb9d57c489]
Author: Joe Neeman <...>
Date: Fri Jun 18 16:53:17 2010 +0300
Joe, can you have a look?
Originally posted by: joenee...@gmail.com
Thanks for bisecting.
Labels: fixed_2_13_27
Status: Fixed
Originally posted by: lilyli...@googlemail.com
This has only partly been fixed.
When running the snippet with 2.13.27 the first collision (accidental and preceding rest) is omitted but the second (accidental and ledger line) is still present.
See attached image.
I don't know how to proceed with it. Change the status? "Give it back" to a developer? mark it verified and open a new issue?
Best
Urs
Originally posted by: lilyli...@googlemail.com
As advised to me on bug-lilypond I change the status of this issue.
Labels: -fixed_2_13_27
Status: Started
Originally posted by: joenee...@gmail.com
I maintain that this second issue is not a regression. If you change the as to fes, you will see that 2.12 does not avoid collisions between accidentals and ledger lines. The fact that it appeared to avoid these collisions in the above example is actually a bug: lilypond thought that it was avoiding a collision between the accidental and the note-head of as.
Regardless, this is fixed now.
Labels: fixed_2_13_29
Status: Fixed
Originally posted by: lilyli...@googlemail.com
OK, I'll verify once I have 2.13.29
Originally posted by: reinhold...@gmail.com
I'm still running into collisions of accidentals with rests in 2.13.29...
Attached is a sample file (from a real project I'm working on right now) where the 64-th note collides with the accidental of the following 64-th note.
Originally posted by: pkx1...@hotmail.com
Here is the png file (preferred over pdf)
Originally posted by: pkx1...@hotmail.com
Also this reminded me of something I had seen recently, and I apologise is this not the same issue I am getting collisions on 2.13.29 here:
\relative c' {
| c'8 (des,) e f c' (d,!) e f c' (d,?) e f c' (dis,) e f
}
Originally posted by: reinhold...@gmail.com
(No comment was entered for this change.)
Status: Accepted
Originally posted by: joenee...@gmail.com
This is a different bug and not a regression (2.12.3 gives the same behavior). It is tricky to fix because the cause is a cyclic dependency: we cannot format the beam until the horizontal spacing is determined, but it isn't until the beam is formatted that we know where the rest should be placed.
Originally posted by: joenee...@gmail.com
By the way, the following is a minimal example for Reinhold's bug:
\version "2.12.0"
\layout {
\context {
\Score
\override SpacingSpanner #'common-shortest-duration = #(ly:make-moment 1 8)
}
}
\relative c''' { e32[ [r64] deses] }
Originally posted by: percival.music.ca@gmail.com
Here's a re-uploaded image from comment 11. I suspect that google code is case-sensitive about the .PNG portion. :(
Originally posted by: percival.music.ca@gmail.com
WTF?! I definitely expected that one to work. ok, let's try again, with all lower-case.
Originally posted by: percival.music.ca@gmail.com
another test, sorry.
Originally posted by: percival.music.ca@gmail.com
*shrug* ok, I have no idea. I created that last image just like I used to create all the previous ones. It has a lower-case filename, it's a small file size, etc etc.
On another topic, since this is Accepted and not Fixed, we should remove the fixed_2_13_29 tag.
Labels: -fixed_2_13_29
Originally posted by: pnorcks@gmail.com
You're not doing anything wrong. It's a recent problem with Google code hosting:
https://code.google.com/p/support/issues/detail?id=4266
Originally posted by: joenee...@gmail.com
I still think this bug is fixed. The bug in comment 8 is not a regression and the bug in comment 11 is about collisions between slurs and rests. Neither is a regression, AFAICT, and so they should have new bugs (which are not marked critical).
Originally posted by: percival.music.ca@gmail.com
That sounds reasonable. Could a Bug Squad person mark this one as fixed (in 2.13.29), and make two separate issues for those other reports?
Originally posted by: percival.music.ca@gmail.com
Original bug was fixed.
Comment #8 was already reported in issue 472.
Comment #11 was already reported in issue 796.
Labels: fixed_2_13_29
Originally posted by: percival.music.ca@gmail.com
mao, forgot to close it.
Status: Fixed
Originally posted by: brownian.box@gmail.com
(No comment was entered for this change.)
Status: Verified