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

[mtsolo]

https://codereview.appspot.com/12957047/diff/46001/lily/paper-system.cc
File lily/paper-system.cc (right):

https://codereview.appspot.com/12957047/diff/46001/lily/paper-system.cc#newcode55
lily/paper-system.cc:55: if (head == ly_symbol2scm ("skyline-stencil"))
On 2013/08/24 16:19:27, dak wrote:
> It seems awkward and error-prone to go through a number of stencil
types here
> just for fishing out footnotes.  Of course, this is just another layer
of
> ugliness on top of existing ugliness, but it would seem that we
actually want a
> separate _backend_ for fishing out footnotes, so that all the default
> interpretations of stencils are done correctly.

Agreed - it's a problem in general of markups being implemented
differently than grobs, which has plagued footnotes from the beginning.

https://codereview.appspot.com/12957047/diff/46001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):

https://codereview.appspot.com/12957047/diff/46001/lily/stencil-integral.cc#newcode915
lily/stencil-integral.cc:915: SCM skyline_stencil = scm_cadr (expr);
On 2013/08/24 16:19:27, dak wrote:
> Why would this traverse the skyline_stencil rather than the real one?

Because we are using the skyline stencil as a substitute for the
dimensions of the real one.

https://codereview.appspot.com/12957047/diff/46001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/12957047/diff/46001/scm/define-markup-commands.scm#newcode730
scm/define-markup-commands.scm:730: (make-box-skyline-stencil
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)?

> Of course this would be incompatible with previous behavior, but more
likely
> matching the expectations?

> I am not sure that replacement skylines are the right thing anyway,
but it seems
> sort of pointless _if_ you propose they are to not use them here.

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.

https://codereview.appspot.com/12957047/diff/46001/scm/stencil.scm
File scm/stencil.scm (right):

https://codereview.appspot.com/12957047/diff/46001/scm/stencil.scm#newcode689
scm/stencil.scm:689: (let ((sur (make-filled-box-stencil x y)))
On 2013/08/24 16:19:27, dak wrote:
> A filled-box stencil seems like serious overkill here when all you
want is
> setting the dimensions.  A stencil operator for just setting
dimensions seems
> less awkward.  There are two possibilities: have it produce an empty
stencil
> expression but with dimensions, and then use make-skyline-stencil on
it.  Or
> have it contain an inner expression anyway.

> In that case, make-box-skyline-stencil (what an awkward name) does not
need to
> call either make-filled-box-stencil nor contain skyline-stencil
anyway.

> It means that one needs one more stencil primitive _if_ one wants to
support
> make-skyline-stencil.  But it avoids juggling with an obscure
combination of
> stencil operations if one doesn't.

The empty stencil wouldn't work, as stencil-integral.cc operates on the
contents of the stencil (lines, curves, etc.), not on the dimension.
So, it would read an empty stencil as empty and not take it into account
in the skyline, irrespective of the dimension.

I'm not exactly sure what you mean in the rest of the comment, nor do I
see why the filled-box-stencil is overkill.  We need to draw a box
around the stencil at some time, and this gets the job done pretty
efficiently (there's not much overhead in stencil creation).  I'm open
to other implementation suggestions, though.

https://codereview.appspot.com/12957047/