Re: Uses the pure-from-neighbor-interface for NonMusicalPaperColumn horizontal spacing. (issue 5432070)

[Keith OHara]

On Sat, 26 Nov 2011 14:48:29 -0800, address@hidden <address@hidden> wrote:

> On Nov 26, 2011, at 9:56 PM, Keith OHara wrote:
>
> > Mike, Maybe change-clefs should not get the full extra-spacing-height by 
> > default.
>
> I could do this if I could call Item::break_visible before line breaking (which 
> would let me know which clefs are change clefs as opposed to 
> beginning-of-line-clefs).  However, I remember Neil saying that this was a bad 
> idea, although I don't remember why.  Any ideas why this call isn't Kosher?

Oops. I was thinking the smaller change clef was a different "grob", but it is 
not.

'break_visible' calls break_status_dir() to look up whether an item is visible 
based on the results of line-breaking, so you don't want that.  Now I see that 
the clef:calc_glyph_name() does the same.

I think all the Clefs that exist before line-breaking should be change clefs, 
with the begin-of-line clefs added afterwards. Probably best if no Clefs use 
the pure-from-neighbor height, certainly not CueClefs.

The distinction between beginning-of-line and middle-of-line spacing is made 
with 'space-alist'.  Most of the spacing based on the meaning, rather than 
extent, of symbols is done with that system.
Actually, your "don't-hang-over-me" rule would fit there nicely as a new type in a 'space-alist' to go 
alongside "minimum-space", "semi-fixed-space" etc.   It could be "no-overlap-space" and 
use the extent of the Item and the next-note column rather than their skylines.

> Perhaps a stupid question, but why does LilyPond even take ledger lines into 
> account if they have no vertical or horizontal extent?  How do they factor into 
> the spacing calculations?

Neighboring note-columns are allowed to tuck under ledger lines, but not within 
the ledger lines.   {e'''8 cis'' e''' fis'' }
The NoteHead has extra-spacing-height to enforce this rule.