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

[Keith OHara]

On Sun, 18 Nov 2012 08:10:49 -0800, address@hidden <address@hidden> wrote:

> On 18 nov. 2012, at 00:55, address@hidden wrote:
>
> > http://codereview.appspot.com/6827072/diff/11002/lily/box-quarantine.cc#newcode70
> > lily/box-quarantine.cc:70: return fabs (ii0.index_ - mid) < fabs
> > (ii1.index_ - mid);
>
> This is a bit over my head - do you recommend I just remove the sorting?  If I 
> do this, then I think the fingerings will fan up or down instead of fanning out 
> from their middle?

The calls you make to translate() shift boxes in pairs by equal amounts in 
opposite directions, so the groups fan from their centers with any order of 
opening the vanes in the fan.
(Strangely, though, all the fingerings involved in any collision shift up a 
half space.)

> > http://codereview.appspot.com/6827072/diff/11002/lily/box-quarantine.cc#newcode86
> > lily/box-quarantine.cc:86: scratch.intersect (boxes_to_quarantine_[i +
> > 1]);
> > If you look only at adjacent boxes, and work from middle out, then with
> > boxes   A B C D E F G   you might push box B clear beyond A before even
> > looking for an A-B collision.
> >
> > Maybe you intended to widen by padding_, otherwise the resulting boxes
> > do not get moved if they are closer to each other than padding_.
>
> I'll have to look at this more closely...basically, I want an algorithm that 
> looks at how things are grouped and moves them around along one axis so that 
> there are no more collisions while maintaining the general grouping.

Simple stacking of the boxes from the middle out (one pass) would probably be 
good enough.  The Dot_Collision solves a similar problem, though it is more 
complex than you need here.  There is also the rods-and-springs code that is 
used in several places: successive Fingerings would be linked by springs with 
natural length equal to the spacing between their parent note-heads, and rods 
long enough to clear collisions.

The patch as it is shows some unevenness in 'fingering-column.ly', and would be 
challenging to understand by anyone who wants to fix that.

> > http://codereview.appspot.com/6827072/diff/11002/lily/script-engraver.cc#newcode270
> > lily/script-engraver.cc:270: // we never want Script grobs to be tucked
> > down next to stems
> > The patch changes  'chord-scripts.ly'  in a way inconsistent with this
> > comment at the moment.
>
> I'm still wondering the best way to implement this is.  For me, the cleanest 
> thing to do is to either use or not use the NoteColumn as a support (see my 
> previous response to you on this subject).  When used, there's no tucking, and 
> when not used, there is.

In your patch, though, NoteColumn is used as 'support' for Scripts, yet the 
accents in 'chord-scripts.ly' do tuck down alongside the stems.  Something is 
not working as intended.


> > What is the meaning of marking the entire NoteColumn as "cross-staff" ?
> > It seems you already iterated through the elements of a NoteColumn,
> > including NoteHeads in skylines but excluding any cross-staff stems.
>
> Try running beam-cross-staff-script.ly with my patch and setting 
> NoteColumn.cross-staff to ##f.  You'll see that it triggers beam slope 
> calculations before vertical spacing is done on the staves because NoteColumn, 
> which is a support for the script, has its height checked prematurely.  This 
> does not happen in current master because NoteColumn is not a support for 
> Scripts.
>
> So why did I make NoteColumn a support for Scripts?  I use the NoteColumn as a 
> side support object because it combines the width of the note head with the 
> height of the stem.  We don't want UP staccatos, for example, getting tucked 
> down to the left of UP stems but they will if skylines are used.  So, we use 
> the NoteColumn as the side support.

I suppose that, strictly speaking, NoteColumn can be 'cross-staff=#t, meaning 
"beware; I might move or change shape when staves are spread across the page."  
But, it seems to preserve more information if we can leave the 'cross-staff indication 
specifically on the Stem.

Scripts clearing Stems is already a special case, controlled by 'add-stem-support, which has in the 
past meant "keep this Script clear of the end of the Stem and Flag of its parent, even if it 
could slide alongside."  Maybe 'add-stem-support could be implemented as "Consider the 
Script widened enough to include a point on the extended line of the Stem, and keep the widened 
Script clear of the Stem."