staff_radius fixes

staff_radius fixes

1. implementation does not assume staff centred at zero
2. where used for determining whether within staff or not,
 use new function Staff_symbol_referencer::staff_span instead

[benko.pal, 2012-05-05 21:34:15]

this patch makes staff_radius work in cases when line-positions is overridden. 
so long staff_radius assumed overriding at most line-count.

http://codereview.appspot.com/6202048/diff/1/lily/tuplet-bracket.cc
File lily/tuplet-bracket.cc (left):

http://codereview.appspot.com/6202048/diff/1/lily/tuplet-bracket.cc#oldcode687
lily/tuplet-bracket.cc:687: 
removed because regtest showed it not true

[benko.pal, 2012-05-06 17:25:52]

> this patch makes staff_radius work in cases when line-positions is overridden.

> so long staff_radius assumed overriding at most line-count.

sorry, I forgot to mention that
- staff-radius behaved incorrectly also when staff-space is overridden
- there's one slight difference in the regression test
ledger-lines-varying-staves.ly, where line-positions is overridden.

[Graham Percival, 2012-05-07 18:25:35]

looks like this simplifies things, which is always nice to see.

http://codereview.appspot.com/6202048/diff/1/lily/slur-configuration.cc
File lily/slur-configuration.cc (right):

http://codereview.appspot.com/6202048/diff/1/lily/slur-configuration.cc#newco...
lily/slur-configuration.cc:291: size_t n = convex_head_distances.size ();
is .size() the number of staff spaces, or the amount of bytes it takes in
memory, or what?  I'm slightly wondering about changing n from a Real to a
size_t.

[benko.pal, 2012-05-07 20:28:34]

On 2012/05/07 18:25:35, Graham Percival wrote:
> looks like this simplifies things, which is always nice to see.
> 
> http://codereview.appspot.com/6202048/diff/1/lily/slur-configuration.cc
> File lily/slur-configuration.cc (right):
> 
>
http://codereview.appspot.com/6202048/diff/1/lily/slur-configuration.cc#newco...
> lily/slur-configuration.cc:291: size_t n = convex_head_distances.size ();
> is .size() the number of staff spaces, or the amount of bytes it takes in
> memory, or what?  I'm slightly wondering about changing n from a Real to a
> size_t.

convex_head_distances is a std::vector, so size () counts its elements.  I've
changed the type of n exactly because as Real it triggered a warning (now
another warning is triggered by /= n, but the code is more readable this way, I
hope).

A new patch set is uploaded, with all convex_head_distances.size () calls
united.  regression tests are unchanged relative to the original patch set.