On Jul 13, 2011, at 4:42 PM, Han-Wen Nienhuys wrote: > 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. >
Most of the current patch does the minimal amount of work to get the result. Note that this does not mean that this is the ideal way to do it - it is just the only way I know how given my understanding of the code. Added line 199: identifies if a grob should be ignored (is it an outside-staff-rider?) Added line 240-250 and 255-264: Admittedly code-dupious, so these really do the same thing. I am trying to follow the patches-as-tiny-and-self-contained-as-possible policy as strictly as possible, especially as I am a cardinal offender in other patches under review. These lines do two things: (1) Add the extent of the tuplet number to the tuplet bracket (which I do here instead of in the Y-extent override because it seems that it should be temporary); and (2) ignores all rider grobs that have already been added into their carriers' extent. Added lines 653-655, 674-675: Move the rider relative to its carrier. This is the spot where I may be able to get some of the code outside of axis-group-interface.cc (thus the "most" in my first sentence). It seems that the best place may be side-position-interface.cc, but the issue in this file is that, as I see it, things can be positioned with respect to their parents on the left/right/above/below but not in the middle of a grob's control points, which is currently where the tuplet number is placed. Do you think it'd be a good idea to modify side-position-interface to do this? Alternatively, another way to get at this may be in the axis-group-interface to change the value of a grob's "control-points" property if it has one such that these points are shifted by the same amount as the grob. Does this seem like a good idea? As always, I'll do whatever is most lily-pond-esque. Lemme know if you see in my explanation anything that seems frivolous/too much, and thanks for all of your feedback! Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
