[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: Fri, 04 Nov 2011 01:52:33 -0700
User-agent: Opera Mail/11.52 (Win32)

On Fri, 04 Nov 2011 00:12:01 -0700, address@hidden <address@hidden> wrote:
On Nov 3, 2011, at 11:39 PM, address@hidden wrote:
What is the overall plan for the new engravers?

Currently, LilyPond has no mechanism to calculate the Y-extents of Items in a relative 
way.  You can't say "make the height of grob X such that it is always Y larger than 
that of grob Z."  This is necessary for grobs (like barlines) that need to block 
certain grobs that fall above and below them.  [The same] for Staves, [the same] for time 
signatures.  Currently, LilyPond accomplishes this through hardcoded values (checkout the 
extra-spacing-height for TimeSignature, for example), which potentially catches unwanted 
fuzz (a text script with '(0 . 0) for extra-spacing-width and low padding will be shifted 
over numerical time signatures but not common time).

Generally, though, there is a desired spacing from the Time Signature to the 
main note column, and we usually do not want decorations like accidentals or 
text scripts to influence that spacing, unless necessary to avoid (near) 

Issue 647 prompted the extra-spacing-height you mentioned, but that was for a 
(near) collision.  Personally, I think the comment added to 
'' was an overreaction.  If the note with lots of 
decorations is well clear, I would rather have the decorations folded over the 
Clef or whatever.

In general, I'd like to see the Pure_from_neighbor_engraver take care of the 
extra spacing heights for all grobs that are ordered by break alignments, as 
all of them should prevent overhang.

Now, earlier you implied that change clefs were getting "too much space" in 
places where we blocked ledgers from overhanging:

2)      The elimination of skyline-vertical-padding corrects a horizontal
spacing issue where the cue-clef takes up too much space in and

I'm assuming you changed your mind.

I agree it would be nice to change this, but did you really see the
problem in real music?

I see the problem in my music (which I consider real music!).

Wow.  Are you a minimalist?

What is a 'pure' when used as a noun?

Grobs that are pure relevant.  I'll use "pure_relevants_" instead.

Purely relevant to what?  How can something be impurely relevant?

I know that you mean grobs that are relevant to the computation of an 
extra-spacing-height, for use in the note-spacing step, which comes before 
line-breaking, at which time we sometimes use approximate heights, which tend 
to be computed by functions that are (inaccurately) called 'pure'.
But, try to think of a less-jargony variable name, for the sake of this guy: 

reply via email to

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