Re: Give slurs skylines in outside-staff-priority calculations. (issue 5504055)

[address@hidden]

On Dec 28, 2011, at 4:46 PM, Janek Warchoł wrote:

> It would be great to fix this too!
> You know, one thing comes to my mind: should we really use boxes for
> all sorts of collision calculations?  I think it would give much
> better results it we calculated real distance between objects (i.e.
> between black areas).  We know the outlines of font glyphs, the real
> shape of slur...  Could we implement a global "metric" for measuring
> distances between objects?  My friend Łukasz (Luke) thinks this should
> be the way to go.

This is possible.
To do this in LilyPond, you'd have to:

-) Have skylines admit only lines and curves.  Have all boxes decomposed into 
lines.
-) Create a Line object like the Bezier object and subclass it from a class 
shape with all of the virtual methods you'd want to use.
-) Figure out a way to read font data into Lines and Curves that can then get 
fed to skylines.
-) Write Bezier & Line intersection algorithms (easy) and keep meticulous track 
of exactly how thick these curves are (harder).

I don't have time to do this now, but it is certainly not impossible.  The 
first step would be the porting of font data over to Bezier and Line objects in 
LilyPond.  If you're looking for a welcome back project in the domain of 
collision avoidance, this'd certainly be it!  Note, however, that the gain in 
precision you'd get from this type of calculation may lead to long calculation 
times (LilyPond spends a lot of time already in skylines) so while it's a 
worthwhile experiment, it may lead to deceiving results on the time front.  
That said, it is always possible to switch on and off more costly calculation 
methods (for example, Scripts use skyline calculations with the 
side-position-interface, whereas other grobs just use intervals).

Cheers,
MS