On Jul 1, 2011, at 5:02 PM, hanw...@gmail.com wrote: > This patch doesnt make sense to me. The TupletBracket grob is already > linked to the TupletNumber. The correct way to fix this is to make sure > the number lets the bracket decide its position. > >
The problem with this is that, in the axis-group-interface, the TupletNumber either: (1) Does not have an outside staff priority and therefore is included in the staff's skyline, which pushes the bracket too high. (2) Does have an outside staff priority, in which case it may push other grobs too high above it (and it would have to be artificially re-placed in the correct spot with respect to the TupletBracket). > http://codereview.appspot.com/4639075/diff/4001/lily/axis-group-interface.cc > File lily/axis-group-interface.cc (right): > > http://codereview.appspot.com/4639075/diff/4001/lily/axis-group-interface.cc#newcode199 > lily/axis-group-interface.cc:199: bool outside_staff_rider = unsmob_grob > (g->get_object ("outside-staff-carrier")) ? true : false; > what is a 'rider' ? Are you sure we need another property for this? > A grob that rides a carrier grob outside the staff. > http://codereview.appspot.com/4639075/diff/4001/lily/axis-group-interface.cc#newcode262 > lily/axis-group-interface.cc:262: mid_line_heights[j].unite ( > code dup. please fix > I agree that it's a code dup, but it was a code dup before with begin-line-heights and mid-line-heights (which could have been rolled into a drul aray), just a smaller, two line code dup. The present patch just exacerbates the code-dupitude. Perhaps in a separate patch a Drul_array can be created for begin and mid so that a do / while loop can take care of a lot of this function? > http://codereview.appspot.com/4639075/diff/4001/scm/define-grob-properties.scm > File scm/define-grob-properties.scm (right): > > http://codereview.appspot.com/4639075/diff/4001/scm/define-grob-properties.scm#newcode1033 > scm/define-grob-properties.scm:1033: outside the staff.") > how is this different from side-support-elements ? > > the definition is unclear as well- what does it mean to "carry" ? > As I understand it, side support elements go to a side (left right up down) of a grob. The issue with the TupletNumber element is that: (a) It goes on the inside of that which would side support it. (b) The side-position-interface only helps grobs position themselves with respect to a parent. It does not subsume the grob into the other grob's outside-staffitude. The issue here is that we need to eliminate TupletNumber from the skyline calculation of the staff so that it's height does not push up all outside-staff grobs. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
