Re: Uses single algorithm for side-position spacing. (issue 6827072)

[k-ohara5a5a]

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:address@hidden 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/