On Wed, Jul 13, 2011 at 11:27 AM, m...@apollinemike.com <m...@apollinemike.com> wrote:
>> Wouldnt it be much easier for the tuplet number's extents to be >> ignored for skyline purposes if there already is an associated tuplet >> bracket? >> > > That's what the new line 250 of axis-group-interface.cc in the patch does: it > makes sure that the rider grob is not counted in the skyline (I think). > The tuplet number sticks out of the tuplet bracket, so it makes sense for its > extent to be combined with that of its carrier (lines 244 and 255 of > axis-group-interface.cc in the patch). > >> Practically speaking, the tupletnumber adapts its position to the >> bracket, so it is best for the implementation to also do this. >> > > The idea of the rider grob in this implementation is a generic concept that > would allow for certain grobs (i.e. TupletNumbers) to ride their carriers > (i.e. TupletBrackets) outside of the staff and then subsequently be counted > as part of their carrier's extent instead of as part of the staff extent (or > as another outside-staff grob). Can you think of a way to make the impact of this to axis-group code minimal? I think the only thing needed is that the axis-group doesnt know about the tuplet number. You could either not add it to the axis-group in the first place, or alternatively, you could remove the number from the 'elements list in axis group once you know it is irrelevant. The number should be parented by the bracket so you get the translations for free. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
