Re: Gets vertical skylines from grob stencils (issue 5626052)

[Keith OHara]

On Fri, 17 Aug 2012 10:16:25 -0700, <address@hidden> wrote:

> http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode780
> lily/axis-group-interface.cc:780: while (dirty);
> On 2012/08/17 08:12:56, Keith wrote:
> > I am beginning to understand the new code. Would you consider again using
> > distance() instead of the repeated calls to intersects() in the while(dirty)
> > loop ?  It might look simpler now that you've been away from the code
> > for awhile.

> > floors[j] = padding - forest[j][UP]~distance~pair[DOWN]
> > ceilings[j] = forest[j][DOWN]~distance~pair[UP]

> > You know the solution will be to move an amount equal to one of the floors[j],
> > and you want to find the smallest that fits, so make
> >    trials = sort (floors)
> > and find the smallest among trials that satisfies
> >     trials[n] > 0
> > &&  for all j (trials[n] > floors[j]
> >                 || trials[n] < ceilings[j] )

> I am not adverse to using distance if possible - my trouble case is the
> following.
>
> AAAAAAAAA
>
>      BBBBBBBBBBBBB
>
> Image that object A above is placed first and LilyPond is now
> considering whether it should leave B where it is or place it above A.
> The distance function would dictate that it needs to be shifted above A
> because its DOWN skyline is below A's UP.

We need not let the distance function between A[UP] and B[DOWN] dictate, 
because having positive distance between A[DOWN] and B[UP] is another solution.

Object AA, a member of the forest, sets two constraints
       floor = padding  -  AA[UP] ~distance~ BB[DOWN]
       ceiling = AA[DOWN] ~distance~ BB[UP]  - padding
and we are checking that a trial location satisfies
       (trial >= floor) OR (trial <= ceiling)

I suppose you show BB having been placed just above the staff, and that it 
still lies below the ceiling set by AA, so this trial position satisfies the 
first test in the OR above, so we win.

All these distances can be computed once, before raising the skylines at all, 
because they tell you right away what trial values of raising BB will clear AA. 
 That would be much simpler for people like me to understand than computing the 
four intersects() conditions, after having moved the skylines by zero or more 
bump(s).


On the question of where to store padding, simple padding was previously added 
by the code using distance().  That seems best because it is a simple addition 
and different applications might have different padding to the same objects.  
Then you don't have to worry about adding padding multiple times to a skyline, 
deciding which of two skylines to pad, etc.

The other thing is 'horizon-padding' which fattens the buildings in the skyline 
themselves, and has in the past been implemented by reshaping the Skyline 
object.  The user-variables skyline-(vertical|horizontal)-padding apply so far 
to symmetric situations, and the code simply horizon-pads both skylines so you 
get the effect of twice the number you enter.