lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adds dimension stencil command to correct with-dimension (issue 1295


From: Mike Solomon
Subject: Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
Date: Sun, 25 Aug 2013 11:21:49 +0300

On 25 août 2013, at 09:15, address@hidden wrote:

> 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.
> 

I wrote this new patch based on my experience from slimming down the stencil 
list a couple years ago.  There used to be lots of stencil primitives whose 
handling code took up a bunch of space in lookup.cc, had a fair bit of code 
dups, and would have made stencil-integral.cc a nightmare.  I eliminated them 
(beam, bezier-sandwich, etc.) and implemented them in Scheme by combining other 
stencil primitives.

I think that adding a stencil primitive should only be done if there is no 
satisfactory solution using the current primitives (which is the case here).  
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?"  So far, this question is only 
ever asked in the specific form "how can we replace the outline of one shape 
with a box?"  But I think if we hardcode the "box" in that question (as both of 
our initial patch sets do), we will lead to the proliferation of multiple 
stencil primitives for different shapes if the need comes up.

The necessity that comes to mind for the more general solution is the work I 
did on line spanners, where we often want different skyline padding for the 
word in the spanner and the line.  That could be implemented by using the 
skyline-stencil primitive as I've coded it in the most recent patch set.

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]