Give DynamicText horizontal space; issues 621 631

Give DynamicText horizontal space; issues 621 631

[pkx166h, 2011-07-25 20:46:23]

Passes make and reg tests show some differences but probably expected

See http://code.google.com/p/lilypond/issues/detail?id=631#c4

[Trevor Daniels, 2011-07-29 07:38:31]

LGTM (so far).
The text in section 4.5.2 Fixing overlapping notation, under the subheading
staff-padding property, needs adjusting to avoid referring back to the now
non-existent Dynamics example.  Also the override of 'extra-spacing-width in
that example showing how to change the baseline of dynamics is presumably no
longer required.
Trevor

[Keith, 2011-07-29 17:44:56]

On 2011/07/29 07:38:31, Trevor Daniels wrote:
> The text in section 4.5.2 Fixing overlapping notation, 
> under the subheading staff-padding property, 
> needs adjusting

Got it.  I'll post a revised patch after I `make doc`.

http://codereview.appspot.com/4805054/diff/5001/Documentation/learning/tweaks...
File Documentation/learning/tweaks.itely (right):

http://codereview.appspot.com/4805054/diff/5001/Documentation/learning/tweaks...
Documentation/learning/tweaks.itely:2624: attached.  It is not a property of
@code{DynamicText} but of
It is [[not a property of DynamicText but]] a property of

http://codereview.appspot.com/4805054/diff/5001/Documentation/learning/tweaks...
Documentation/learning/tweaks.itely:2627: spanners.  So this is the way to align
the dynamic marks in the
spanners :  [[So this is the way]]

http://codereview.appspot.com/4805054/diff/5001/Documentation/learning/tweaks...
Documentation/learning/tweaks.itely:2631: @cindex extra-spacing-width property,
example
dd

http://codereview.appspot.com/4805054/diff/5001/Documentation/learning/tweaks...
Documentation/learning/tweaks.itely:2638: \override DynamicText
#'extra-spacing-width = #'(-0.5 . 0.5)
d2k

http://codereview.appspot.com/4805054/diff/5001/Documentation/learning/tweaks...
Documentation/learning/tweaks.itely:2641: a4\f b\mf c\mp b\p
include a spanner
b4\f\> a g\p f\mf

[Carl, 2011-07-29 21:29:24]

LGTM.

Carl

[Neil Puttock, 2011-07-29 21:35:11]

I think this is a mistake.  We don't want dynamics to influence spacing unless
absolutely necessary.

For the snippet in issue 621, the correct approach would be either to whiteout
the dynamic or move it to the right slightly.

[Carl, 2011-07-29 21:44:25]

Just to be sure I understand, you'd prefer to require a manual tweak to deal
with the dynamic in the example snippet, rather than allow the automatic
behavior introduced with Keith's patch.

Is this correct?

[Neil Puttock, 2011-07-29 21:51:37]

On 29 July 2011 22:44,  <Carl.D.Sorensen@gmail.com> wrote:
> Just to be sure I understand, you'd prefer to require a manual tweak to
> deal with the dynamic in the example snippet, rather than allow the
> automatic behavior introduced with Keith's patch.

The automatic behaviour is undesirable, since it introduces extra
space before the dynamic to prevent the collision.  You're unlikely to
see this in engraved music.

Ideally, the collision would be handled by shifting the dynamic
automatically, taking into account any further dynamics which the
initial one might collide with if moved (in that case, a whiteout
would be more likely, but the shifting is preferred.)

Cheers,
Neil

[Keith, 2011-07-29 22:19:54]

On Fri, 29 Jul 2011 14:51:35 -0700, Neil Puttock <n.puttock@gmail.com> wrote:

> The automatic behaviour is undesirable, since it introduces extra
> space before the dynamic to prevent the collision.

Let's put that concept on the tracker for item 621.

> You're unlikely to see this in engraved music.

Very True.

However, when was deciding how to workaround 621 for my own scores,
I decided to space the note-column because I found that the most readable.

> Ideally, the collision would be handled by shifting the dynamic
> automatically, taking into account any further dynamics which the
> initial one might collide with if moved (in that case, a whiteout
> would be more likely, but the shifting is preferred.)

I personally see no reasonable way for Lilypond to do this automatically. 
Conceptually the DynamicsText would be able to break out into its own column,
either left or right of its parent, before spacing note-colums with their
springs.

My inclination now is to set a default white-out and padding for DynamicText,
and maybe also Hairpin, TimeSignature, etc.

Then the overlap is obvious but legible, and we can choose to move the
note-column
using minimum-X-extent (for which I really should put an example in the docs) or
just the DynamicText using X-offset.