On Dec 3, 2013, at 4:51 PM, David Kastrup <[email protected]> wrote: > Mike Solomon <[email protected]> writes: > >> On Dec 3, 2013, at 4:19 PM, David Kastrup <[email protected]> wrote: >> >>> David Nalesnik <[email protected]> writes: >>> >>> >>> So I wanted to share the slurs, and then LilyPond surprised me with >>> awful tuplet numbers. >> >> I’m guessing that there are a few things stopping the number from >> lining up nicely, but the most glaring one is line 526 of >> lily/tuplet-bracket.cc, which specifies that tuplet brackets should >> not follow kneed beams. > > I find the version cranked out when setting > TupletBracket.bracket-visibility to ##t quite defensible. > > I don't find it defensible that tuplet brackets interfere with tuplet > number placement when there are no actual tuplet brackets being typeset. >
The logic inside LilyPond is that tuplet numbers should always occupy the same position, irrespective of the presence of a tuplet bracket. When tuplet brackets are not visible, a phantom one is calculated that tuplet numbers are positioned off of. The EP snippet you’ve found is a good example of a case where this rule breaks down. My gut feeling is that tuplet numbers for kneed beams should follow the beam if the bracket is not visible and if there is no collision between a stem and the tuplet number. Perhaps this is generalizable to a bigger class of tuplet numbers, but that’s what comes to mind for now. To get placement of the tuplet number like the EP snippet, one can do \override TupletBracket.direction = #UP. This results in ugly slurs and a collision between the septuplet figure and the B-flat…belch… Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
