[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Excludes grobs supported by cross-staff grobs from pure-relevant cal
From: |
k-ohara5a5a |
Subject: |
Re: Excludes grobs supported by cross-staff grobs from pure-relevant calculations (issue 12857043) |
Date: |
Wed, 14 Aug 2013 05:34:18 +0000 |
https://codereview.appspot.com/12857043/diff/3001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
https://codereview.appspot.com/12857043/diff/3001/lily/axis-group-interface.cc#newcode504
lily/axis-group-interface.cc:504: && dynamic_cast<Spanner *> (elts[i])))
So if a spanner lies over just one cross-staff item, we ignore the
entire spanner for purposes of estimation of the space needed by its
staff ? The spanner still takes up space, we are just slightly
uncertain of its position, due to the possibility that upon final
page-layout the position of the cross-staff item might force the spanner
to shift.
It would seem better to deal with the concept of
supported_by_cross_staff_grobs in side-support-interface, where we are
finding, or estimating, the position of the spanner so that it clears
its 'support's.
https://codereview.appspot.com/12857043/diff/3001/lily/side-position-interface.cc
File lily/side-position-interface.cc (right):
https://codereview.appspot.com/12857043/diff/3001/lily/side-position-interface.cc#newcode283
lily/side-position-interface.cc:283: && cross_staff
Under these conditions,
trying to estimate before line-breaking (pure)
where an object 'me' will align vertically (Y_AXIS)
against an object 'e' whose position depends on staff-spacing
(cross-staff)
we might want to skip this object 'e', whether 'e' is a stem or not.
If it is a stem, since we know it is cross-staff, is the test on the
next line of the stem's direction going to be reliable ? It seems best
to skip the stem and estimate the alignment against the remaining
objects in 'support'.
https://codereview.appspot.com/12857043/
- Re: Excludes grobs supported by cross-staff grobs from pure-relevant calculations (issue 12857043),
k-ohara5a5a <=