Measure 'staff-padding' to reference points, as claimed in its docstring

five commits

Measure 'staff-padding' to reference points; issue 3026
 lily/side-position-interface.cc |    6 +++---
 scm/define-grobs.scm            |    4 ++--

DynamicText: reference point at middle of ex-height
 scm/define-grobs.scm |    3 +--
 scm/output-lib.scm   |    5 +++++

Doc: update staff-padding
 Documentation/learning/tweaks.itely                |   20 +-
 Documentation/notation/keyboards.itely             |    2 +-
 Documentation/notation/spacing.itely               |    6 +-
 .../snippets/new/broken-crescendo-hairpin.ly       |   42 +++
 Documentation/snippets/new/expressive-headword.ly  |  268 ++++++++++++++++++++
 Documentation/snippets/new/pitches-headword.ly     |  137 ++++++++++
 .../vertically-aligned-dynamics-and-textscripts.ly |   34 +++
 7 files changed, 493 insertions(+), 16 deletions(-)

makelsr
 Documentation/snippets/broken-crescendo-hairpin.ly |   47 ++++++++------------
 Documentation/snippets/expressive-headword.ly      |   17 ++++---
 Documentation/snippets/pitches-headword.ly         |   22 +++++-----
 .../vertically-aligned-dynamics-and-textscripts.ly |   30 ++++++------

convert-ly rule
 python/convertrules.py |    8 ++++++++

[Keith, 2013-09-06 03:02:11]

DynamicText is shifted to that the center of the 'm' in "mf" is at the reference
line of the DynamicLineSpanner.

A shift of reference line to half the ex-height in LyricText would help people
who want truly centered lyrics, but that is another issue.

The right way to shift the reference line in TextScripts would seem to be on
each string of text, because we can mix font-sizes in markup.  This could change
the alignment in hand-crafted markup though, so I did not move this reference
line.  With the reference line for text still at the baseline, there there is no
good default 'staff-padding for TextScripts, because we generally want the
baseline further below the staff that above it.

https://codereview.appspot.com/7005056/diff/29001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7005056/diff/29001/scm/output-lib.scm#newcode861
scm/output-lib.scm:861: 
Below is an alternative function for finding the point in "mf" that should line
up with the haripin: Y-offset =  #(center-of-text "m")

Its only benefit is if people use dynamic fonts where font-size=0 has an
ex-height significantly different from that in Feta.  If used by default,
though, it costs an extra stencil-creation per dynamic.

[lemzwerg, 2013-09-06 05:01:03]

LGTM.

https://codereview.appspot.com/7005056/diff/29001/Documentation/notation/spac...
File Documentation/notation/spacing.itely (left):

https://codereview.appspot.com/7005056/diff/29001/Documentation/notation/spac...
Documentation/notation/spacing.itely:2048: <<
s/midlne/midline/

[Trevor Daniels, 2013-09-07 10:06:25]

A couple of typos.  I can't give a LGTM as
I haven't recompiled to check regtests or
docs, but eyeballing it looks good.

Trevor

https://codereview.appspot.com/7005056/diff/39001/Documentation/learning/twea...
File Documentation/learning/tweaks.itely (right):

https://codereview.appspot.com/7005056/diff/39001/Documentation/learning/twea...
Documentation/learning/tweaks.itely:2706: the minimum distance from the staff to
the oustide-staff object.
"outside-staff"

https://codereview.appspot.com/7005056/diff/39001/Documentation/snippets/brok...
File Documentation/snippets/broken-crescendo-hairpin.ly (right):

https://codereview.appspot.com/7005056/diff/39001/Documentation/snippets/brok...
Documentation/snippets/broken-crescendo-hairpin.ly:19: the bottom edge of the
rectangle when spacing it against the haripin.
"hairpin"

[Mark Polesky, 2013-09-18 23:45:37]

https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/twea...
File Documentation/learning/tweaks.itely (right):

https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/twea...
Documentation/learning/tweaks.itely:2987: \override
DynamicLineSpanner.staff-padding = #3
I think we should stop using the `#' for scheme numbers.
http://lilypond.org/doc/v2.17/Documentation/changes/index.html

This applies elsewhere in the patchset, though I'll just mention it here.

[Keith, 2013-09-19 05:26:52]

On 2013/09/18 23:45:37, Mark Polesky wrote:

> I think we should stop using the `#' for scheme numbers.

But when it is time to make that change, we would make the change over all the
documentation at once.