Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)

[Mike Solomon]

On Nov 9, 2011, at 11:19 PM, address@hidden wrote:

> On 2011/08/30 16:28:28, mikesol_ufl.edu wrote:
>> On Aug 30, 2011, at 5:53 PM, mailto:address@hidden wrote:
> 
>> > Correct me if I'm wrong, but this is my understanding: wherever
> there's
>> > a SpanBar, you're creating SpanBarStubs between every relevant pair
> of
>> > staves. These don't actually get printed; they're just there for the
>> > pure-height (because the SpanBar height is pretty much the whole
> system,
>> > so it doesn't tell you where the gaps are).
>> >
> 
>> Yes.
> 
>> > If that's correct, I have two broad comments: it's worth commenting
>> > somewhere (span-bar-stub-engraver.cc, maybe) that the purpose of
>> > SpanBarStub is for pure-height only.
> 
>> Will do.
> 
> 
> Haven't done yet.

Done now.

> 
>> > But more importantly, isn't SpanBar
>> > now obsoleted by SpanBarStub? That is, you can just remove the
> SpanBar
>> > altogether and print the SpanBarStubs.
>> >
> 
>> Mmm...you're not unright, but I'd prefer to do that in another patch
> if that's
>> OK.  It'd require a lot of deleting and moving around, and I'd first
> like to
>> make sure that these stubs are the code base and bug free for a while
> before I
>> deprecate an entire grob (and figure out how to deal with the syntax
> changes
>> that come with said deprecation).
> 
> 
> Well, the SpanBarStub extent is not the full length to bridge between
> BarLines, it is only the height of the Lyrics, and only those Lyrics in
> the neighboring measures.

Yup.

> 
> SpanBarStub needs to change size, or get a bar-extent different from its
> Y-extent, before it can take over the job of printing SpanBars.
> 

You're right - I think that was a bad idea, which is why I haven't followed up 
on it.

> I'm worried the code will be quite difficult to understand for quite a
> while unless Mike retreats.
> 

I would rather create a killer flow chart that explains in as much detail as 
possible how all of this works than give up on code that I believe is correct 
given the way that this problem needs to be formulated.  If someone said to me, 
for example, "Mike, music doesn't actually work like that - sharps should be 
allowed to pass over time signatures and clefs (pertaining to the example I 
sent out before), then I'd say "my bad, my research was incorrect, let's revert 
the patch."  As I've said before, after reverting the patch, there are other 
ways to tackle the problem that this patch was originally designed to fix.

Remembering back to the beam collision days (ah, the good old days...), we saw 
several critical issues arise from that, but at no point did people question 
the validity of getting rid of beam collisions.  I think this is because, 
visually, everyone can say "ouch" just by looking at them.  However, as I've 
studied the present issue more, I've realized that collisions between 
accidentals and the airspace above or below non-musical grobs is just as much 
of a 'collision' in traditional typesetting and needs a similar approach.  
Beams collect all of the colliding grobs in an array and then deal with them 
during their positioning callbacks.  BarLines and other non musical grobs also 
need an array of pertinent grobs (in this case, "neighbors") that they can use 
during their callbacks.

Cheers,
MS