LGTM Removing the contribution from 'height-limit' to estimated slur heights is very helpful. It was never appropriate to add 'height-limit' to the extent of the slurred notes, because the note or stem furthest in the direction of the slur is much closer to the curve of the slur than 'height-limit'. Piano music often has to increase height-limit, and the formerly ridiculous height estimates made the page-breaker useless for me.
Estimating the slur extent as an offset from the notes in the direction of the slur, rather than a widening of the notes extent on both sides, should also help a bit. The stuff with slur slopes is fümms bö wö tää zää uu, but seems harmless. http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc File lily/slur.cc (right): http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode101 lily/slur.cc:101: ret[downup] = minmax (downup, d[dir], ret[downup]); any different from ret.add_point(d[dir]) http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode113 lily/slur.cc:113: // we dampen the height approximation by the slur's likely slope 'height_approximation' now stores free_head_distance_, which is applied vertically so its effect doesn't depend on slope of the slur. Its value is very small by default, and is only a request to the slur scoring routine, so why bother with it? http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode114 lily/slur.cc:114: // steeper slopes get smaller factors Without a count of the note-columns spanned, this is more of a height than a slope. And larger slopes/heights get larger 'factor's, smaller '(1 - factor)'s http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode116 lily/slur.cc:116: ret[dir] += height_approximation * (1 - factor); dir * http://codereview.appspot.com/5431065/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
