"[email protected]" <[email protected]> writes: > On Oct 21, 2011, at 6:15 PM, David Kastrup wrote: > >> >> commit 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf >> Author: Mike Solomon <[email protected]> >> Date: Fri Oct 21 09:03:43 2011 +0200 >> >> Implements consistent beam slopes across line breaks. >> >> says >> >> To turn on this feature, use \override Beam #'consistent-slope = ##t. >> >> I think that is a mistake: unbroken beams naturally have consistent >> slope. So when breaking a beam across lines, Lilypond already gets to >> play with stem lengths to make the broken output strictly better than >> the unbroken output was. >> >> The best output might conceivingly be achieved by very slightly relaxing >> slope consistency. As long as we have no button for that, not relaxing >> it is a much saner visual choice than totally discarding it. >> >> I would not even offer a settable property for this as long as the only >> options are on and off. >> > > > Compile beam-feather-breaking.ly in input/regression with and without > this property - I think that the visual output changes enough to merit > the on/off existing in LilyPond, no?
Apart from breaking the documentation, this patch does not really reach the finishing line. First, the property actually is called consistent-broken-slope. Second, it is quite obvious from the output that it does _not_ merely keep the slope consistent, but additionally the vertical position. Of course, this _does_ change the quality of the output. The vertical positions of the broken beams should be kept together with a light spring at most. If the vertical positions are tied together rigidly, the user gets the choice between two suboptimal extremes: detrimental overconsistency, or total non-consistency. Picking the detrimental overconsistency only makes sense if by chance the beam slopes would be similar anyway. Which is the case in beam-feather-breaking.ly. But it should not be the task of the user to determine this and flip a switch accordingly. -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
