Re: Allows for rider grobs in outside-staff-priority. (issue4639075)

[address@hidden]

On Jul 1, 2011, at 5:02 PM, address@hidden 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