On 2013/08/26 04:51:50, mike7 wrote:
On 26 août 2013, at 07:36, mailto: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.
Indeed. Instead of calling stencil-integrate on a "surrogate stencil" or whatever for deriving a skyline, the respective stencil operation in stencil-integrate will just plug in a a "surrogate skyline" directly specified in the stencil operation and be done. Which is less work. https://codereview.appspot.com/12957047/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
