Fix #915 (faulty full-bar rest positioning with clef).

Fix #915 (faulty full-bar rest positioning with clef).

Allow user override of left/right spacing of full-bar rests relative to
barlines or prefatory material.

[Carl, 2010-04-19 19:37:12]

Thanks,

Carl

http://codereview.appspot.com/931041/diff/1/9
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/931041/diff/1/9#newcode756
scm/define-grob-properties.scm:756: (spacing-pair ,pair? "A pair of booleans
which set the spacing for a
Should the name of this property be something like ignore-prefatory-material?

Or perhaps even better, should we change space-to-barline to a pair of booleans,
and use space-to-barline for both?  It seems to me that space-to-barline is the
same property as spacing-pair, except that it only goes one direction.

I'd prefer, if possible, to have the property potentially apply to any grob that
needs to be centered, instead of just multi-measure rests.

[Neil Puttock, 2010-04-19 21:13:14]

Hi Carl,

Thanks for checking this out.

On 2010/04/19 19:37:12, Carl wrote:

> Should the name of this property be something like ignore-prefatory-material?

Hmm, possibly; it's certainly less vague. :)

Actually, I've had a thought: instead of using booleans, it would probably make
more sense (and allow finer control) to use a pair of symbols in a similar
manner to break-align-symbols.  So the default setting would be

'(break-alignment . bar-line)


> Or perhaps even better, should we change space-to-barline to a pair of
booleans,
> and use space-to-barline for both?  It seems to me that space-to-barline is
the
> same property as spacing-pair, except that it only goes one direction.

Indeed, when measured the space to the right hand side column it's doing the
same thing.  But what would you do about the left spacing?  For NoteSpacing it
wouldn't make any sense since 'space-alist settings for the breakable grobs
control this, so the car would be ignored.

> I'd prefer, if possible, to have the property potentially apply to any grob
that
> needs to be centered, instead of just multi-measure rests.

There aren't any others as far as I'm aware.

Cheers,
Neil

[Patrick McCarty, 2010-04-29 04:30:03]

LGTM.

Thanks,
Patrick

[Patrick McCarty, 2010-04-29 04:31:19]

On 2010/04/19 21:13:14, Neil Puttock wrote:
> On 2010/04/19 19:37:12, Carl wrote:
> 
> > Should the name of this property be something like
ignore-prefatory-material?
>
> Actually, I've had a thought: instead of using booleans, it would probably
make
> more sense (and allow finer control) to use a pair of symbols in a similar
> manner to break-align-symbols.  So the default setting would be
> 
> '(break-alignment . bar-line)

I wouldn't be opposed to this idea.

[Patrick McCarty, 2010-06-18 21:56:10]

Thanks for working on this, Neil.  Just one quick comment, and otherwise, LGTM.

http://codereview.appspot.com/931041/diff/14001/15007
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/931041/diff/14001/15007#newcode757
scm/define-grob-properties.scm:757: multi-measure rest relative to its left and
right @code{BreakAlignment}s.")
Should this docstring be generalized, i.e. not mentioning multi-measure rests? 
I am thinking that this property might become useful in the slur code ...
eventually :)

[Neil Puttock, 2010-06-29 23:58:07]

On 2010/06/18 21:56:10, Patrick McCarty wrote:

> http://codereview.appspot.com/931041/diff/14001/15007
> File scm/define-grob-properties.scm (right):
> 
> http://codereview.appspot.com/931041/diff/14001/15007#newcode757
> scm/define-grob-properties.scm:757: multi-measure rest relative to its left
and
> right @code{BreakAlignment}s.")
> Should this docstring be generalized, i.e. not mentioning multi-measure rests?

> I am thinking that this property might become useful in the slur code ...
> eventually :)

Sure, I'm happy to emend the description (I think Carl will be happy too. ;)

Do you think the property name's OK though?  I agree with Carl it could be a bit
more descriptive, but then there's also the need to keep verbosity to a minimum.

[Carl, 2010-06-30 01:37:20]

On 2010/06/29 23:58:07, Neil Puttock wrote:
> On 2010/06/18 21:56:10, Patrick McCarty wrote:
> 
> Sure, I'm happy to emend the description (I think Carl will be happy too. ;)

Yep!

> 
> Do you think the property name's OK though?  I agree with Carl it could be a
bit
> more descriptive, but then there's also the need to keep verbosity to a
minimum.

I think that if we have to choose between verbosity and clarity, clarity should
win.  Although I prefer the shortest names we can use with clarity.

Thanks,

Carl

[Patrick McCarty, 2010-07-08 23:53:39]

On 2010/06/29 23:58:07, Neil Puttock wrote:
> 
> Do you think the property name's OK though?  I agree with Carl it could be a
bit
> more descriptive, but then there's also the need to keep verbosity to a
minimum.

Yes, I think the property name is fine.

-Patrick