On Nov 9, 2011, at 11:19 PM, k-ohara5...@oco.net wrote: > On 2011/08/30 16:28:28, mikesol_ufl.edu wrote: >> On Aug 30, 2011, at 5:53 PM, mailto:joenee...@gmail.com 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
