Re: Fixes issue 1628. (issue 4876051)

[Mike Solomon]

On Aug 16, 2011, at 1:06 PM, Han-Wen Nienhuys wrote:

> Your patch is doing much more than address issue 1628.  Can you do
> just the change to the engraver to close issue 1628?   Any ensuing
> collisions should be made into a new issue.
> 

OK.  The reason that I added all that extra stuff was for a 
string-number-arond-slur regtest with slurs that explicitly has "outside" and 
"inside" written in certain places.  These get changed with my patch.  I 
assumed that this was important, so I implemented the behavior necessary for 
the regtest not to change.  My patch, then, will introduce a regression from 
this test (or, alternatively, I could just change the outside/inside labels to 
the new results, but again, I'm not sure how important they are).

> Are you sure exclude_extra_objects_outside_x_range() is really needed?
> We already have
> 
>          Real x = info.extents_[X_AXIS].linear_combination (info.idx_);
> 
>          if (!slur_wid.contains (x))
>            continue;
> 

Didn't see this, so no, it's not needed.

> I don't think we can realistically mess with the offsets of
> extra-encompass objects in the slur scoring (or, in general: change
> dependency order during formatting): other objects may already have
> used the object's position (which you are trying to invalidate) to
> make other decisions.  Eg. what if a skyline algorithm has already
> read the position of the grob?
> 
> If you want to have more adaptive behavior, you need to have a
> super-grob which coordinates between slur and encompass objects, like
> we have for note and rest-collisions.
> 

This is not a bad idea.  As my summer of lily comes to a close in a couple 
weeks, I may try to get this up and running.

Cheers,
MS