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

[address@hidden]

On Nov 10, 2011, at 7:49 PM, address@hidden wrote:

On Nov 10, 2011, at 10:38 AM, address@hidden wrote:

If SpanBars have space reserved where and only where they print, issue
910 would be solved.

If BarLines and KeySignatures later receive extra-spacing-height to
prevent accidentals from hanging over, issue 1955 would be solved.

Separation has the advantage that, should there be an exception to the
rules exemplified by either of these issues, a user can override one
rule and keep the other.

I'll do my best to separate these out - as I said above, I don't want to do it if it is going to compromise the universality of the solution and/or if it'll require reverting one solution to implement a later one.  But, I'll mull over it and see if I can cook something up on my 11 hour plane ride today (uggggghhhhhhhhhhhhh).

I posted an uber-patch online that can be separated out into several patches.  This uses a new extra-spacing-height for barline to allow span bars to block offending grobs while not applying this to barlines that either don't have span bars or have allow-span-bar set to ##f.

I think that this does everything that needs to be done to fix regressions in addition to adding new functionality that makes sure that accidentals don't shift over/under time signatures, clefs, and key signatures.

After ironing all the kinks out (assuming that there are still kinks to iron out), my plan would be to do the following:

1) Push a patch that fixes the span bar problem.

2) Push a patch that adds extra spacing height to clefs, key signatures, and time signatures to block accidentals from trailing over them.

3) Push a patch that makes the default for LilyPond to block accidentals trailing over barlines.

2 and 3 are still up for debate, but as I've said several times in this thread, there is nothing that i've found in the literature to suggest that music does not work this way.

Cheers,

MS