spacing-spanner: rods for non-adjacent paper-columns; issue 1700

spacing-spanner: rods for non-adjacent paper-columns; issue 1700

[Keith, 2012-09-11 05:09:31]

http://codereview.appspot.com/6489107/diff/1/lily/spacing-spanner.cc
File lily/spacing-spanner.cc (right):

http://codereview.appspot.com/6489107/diff/1/lily/spacing-spanner.cc#newcode268
lily/spacing-spanner.cc:268: for (LEFT_and_RIGHT (d))
Here, LEFT denotes the non-broken Item, while RIGHT denotes its broken form when
at the right-end of a line.  The broken form when at the left-end of a line is
handled separately.  I plan to unroll this loop, to avoid all the (d == LEFT)
tests

[Keith, 2012-09-16 07:26:39]

Patch set 2 is preliminary re-organization
Patch set 3 is the functional change

[Keith, 2012-09-18 02:37:34]

http://codereview.appspot.com/6489107/diff/9001/lily/spacing-spanner.cc
File lily/spacing-spanner.cc (left):

http://codereview.appspot.com/6489107/diff/9001/lily/spacing-spanner.cc#oldco...
lily/spacing-spanner.cc:274: doesn't touch the right column. */
This comment tells me what the code did, but not why.
When setting spacing constraints for a column on the right, it was checking
columns to the left until they were too far to matter, then checking the
line-broken version of one column farther back to the left.

This could matter for cases where the broken version (likely a clef and key
signature) interleaves more with intervening note-columns that the unbroken
version (likely a barline).  The simplest example I can think of is

\paper{ragged-right = ##t }
music = {
  \grace { \stemDown <b,-1-2-3>8[ c d] }
  <e'-1-2-3-4-5>4 r2.}
\new PianoStaff \with {
  fingeringOrientations = #'(left)
} <<
  \new Staff{\clef alto R1 \music \break \music}
  \new Staff{\clef alto R1 R1*2 }
>>

Maybe more relevant cases come up in medieval music?

[MikeSol, 2012-09-22 08:34:57]

LGTM - looking forward to the skyline version, as that'll more accurately
reflect where columns are overhanging.

[Keith, 2012-09-22 17:15:14]

On Sat, 22 Sep 2012 01:34:57 -0700, <mtsolo@gmail.com> wrote:

> LGTM - looking forward to the skyline version, as that'll more
> accurately reflect where columns are overhanging.
>

Well, long term I would like to use extent() to determine which columns have
overlapping extents, but need to find and fix unrelated bug first.

Unfortunately, extent() does not report the truth when fingering goes around
accidentals.  So here we need to continue figuring the extents from the
skylines.

> http://codereview.appspot.com/6489107/

[Keith, 2012-09-26 02:56:24]

http://codereview.appspot.com/6489107/diff/13001/lily/spacing-spanner.cc
File lily/spacing-spanner.cc (right):

http://codereview.appspot.com/6489107/diff/13001/lily/spacing-spanner.cc#newc...
lily/spacing-spanner.cc:246: sticks out a lot to the left */
/* TODO: The max_height() of the skyline should be the same as simply the
extent() of the column, but extent() is missing the width of scripts stacked
horizontally left of accidentals */

[janek, 2012-09-26 05:55:57]

lgtm, i think.