[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Keith OHara
Subject: Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
Date: Mon, 07 Nov 2011 10:46:36 -0800
User-agent: Opera Mail/11.52 (Win32)

On Sun, 06 Nov 2011 23:34:37 -0800, <address@hidden> wrote:
lily/ && (grace == LEFT ? has_grace :
On 2011/11/07 01:25:30, Keith wrote:
In fact, why even use a loop over grace-ness if the actions within the
occur only for one of two passes through ?

I'm not sure what you mean...the actions apply for both passes.

Well, the condition we are commenting on is inside an if() that protects the 
only action in the loop over grace.
The loop takes action for just the one value of 'grace = (has_grace? LEFT : 
The other statements inside the loop over 'grace' look to be loop-invariants.

I realize that do{}while(flip()!=LEFT) is a LilyPond idiom, but in this case it 
seems more clear to update array element that needs it, without looping over 
the other case.

This is saying "if the closest column is a grace-note-column, include
the next-closest column as well."  This gets rid of any accidental
overlap problems at the expense of potentially adding a little extra
vertical space to the page-spacer calculations, but this extra space
seems to be so minimal as to not be a problem (not unlike pure heights
for beamed stems, which could also slightly overshoot their actual

I had not realized that the results of the pure-from-neighbor system influence 
the page-spacing.  This is inconvenient.  Now I have some idea why there is so 
much effort to increase the height only as much as needed.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]