Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

[address@hidden]

On Nov 7, 2011, at 8:19 PM, Keith OHara wrote:

> Mike,
> Now that we understand that we can adjust 'extra-spacing-height
> for note-spacing, without messing up line-breaking or page-spacing,
> let's revisit the big picture.
> 
> On Fri, 04 Nov 2011 00:12:01 -0700, address@hidden <address@hidden> wrote:
> 
>> On Nov 3, 2011, at 11:39 PM, address@hidden wrote:
>> 
>>> What is the overall plan for the new engravers?
>>> 
>> Currently, LilyPond has no mechanism to calculate the Y-extents of Itemsin a 
>> relative way.  You can't say "make the height of grob X such thatit is 
>> always Y larger than that of grob Z."
> 
> So far, so good.
> 
>> This is necessary for grobs (like barlines) that need to block certain grobs
>> that fall above and below them.   Idem for Staves, idem for time 
>> signatures.Currently, LilyPond accomplishes this through hardcoded values 
>> (check out
>> the extra-spacing-height for TimeSignature, for example), which potentially
>> catches unwanted fuzz (a text script with '(0 . 0) for  extra-spacing-width
>> and low padding will be shifted over numerical time signatures but notcommon 
>> time).
> 
> Well, it depends on /why/ we need the blocking.
> If the goal is to avoid collisions, we use the extents plus extra-spacing-*
> For horizontal spacing based on the meaning of the grobs, we have the 
> 'space-alist.
> Grobs that need prominence relative to their non-colliding neighbors can 
> benefit
> from your pure-from-neighbor-interface.
> 
> Span Bars need space to avoid collisions.
> 
> Separating SpanBars into segments, as you did for issue 910, seems wise 
> because
> in the case of issue 910 they can print as segments.
> 

I'm OK with getting rid of all of this pure-from-neighbor and span-bar-stub 
stuff and just create several SpanBars instead of one SpanBar with gaps in its 
stencil.  I can reuse code I've already written, so it's not that bad.  But, my 
question is: was it ever a good idea to have the pure heights of span bars 
calculated the way they were?  SpanBars are inherently cross staff, so how can 
they estimate a correct Y-extent without triggering a VerticalAlignment?

Cheers,
MS