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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
