Re: Fixes issue 39 by raising stems (issue3934041)

[Carl Sorensen]

On 1/11/11 5:31 PM, "address@hidden" <address@hidden> wrote:

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

No, you're being the thorough cop to Carl's much less-thorough cop.

If it passes regtests, I consider it fine.

If it breaks other things that aren't in regtests, you catch it.  I think
your work is invaluable.

When fixing bugs, we likely ought to have the rule of "first do no harm".
If we make common automatic engraving worse in order to fix uncommon
problems, we're going backwards.

Please keep up your careful checking!

> 
> 
> 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#newcode
> 177
> 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.

I have not followed the code carefully enough to understand the difference.
What is the difference between "extra-raise-tip" and "extra-stem-length" in
terms of how it acts?

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

This seems reasonable to me.

Thanks,

Carl