Re: Fixes issue 39 by raising stems (issue3934041)

[k-ohara5a5a]

I seem to be playing bad-cop to Carl's good cop.  Maybe I'm being picky
because the original issue didn't bother me very much, so I don't like
side effects to the fix.  I'll say what I don't like, test at my own
suggestions at my slow pace, and let Carl overrule if appropriate.


http://codereview.appspot.com/3934041/diff/2001/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/3934041/diff/2001/lily/note-collision.cc#newcode177
lily/note-collision.cc:177: if (touch)
On 2011/01/09 09:52:42, Keith wrote:
> why not apply the stem lengthening here?

Oops, then we lengthen in more common cases, <<g32\\g32>> and
merge-differently-headed, which looked better the old way.

I think the ideal target set is (touch && !merge_possible) but I will be
slow to test (have an evening meeting).

http://codereview.appspot.com/3934041/diff/11001/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/3934041/diff/11001/lily/stem.cc#newcode322
lily/stem.cc:322: Real extra_raise_tip = scm_to_double (me->get_property
("extra-raise-tip"));
On 2011/01/11 17:20:27, Carl wrote:
> But I think that extra-stem-length is a better description

It is a better description of what we want, yes, but then it should act
that way.

The note-collisions determine a minimum-stem-length that probably should
apply 12 lines up, near the length adjustment for the stem's own
noteheads.
length := min (me->"length", minimum-stem-length)

Then stems that are lengthened anyway to reach the staff centerline
<<c32\\c2>> should be left alone, as well as those lengthened due to
with chords in the flagged stem << <g f' g'>64\\g2 >>.

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