Fix clef transposition alignment (issue 3186)

Issue 3186: fix clef transposition alignment

Until now, numbers indicating clef transposition (for example
in \clef "G_8") were simply centered against the clef glyph.
This was not optimal, because clef glyphs aren't symmetrical
- for example the hook of the treble clef isn't exactly at its
horizontal center, and thus the octavation number shouldn't
be exactly centered.

This commit allows to specify alignment separately for each
clef, taking into account their individual characteristics.
Alignments are stored in clef-alignments property.

[janek, 2013-04-10 22:17:56]

this fixes cue clef transposition alignment, but not optional yet

[janek, 2014-08-09 21:07:57]

Use Issue 4022. This should procuduce correct alignment in all cases.

[janek, 2014-08-09 21:12:22]

Please review.

Note that the diff between current patchset (#3) and previous one is broken
(probably because the patch had to be rebased and there were a lot of changes to
master since patchset 2).

[janek, 2014-08-16 21:51:39]

Pushed as 

commit 21a1e3b8267fd76ff261ed9f01e833d5d04703e7
Author: Janek Warchoł <lemniskata.bernoullego@gmail.com>
Date:   Wed Apr 3 21:46:56 2013 +0200

    Issue 3186: fix clef transposition alignment
    
    Until now, numbers indicating clef transposition (for example
    in \clef "G_8") were simply centered against the clef glyph.
    This was not optimal, because clef glyphs aren't symmetrical
    - for example the hook of the treble clef isn't exactly at its
    horizontal center, and thus the octavation number shouldn't
    be exactly centered.
    
    This commit allows to specify alignment separately for each
    clef, taking into account their individual characteristics.
    Alignments are stored in clef-alignments property.

[dak, 2014-08-16 22:23:38]

https://codereview.appspot.com/8363044/diff/6001/input/regression/clef-transp...
File input/regression/clef-transposition-placement.ly (right):

https://codereview.appspot.com/8363044/diff/6001/input/regression/clef-transp...
input/regression/clef-transposition-placement.ly:21: \override
Staff.Clef.full-size-change = ##t
This syntax is not version 2.16.0 as declared above

https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc
File lily/clef-modifier.cc (right):

https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc#newcode42
lily/clef-modifier.cc:42: me->get_property ("clef-alignments"));
Up to this point there is not exactly a fabulous amount of crash-proneness in
case of non-standard clef layout.  The code does not seem particularly prepared
to deal with a clef like varC.

Why would the table clef-alignments be stored in a context property?  It does
not seem to be context dependent.

[janek, 2014-08-17 12:58:28]

https://codereview.appspot.com/8363044/diff/6001/input/regression/clef-transp...
File input/regression/clef-transposition-placement.ly (right):

https://codereview.appspot.com/8363044/diff/6001/input/regression/clef-transp...
input/regression/clef-transposition-placement.ly:21: \override
Staff.Clef.full-size-change = ##t
On 2014/08/16 22:23:38, dak wrote:
> This syntax is not version 2.16.0 as declared above

Done.

https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc
File lily/clef-modifier.cc (right):

https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc#newcode42
lily/clef-modifier.cc:42: me->get_property ("clef-alignments"));
On 2014/08/16 22:23:38, dak wrote:
> Up to this point there is not exactly a fabulous amount of crash-proneness in
> case of non-standard clef layout.  The code does not seem particularly
prepared
> to deal with a clef like varC.

I'm not sure what you mean by "crash-proneness in case of non-standard clef
layout".  The code is supposed to center-align the ClefModifier if there is no
detailed alignment provided for a given clef, and as far as i can see this
works.  However, i agree that taking the 1-letter substring is not the most
elegant thing; i could change that.

> Why would the table clef-alignments be stored in a context property?  It does
> not seem to be context dependent.

You mean clef-alignments should be defined as a kind of a global variable,
someplace like in output-lib.scm?  Ok, this could be done like that - however, i
didn't find how such Scheme-defined global variables can be accessed from C++. 
Pointer, please?

[dak, 2014-08-17 13:14:18]

On 2014/08/17 12:58:28, janek wrote:
>
https://codereview.appspot.com/8363044/diff/6001/input/regression/clef-transp...
> File input/regression/clef-transposition-placement.ly (right):
> 
>
https://codereview.appspot.com/8363044/diff/6001/input/regression/clef-transp...
> input/regression/clef-transposition-placement.ly:21: \override
> Staff.Clef.full-size-change = ##t
> On 2014/08/16 22:23:38, dak wrote:
> > This syntax is not version 2.16.0 as declared above
> 
> Done.
> 
> https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc
> File lily/clef-modifier.cc (right):
> 
>
https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc#newcode42
> lily/clef-modifier.cc:42: me->get_property ("clef-alignments"));
> On 2014/08/16 22:23:38, dak wrote:
> > Up to this point there is not exactly a fabulous amount of crash-proneness
in
> > case of non-standard clef layout.  The code does not seem particularly
> prepared
> > to deal with a clef like varC.
> 
> I'm not sure what you mean by "crash-proneness in case of non-standard clef
> layout".  The code is supposed to center-align the ClefModifier if there is no
> detailed alignment provided for a given clef, and as far as i can see this
> works.  However, i agree that taking the 1-letter substring is not the most
> elegant thing; i could change that.
> 
> > Why would the table clef-alignments be stored in a context property?  It
does
> > not seem to be context dependent.
> 
> You mean clef-alignments should be defined as a kind of a global variable,
> someplace like in output-lib.scm?  Ok, this could be done like that - however,
i
> didn't find how such Scheme-defined global variables can be accessed from C++.

> Pointer, please?

Why would you want to access anything from C++?  Lots of callbacks are written
in Scheme, and it's not like you cannot also access Scheme variables, like with
ly_lily_module_constant.  At any rate, we are talking about character dimensions
here that are font-dependent.  So this effort should really be coordinated with
the efforts of the people switching various music fonts around, and then a
decision has to be made how the respective information regarding attachment
points/slant can be connected with various fonts.

Apart from the font specificity of the displacement (which likely warrants
coordination with the people working on multiple font support),
scm/parser-clef.scm uses global variables to store various clef characteristics.

[Keith, 2014-08-18 06:24:20]

https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc
File lily/clef-modifier.cc (right):

https://codereview.appspot.com/8363044/diff/6001/lily/clef-modifier.cc#newcode42
lily/clef-modifier.cc:42: me->get_property ("clef-alignments"));
On 2014/08/16 22:23:38, dak wrote:
> Up to this point there is not exactly a fabulous amount of crash-proneness in
> case of non-standard clef layout.  The code does not seem particularly
prepared
> to deal with a clef like varC.
> 
    \override Staff.ClefModifier.clef-alignments.varC = #'(+1 . +1)
    \clef "varC^8"
works for me.

> Why would the table clef-alignments be stored in a context property?  It does
> not seem to be context dependent.

A lot of potentially-overridable layout details are stored in context
properties.