On Mon, Apr 25, 2011 at 6:43 PM, m...@apollinemike.com <m...@apollinemike.com> wrote: > > On Apr 25, 2011, at 5:37 PM, Han-Wen Nienhuys wrote: > >> On Mon, Apr 25, 2011 at 9:45 AM, <mts...@gmail.com> wrote: >>> I realized that it was way too restrictive to have cross-staff beams >>> avoid stems and beams - Reinhold had sent out a Beethoven example a >>> while back that would need cross staff beams to take other beams into >>> consideration. >>> >>> The real problem is that certain cross staff beams are not in fact cross >>> staff beams. This patch weeds them out of beam collision work via a new >>> function Beam::is_fake_cross_staff. Ultimately, this sorta logic can >>> disappear once the beam collision engraver moves up to the score level, >>> which seems like something that'll cause several bugs in the unstable >>> version (if history is any indication) and thus is something I'm holding >>> off on until this current crop of bugs dies down. >> >> Can you try with looking for the common Y refpoint of stems and beam, >> and seeing if that is an Y-aligment instead? This code looks a bit >> kludgey. >> > > What is a Y-alignment? I tried > > git grep y-alignment > git grep Y-alignment > git grep Yalignment > git grep yalignment > git grep y_alignment > > but got meager results.
Look for Align_interface. IIRC, the type has an get_axis() method (or similar). -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
