Implement extra-offset for system positioning

Implement extra-offset for system positioning

Add the property 'extra-offset to 'line-break-system-details.

It is possible to position systems absolutely using the properties
'X-offset and 'Y-offset of 'line-break-system-details.  Placement,
however, is relative to the top left of the usable space, and can
be difficult to gauge without considerable trial and error.

An 'extra-offset property allows easy movement of systems relative
to where they currently are on the page--either through their
default positioning, or as a result of absolute positioning through
'X-offset and/or 'Y-offset.

System separators will be properly positioned. (Thanks go to Thomas
Morley.)

[david.nalesnik, 2017-04-27 22:48:46]

Please review.  Thanks!

[thomasmorley651, 2017-04-28 09:26:34]

Some nits, otherwise LGTM
Worth an entry in changes?

https://codereview.appspot.com/324810043/diff/1/input/regression/page-layout-...
File input/regression/page-layout-extra-offset.ly (right):

https://codereview.appspot.com/324810043/diff/1/input/regression/page-layout-...
input/regression/page-layout-extra-offset.ly:7: printable area of the page or
the absolute position pecified by
typo
pecified->specified

https://codereview.appspot.com/324810043/diff/1/scm/page.scm
File scm/page.scm (right):

https://codereview.appspot.com/324810043/diff/1/scm/page.scm#newcode246
scm/page.scm:246: (extra-offset (ly:prob-property system 'extra-offset (cons 0
0)))
Why not directly '(0 . 0) instead of constructing it?
Admittedly, starting with guile-2.2 set-car! (and similiar) will error on
literals, though this is not the case here.

[david.nalesnik, 2017-04-28 15:16:54]

Changes based on Harm's review

[david.nalesnik, 2017-04-28 15:20:28]

Also added a "Changes" entry.

Thanks!

https://codereview.appspot.com/324810043/diff/1/input/regression/page-layout-...
File input/regression/page-layout-extra-offset.ly (right):

https://codereview.appspot.com/324810043/diff/1/input/regression/page-layout-...
input/regression/page-layout-extra-offset.ly:7: printable area of the page or
the absolute position pecified by
On 2017/04/28 09:26:33, thomasmorley651 wrote:
> typo
> pecified->specified

Done.

https://codereview.appspot.com/324810043/diff/1/scm/page.scm
File scm/page.scm (right):

https://codereview.appspot.com/324810043/diff/1/scm/page.scm#newcode246
scm/page.scm:246: (extra-offset (ly:prob-property system 'extra-offset (cons 0
0)))
On 2017/04/28 09:26:33, thomasmorley651 wrote:
> Why not directly '(0 . 0) instead of constructing it?
> Admittedly, starting with guile-2.2 set-car! (and similiar) will error on
> literals, though this is not the case here.

Done.

[dak, 2017-04-28 15:50:52]

Does an extra-offset in X direction even make sense when the systems are spaced
according to their skylines _before_ the extra-offset is applied?

[david.nalesnik, 2017-04-28 16:15:42]

On 2017/04/28 15:50:52, dak wrote:
> Does an extra-offset in X direction even make sense when the systems are
spaced
> according to their skylines _before_ the extra-offset is applied?

Well, X-offset of line-break-system-details is applied in make-page-stencil,
too.

[david.nalesnik, 2017-04-28 22:24:57]

On 2017/04/28 16:15:42, david.nalesnik wrote:
> On 2017/04/28 15:50:52, dak wrote:
> > Does an extra-offset in X direction even make sense when the systems are
> spaced
> > according to their skylines _before_ the extra-offset is applied?
> 
> Well, X-offset of line-break-system-details is applied in make-page-stencil,
> too.

In any case, having an extra-offset in the Y direction is obviously much more
useful.  Extra-offset in the X direction seems a bit superfluous, since it's
easy enough to set 'X-offset based on the left edge of the printing space.  My
original code created an extra-Y-offset, and I'm happy to go back to this.

Opinions?

[david.nalesnik, 2017-04-28 22:27:12]

On 2017/04/28 22:24:57, david.nalesnik wrote:
> On 2017/04/28 16:15:42, david.nalesnik wrote:
> > On 2017/04/28 15:50:52, dak wrote:
> > > Does an extra-offset in X direction even make sense when the systems are
> > spaced
> > > according to their skylines _before_ the extra-offset is applied?
> > 
> > Well, X-offset of line-break-system-details is applied in make-page-stencil,
> > too.
> 
> In any case, having an extra-offset in the Y direction is obviously much more
> useful.  Extra-offset in the X direction seems a bit superfluous, since it's
> easy enough to set 'X-offset based on the left edge of the printing space.

Or, rather, I would imagine that the extra-offset setting for X would be the
same as X-offset....

> My
> original code created an extra-Y-offset, and I'm happy to go back to this.
> 
> Opinions?

[thomasmorley651, 2017-04-28 22:49:25]

On 2017/04/28 22:27:12, david.nalesnik wrote:
> On 2017/04/28 22:24:57, david.nalesnik wrote:
> > On 2017/04/28 16:15:42, david.nalesnik wrote:
> > > On 2017/04/28 15:50:52, dak wrote:
> > > > Does an extra-offset in X direction even make sense when the systems are
> > > spaced
> > > > according to their skylines _before_ the extra-offset is applied?
> > > 
> > > Well, X-offset of line-break-system-details is applied in
make-page-stencil,
> > > too.
> > 
> > In any case, having an extra-offset in the Y direction is obviously much
more
> > useful.  Extra-offset in the X direction seems a bit superfluous, since it's
> > easy enough to set 'X-offset based on the left edge of the printing space.
> 
> Or, rather, I would imagine that the extra-offset setting for X would be the
> same as X-offset....
> 
> > My
> > original code created an extra-Y-offset, and I'm happy to go back to this.
> > 
> > Opinions?

If I understand correctly the default systems X/Y-offset is calculated
elsewhere, I like the possibility to offset those values.
So I'd vote for keeping extra-offset as in your last patch-set.
Although I'm aware David K's point is important, I think a user doing manual
positioning, is responsible to deal with possible problems (collisions), too.

[david.nalesnik, 2017-04-29 00:36:36]

On 2017/04/28 22:49:25, thomasmorley651 wrote:
> On 2017/04/28 22:27:12, david.nalesnik wrote:
> > On 2017/04/28 22:24:57, david.nalesnik wrote:
> > > On 2017/04/28 16:15:42, david.nalesnik wrote:
> > > > On 2017/04/28 15:50:52, dak wrote:
> > > > > Does an extra-offset in X direction even make sense when the systems
are
> > > > spaced
> > > > > according to their skylines _before_ the extra-offset is applied?
> > > > 
> > > > Well, X-offset of line-break-system-details is applied in
> make-page-stencil,
> > > > too.
> > > 
> > > In any case, having an extra-offset in the Y direction is obviously much
> more
> > > useful.  Extra-offset in the X direction seems a bit superfluous, since
it's
> > > easy enough to set 'X-offset based on the left edge of the printing space.
> > 
> > Or, rather, I would imagine that the extra-offset setting for X would be the
> > same as X-offset....
> > 
> > > My
> > > original code created an extra-Y-offset, and I'm happy to go back to this.
> > > 
> > > Opinions?
> 
> If I understand correctly the default systems X/Y-offset is calculated
> elsewhere, I like the possibility to offset those values.

Yes, but 'X-offset already acts as an offset from default values.  Try the
following example.  Any setting of 'X-offset is obviously in relation to what's
on your screen.  Set indent, short indent, left-margin to what you like.

\version "2.19.59"

\paper {
  left-margin = 40
  indent = 30
  short-indent = 30
}

\book {
  \score {
    <<
      \new Staff <<
        \new Voice {
          \overrideProperty
Score.NonMusicalPaperColumn.line-break-system-details
            #'((X-offset . 0))
          s1*5 \break
          \overrideProperty
Score.NonMusicalPaperColumn.line-break-system-details
            #'((X-offset . 1))
          s1*5 \break
        }
        \new Voice { \repeat unfold 15 { c'4 c' c' c' } }
      >>
      \new Staff {
        \repeat unfold 15 { d'4 d' d' d' }
      }
    >>
  }
}

In contrast 'Y-offset is always an offset from the top of the page.  If you
don't set it, LilyPond calculates it.  If you set it, Lilypond uses that
instead.  extra-Y-offset will then modify whatever's in Y-offset, default or
user-specified.

So what I'm saying is that 'X-offset already acts as an offset of the default,
so an extra-X-offset is not needed.

The only reasons I can see for keeping it are: you can offset your own setting
of X-offset (why?), and you can set X and Y together.

> So I'd vote for keeping extra-offset as in your last patch-set.
> Although I'm aware David K's point is important, I think a user doing manual
> positioning, is responsible to deal with possible problems (collisions), too.

X-offset and Y-offset don't check for collisions.  You can put systems on top of
each other, and move them right off the page.  (That's another attraction of
"extra-offset" for a name--there are plenty of warnings about potential
collisions.)

[dak, 2017-04-29 07:29:09]

On 2017/04/29 00:36:36, david.nalesnik wrote:
> On 2017/04/28 22:49:25, thomasmorley651 wrote:

> > So I'd vote for keeping extra-offset as in your last patch-set.
> > Although I'm aware David K's point is important, I think a user doing manual
> > positioning, is responsible to deal with possible problems (collisions),
too.
> 
> X-offset and Y-offset don't check for collisions.  You can put systems on top
of
> each other, and move them right off the page.  (That's another attraction of
> "extra-offset" for a name--there are plenty of warnings about potential
> collisions.)

When in doubt, let's not invent new interfaces.  The standard for changes done
_after_ spacing is resolved is extra-offset .  Even when just one of the extras
is non-zero and making the other non-zero is of very little usefulness.  I was
merely musing over whether there was any way to make it more useful, but then in
keeping with the general semantics used elsewhere, we should likely rather focus
on making X-offset do shifts before distance calculations and let extra-offset
work afterwards, useful or not.