[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improves horizontal spacing of axis groups that SpanBar grobs traver
Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)
Thu, 10 Nov 2011 06:58:11 -0800
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
>> > a SpanBar, you're creating SpanBarStubs between every relevant pair
>> > staves. These don't actually get printed; they're just there for the
>> > pure-height (because the SpanBar height is pretty much the whole
>> > so it doesn't tell you where the gaps are).
>> > 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.
>> > But more importantly, isn't SpanBar
>> > now obsoleted by SpanBarStub? That is, you can just remove the
>> > 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
>> 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.
> 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
> 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.