On 14 nov. 2012, at 07:33, m...@mikesolomon.org wrote:
>> http://codereview.appspot.com/6827072/diff/1/lily/axis-group-interface.cc
>>
>> File lily/axis-group-interface.cc (right):
>>
>>
>> http://codereview.appspot.com/6827072/diff/1/lily/axis-group-interface.cc#newcode403
>>
>> lily/axis-group-interface.cc:403: Axis_group_interface::cross_staff (SCM
>> smob)
>> For what situation? Which object that supports axis-group-interface
>> (PianoPedalSpanner, DynamicLineSpanner) should be potentially considered
>> a cross-staff object?
>
> NoteColumn
Hey all,
One result of my approach is that grobs that were not previously cross staff
are. This allows for better positioning with respect to a system, but results
in collisions with other systems. Try the following on current master and this
patch :
foo = \new PianoStaff <<
\new Staff = "up" {
s1 |
}
\new Staff = "down" {
\clef bass
\stemDown
% keep staff alive
<c,, c,>8 [ <c,, c,>8_\f
\change Staff = "up"
g' g' ]
r2 |
}
>>
\score { \foo }
\score { \foo }
In current master, there is a dynamic-on-beam intersection, and w/ my patch
there is a dynamic-on-system intersection. Both of them are bad, but in terms
of future work on LilyPond, I think the dynamic-on-system is a better
alternative. The long-term goal of this work is to get cross-staff grobs into
vertical calculations, which will require removing several calls to
translate_axis. All of this work is moving in that direction by simplifying
grob positioning. The next step will be to eliminate the function
avoid_outside_staff_collisions and replace it with the the new
Side_position_interface::y_aligned_side that comes w/ this patch.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
