On 2013/08/24 16:33:39, MikeSol wrote:
On 2013/08/24 16:19:27, dak wrote:
> Stupid question: _iff_ you store a _whole_ replacement skyline
anyway,
> shouldn't pad-around just shift the original left/right/up/down
skylines
> left/right/up/down by the given amount (don't ask me what to do
about the
> corners, though)?
It's a good idea, but stencils don't have left/right/up/down, so it'd
be hard to
figure out how to add this padding to the stencils without additional plane-geometry functions.
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. The existing interface, \with-dimensions etc., gives a way to specify the simplest Skyline: a single box. I struggled to make a regression test for these functions. I used \pad-to-box #'(0 . 6) #'(0 . 1) fa......} to add a building around the dots... to the existing skyline of the "fa" and had to use debug-skylines to get the dimensions right. If I ever did need a more complex space-reservation shape, such as a PostScript stencil, I would at first make the space-reservation print light blue and \combine with the printing stencil, so I can see if I got the right shape. Your patch might save me a the few bytes of the \transparent version of the PostScript outline in my output. The meaning of the "Cells" output is a little mysterious to me, with Scheme a garbage-collected system and all, but this patch makes one third of the reg-tests report using between 3% and 8% more "cells", which can't be good. https://codereview.appspot.com/12957047/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
