Re: Potential issue 39 fix w/ patch

[Mike Solomon]

New patch set that moves the stem up - regtests check out OK.

http://codereview.appspot.com/3934041/

For some reason, the side-by-side diffs don't work for the last file, but as you'll see in the unified diff, the change is trivial.

Attached is a PDF of the regtest I created for this patch.

Cheers,

MS

0002-Fixes-issue-39-by-raising-stems.patch
Description: Binary data

0001-Potential-fix-for-issue-39.patch
Description: Binary data

flag-collision.pdf
Description: Adobe PDF document

On Jan 7, 2011, at 5:42 PM, Keith OHara wrote:

-------- Original Message --------

From: "Mike Solomon" <address@hidden>

Sent: Thursday, January 06, 2011 10:03 AM

Mike,
The patch moves 8th notes unnecessarily.
The patch breaks the collision resolution of dotted notes.
If you have to move the notehead, you're moving it the wrong direction.  

Test music attached.  I notice that LilyPond moves an undotted upstem note
to the left, away from a dotted note, but usually the first priority is to
keep simultaneous noteheads as close as possible.  For perspective, I
included a couple collisions LilyPond has never tried to resolve
automatically. (The last one is allowed intentionally, surprisingly, see
code comments regarding the boolean 'touch'; there might be a very good
reason, or it might have been a mental slip. Either way, the LearningManual
has a "real music example" to teach users how to resolve what LilyPond
cannot.)

So I suggest
1) lengthening the stem, selectively, based on duration_log and the
appropriate collision-sense booleans; or
2) treating notes with big flags as if the were dotted, because the
dangling flag creates a conceptually similar situation.

Later I'll post the image of desired output, or better desires if we have
any, on issue 39.

<39.ly><test.preview.png><desire.preview.png>