On Nov 10, 2011, at 7:49 PM, m...@apollinemike.com wrote:

> On Nov 10, 2011, at 10:38 AM, k-ohara5...@oco.net 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to