Re: Changes the Y offset callback of multi-measure rest. (issue4389047)

[address@hidden]

On Apr 13, 2011, at 6:51 AM, address@hidden wrote:

> The only (big) issue with this patch as it stands is that, at some point
> in the chain, the Y-offset of the multi-measure-rest is being fed into
> that which controls MultiMeasureRestText positioning.  Before, it would
> receive the Y-offset of 0, which did not bump these texts (i.e.
> fermataMarkup) up.  Now, it receives the new Y-offset, which causes
> these grobs to rise above their prior placement.
> 
> I don't really where this bumping-up of MultiMeasureRestText grobs is
> done...maybe Side_position_interface::general_side_position ?  Thoughts
> would be appreciated!
> 

After further reading, I get the sense that the issue comes from the fact that 
the pure_relative_y_coordinate that an MMR needs to work is 0.0, and that the 
shift of staff space can only happen after all of the positioning has been done 
(read: in the print function).

It seems like the real problem is that 
ly:side-position-interface::y-aligned-side is not the appropriate function for 
MultiMeasureRestText #'Y-offset given how users likely want these grobs to be 
typeset.  Try:

{
R1^\fermataMarkup
\override Staff . MultiMeasureRest #'Y-offset = #-1.5
R1^\fermataMarkup
\override Staff . MultiMeasureRest #'Y-offset = #0.5
R1^\fermataMarkup
\override Staff . MultiMeasureRest #'Y-offset = #1.0
R1^\fermataMarkup
\override Staff . MultiMeasureRest #'Y-offset = #2.0
R1^\fermataMarkup
}

IMO, the fermata should not move in any of these cases, or rather, its moving 
should be a non-default behavior that can be requested by the user.

Assuming that others agree, I think that this should be fixed first before 
tackling issue 1604.  And, if others agree, is there an existing function that 
can achieve this behavior?

Cheers,
MS