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

[Mike Solomon]

On 27 août 2013, at 09:01, "Keith OHara" <address@hidden> wrote:

> On Mon, 26 Aug 2013 22:37:17 -0700, Mike Solomon <address@hidden> wrote:
> 
>> On 27 août 2013, at 07:18, "Keith OHara" <address@hidden> wrote:
>> 
>>> (1) At the moment, the stencil expressions are assembled first, when markup 
>>> is interpreted, and then stencil_traverser() reads the stencil expression 
>>> to figure the skylines.  So long as that approach remains in place we need 
>>> some sign in the stencil expression to be read by stencil_traverser() 
>>> telling it to omit the usual skyline around part of the stencil.  (I could 
>>> re-use 'delay-stencil-evaluation, but think a new primitive is wiser.)
>>> 
>>> 
>>> (2) If someday the skylines are assembled in parallel with 
>>> stencil-expressions when the markup is interpreted, then \with-dimensions 
>>> or \no-skyline could simply throw away the skyline it built for "text" (in 
>>> the examples above) and there is no need for a 'with-dimensions' primitive. 
>>>  (There would still be primitives that move markup like 'translate-stencil' 
>>> for things like \concat {B\flat}.)
>>> 
>>> Are systems organized as in (2) better systems than the one we have 
>>> organized as in (1) ?
>> 
>> Good summary of the current state of things.  I'd argue that (2) is better.
> 
> What, then, is your argument ?

What I put below - namely, that it is consistent with the previous practice of 
stencils separating layout information from graphical content.

> 
>> The original function definition for \with-dimension does not need a special 
>> primitive because dimension information is encoded in the stencil in 
>> parallel with stencil-expressions when the markup is interpreted.
> 
> The only problem that I have heard of a special primitive is that it would be 
> redundant, *if* we change a system of type (2) for building skylines.  In the 
> current system, the primitive seems fine.

It's true that a new primitive works.  But, it seems that, on a more systemic 
level, this is not a tenable solution as it would lead to the creation of many 
different stencil primitives for different types of padding.

> 
>> The same could be true of skylines, with the caveat that skylines should 
>> only be generated and used when asked for to save computation time, and 
>> otherwise dimensions should be used.
> 
> How are skylines asked-for, and is it possible to know if they were asked for 
> while interpreting the markup ?
> {c4-\markup \whiteout \pad-to-box #(-0.5 . 9) #(-0.5 . 1.5) \concat 
> {"Clarinet in B" \flat}}
> 

class Stencil {
  private :
    Scheme expr_;
    Box dim_;
    Skyline_pair *vskys_; // set to 0 in the constructor
    Skyline_pair *hskys_; // set to 0 in the constructor

  public :
    Skyline_pair* get_vskys () { if (!vskys_) create_vskys (); return vskys_; }
}

So, the idea is that we only ever create the skylines if they are asked for or 
if we use something like pad-to-box.  Then, if we are going to combine two 
stencils and neither of them have skylines set already, we do not calculate 
their skylines yet.  If one of them has skylines set, then somebody must have 
set it with something like with-dimension and we calculate the skyline of the 
other to create a composite skyline.

pad-to-box would not require the finding of the skyline of Clarinet in Bb, 
since we already have its X and Y dimensions.  The skyline resulting from the 
pad-to-box call would be calculated off of that.

> The current system (1) seems more efficient at generating only the needed 
> skylines.  We only need the skyline if the markup ends up in a TextScript 
> with 'vertical-skylines set, as opposed to titling markup, and then 
> stencil_traverser() works through the stencil expression and sees that it 
> need not traverse through argument of \pad-to-box and need not trace the 
> letters in "Clarinet in B"
> 

In the pseudocode above, imagine that a call to create_vskys () would only 
happen in the stencil traverser and in certain padding or concatenating 
scenarios.  This would be less efficient than (1) but not by much.

Cheers,
MS