Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

[k-ohara5a5a]

On 2012/09/07 16:23:21, mike7 wrote:
> On 7 sept. 2012, at 09:34, mailto:address@hidden wrote:

> > Do you still think it possible to use just the real Slurs ?...
> >
> > 1) setting tentative control points using pre-line-breaking
> > estimates of heights (which are later replaced when the Slurs
> > go through their post-line-breaking shaping-and-scoring cycle).

> This doesn't work because all of this skyline stuff happens
> pre-line breaking but post-vertical spacing.

Did you mean "after line-breaking but before vertical-spacing"?

>   And furthermore, there needs to be a SlurStub for
> each axis group traversed.

I didn't know that.  I thought one skyline per Slur would suffice, since
it is applied for spacing the Systems.

> > 2) Determining their extremal-side-only skylines, either through
> > callbacks on a property other than the real "vertical-skylines", > >
or not as a callback at all but through a direct function call.

> Even if this were done, it couldn't be applied to the Slur proper.
> For example, if you have slur S that cross staves X Y and Z from
> bottom to top, the SlurStub on X would only have a bottom skyline,
> the SlurStub on Y would have no skyline and the slur stub on Z
> would have an upper skyline.  If the Slur had these two skylines
> via some sort of pre-skyline callback, LilyPond would think that
> the VerticalAxisGroup were the height of the Slur and would space
> it way far apart from its upper or lower neighbor.  That's why
> separate stubs need to be in each axis group.

Then we don't store the extremal-side-only skylines as a property of the
Slur.  We merely use the data in the Slur to compute extremal-side-only
skylines, and merge them with the System skylines for system-system
spacing.

But, that does seem more trouble than it is worth, given that the
estimated slur shapes are only accurate enough to resolve about 50% of
the collisions.



http://codereview.appspot.com/6498077/diff/29/input/regression/cross-staff-slur-vertical-spacing.ly
File input/regression/cross-staff-slur-vertical-spacing.ly (right):

http://codereview.appspot.com/6498077/diff/29/input/regression/cross-staff-slur-vertical-spacing.ly#newcode61
input/regression/cross-staff-slur-vertical-spacing.ly:61: <g'' c''>8 )
 <g'' c''>8 )(

http://codereview.appspot.com/6498077/diff/29/input/regression/cross-staff-slur-vertical-spacing.ly#newcode63
input/regression/cross-staff-slur-vertical-spacing.ly:63: e8 dis e
 e8 dis e)

http://codereview.appspot.com/6498077/diff/29/input/regression/cross-staff-slur-vertical-spacing.ly#newcode70
input/regression/cross-staff-slur-vertical-spacing.ly:70: a8 a8 a8 a8 a8
a8 a8_\markup \column { "f" "o" "o" } a8 a8 a8

Stubs for down-sloped slurs are not helping.

http://codereview.appspot.com/6498077/diff/29/lily/script-column.cc
File lily/script-column.cc (right):

http://codereview.appspot.com/6498077/diff/29/lily/script-column.cc#newcode58
lily/script-column.cc:58: /*
This seems entirely unrelated to spacing of systems.  It looks like a
sensible fix to issue 2589, but it causes a collision in the Chopin
Op.45 measure 85, for reasons I cannot quite figure out.  One fix for
that score is
\once\override Script #'avoid-slur = #'inside

I'd rather have a message in debug builds than a collision in user
scores. (Maybe that message should be a warning rather than 'programming
error', since LilyPond allows users to make inconsistent spacing
requests like I did with Fingering inside and Accents avoiding slurs,
yet fingering outside the accent when they occur together.)

http://codereview.appspot.com/6498077/