Re: Uses single algorithm for side-position spacing. (issue 6827072)

[k-ohara5a5a]

On 2012/12/17 10:44:23, mike7 wrote:

> Fixed in the most recent patch-set. It is because
> Axis_group_interface::generic_bound_extent did not recurse into the
elements
> list of cross-staff grobs implementing axis-group-interface.


I haven't tried this yet, but I notice a lot of other places where a
grouping-object is marked 'cross-staff' where we might also need to look
at the 'elements' to see which individual graphical-objects are
'cross-staff'

I guess it is logical to flag the grouping-object as 'cross-staff' if it
contains a cross-staff element, but previously 'cross-staff' meant more
like "I will be spanning across one or more staves, so please completely
ignore me for vertical spacing purposes"


https://codereview.appspot.com/6827072/diff/34001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

https://codereview.appspot.com/6827072/diff/34001/lily/axis-group-interface.cc#newcode62
lily/axis-group-interface.cc:62: return SCM_BOOL_T;
Now the whole note-column is marked cross-staff if its stem spans
staves.  Check if Note_column::cross_staff_extent() still makes sense

https://codereview.appspot.com/6827072/diff/34001/lily/axis-group-interface.cc#newcode258
lily/axis-group-interface.cc:258: continue;
This might now ignore protruding note-heads under a cross-staff beam
when estimating system heights for page breaking.

https://codereview.appspot.com/6827072/diff/34001/lily/axis-group-interface.cc#newcode845
lily/axis-group-interface.cc:845: // really depend on position of the
cross-staff grobs that lie between them.
An old comment, but is it backwards?
Obviously, the position of a cross-staff beam depends on the distance
between the staves that it spans, not the other way around.

https://codereview.appspot.com/6827072/