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

[Mike Solomon]

On 26 août 2013, at 07:36, address@hidden wrote:

> On 2013/08/26 04:08:17, mike7 wrote:
>> On 25 août 2013, at 16:04, mailto:address@hidden wrote:
> 
>> > On 2013/08/25 08:22:01, mike7 wrote:
>> >> On 25 août 2013, at 09:15, mailto:address@hidden 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