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/ _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
