[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fixes issue 1628. (issue 4876051)
From: |
Mike Solomon |
Subject: |
Re: Fixes issue 1628. (issue 4876051) |
Date: |
Tue, 16 Aug 2011 13:12:42 +0200 |
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