On 26 août 2013, at 07:36, d...@gnu.org wrote: > On 2013/08/26 04:08:17, mike7 wrote: >> On 25 août 2013, at 16:04, mailto:d...@gnu.org wrote: > >> > On 2013/08/25 08:22:01, mike7 wrote: >> >> On 25 août 2013, at 09:15, mailto:k-ohara5...@oco.net wrote: >> > >> >> > A second stencil is not a very good data structure for reserving >> > space. >> >> > Skylines are better at this, and we can \once\override 'padding > and >> >> > 'horizon-padding to get padding that follows the outlines of the >> >> > stencil. >> >> [...] >> >> If >> >> we're going to do that, then we should think of the general problem >> > we're trying >> >> to solve. To me, the general problem seems to be "how can we > replace >> > the >> >> outline of one shape with that of another?" >> > >> > No, that is _absolutely_ not the general problem here. The general >> > problem is: "how can we replace the outline/skylines of one stencil > with >> > a different outline/skyline?" >> > > >> It seems like what would make sense is for stencils to carry their own > skyline >> information, much like they carry their own dimension information. > > So what? Whether or not the skyline is cached or even persistent is > completely orthogonal to the issue at hand, namely what we want to be > able to override a stencil's skyline in stencil-integration with.
It changes the amount of work required to arrive at a solution. I agree that overriding a skyline with a skyline is best way to do this. Stencils have XY dimensions, as do grobs, and often the grob dimensions come from the stencil but sometimes not. Similarly, stencils should have horizontal-vertical skylines, as do grobs, and often the grob skylines come from the stencil but sometimes not. That means that the Stencil class, which currently has members: Box dim_; SCM expr_; would need a third member to hold skylines. The issue is that if we start tackling it this way, it'd be a huge project and a lot of juggling code around. Keith's solution and the one I originally proposed are more efficient expedients but seem like a band-aids on a larger issue. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
