http://code.google.com/p/lilypond/issues/detail?id=3503
On 2012/11/16 20:32:54, mike7 wrote:
On 14 nov. 2012, at 07:33, mailto:m...@mikesolomon.org wrote:
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 : [what is now input\regression\dynamics-avoid-cross-staff-stem-2.ly]
This was a side-effect of marking the entire NoteColumn as cross-staff if it contains a cross-staff-stem. The DynamicLineSpanner responds by becoming cross-staff (as has been done for a long time, for spanners normally belonging to a Voice) and delays placement of the 'f' until after staff-spacing (thus possibly overwriting the next staff down the page). Grouping objects like NoteColumn, however, are not usually marked cross-staff if some contents of the group are cross-staff. Marking NoteColumn as cross-staff requires the marking to be ignored in few places https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode115 https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode257 https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode896 The 'f' would then avoid the stem, but tuck in alongside and cross beam, as the beam is not part of the NoteColumn. Another special case, though, replaces the skyline of the note and stem with a box https://codereview.appspot.com/6827072/diff/38003/lily/side-position-interface.cc#newcode326 These changes were all originally added for fingerings, but for fingerings we had to restore the old 'add-stem-support' mechanism to choose whether slide down alongside the stem.
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,
We can tell dynamics to acknowledge Stems and NoteHeads individually, and become cross-staff if the stem is, *after* you include cross-staff grobs into vertical calculations. Until that time, the old code does a better job of dynamics overall. https://codereview.appspot.com/6827072/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
