On Monday 13 November 2006 21:11, Joe Neeman wrote:
> Here's a patch for introducing skyline vertical spacing. The bulk of the
> changes are to rewrite skyline so that
> 1) merging is linear (in the sum of the lengths of the skylines) time
> 2) building a skyline from boxes is O(n lg(n)) time
> 3) we support sloped-roof skylines. This isn't used yet, but I think it can
> be used for skylines where more accuracy is needed (for example in
> horizontal spacing). In any case, it only adds a constant factor to the
> complexity.
This sounds very cool.
Just a question: I have been thinking about skyline spacing in music for a
while (trying to figure out cases where skyline spacing can give bad
results), and I have one idea: In some cases, objects could come too close
together with skyline spacing. E.g., if a stem sticks up from one staff, and
a horizontally nearby stem sticks down from the staff above, the stems could
end up too close to each other, like:
======
==o===
|
|||
|||
| |
=o=o==
=====
I have an idea on how to work around this problem: We could define a maximum
slope for 'sloped-roof' skylines; i.e., for vertical spacing, we allow
horizontal lines but not vertical lines, instead the slope of a skyline can
maximally be (say) 60 degrees. So the skyline of the upper staff becomes
something like (sorry for the lousy ascii art):
===============
__===o===____
\ | /
\ | /
\|/
With the right choice of maximum slope, this would hopefully increase the
distance sufficiently to prevent too tight spacing.
I know nothing about the theories of skylines, and I haven't looked at your
code yet, so maybe there is a better solution to the problem already; my
apologies in that case. If not, does this sound sensible to you?
--
Erik
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
