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

[Mike Solomon]

On 26 août 2013, at 11:41, address@hidden wrote:

> On 2013/08/26 06:42:38, mike7 wrote:
>> On 26 août 2013, at 08:35, mailto:address@hidden wrote:
> 
>> > So why do you talk about that in the first place?
> 
>> Because I'd rather spend more time implementing a solid system than
> less time
>> implementing a kludge.
> 
> In the context of this issue, we are currently talking about not doing
> anything at all.  It seems like the best course forward with regard to
> resolving the reported regression would be to just adapt Keith's
> patch.

I think that if we can devise a better system, the creation of a new stencil 
primitive is unnecessary.  If we agree that we should implement a system where 
stencils are carriers of their own skylines, then we should fix this bug using 
that system.

But if there is no better system, then we should go with Keith's patch.

> 
>> What I'm proposing (making skylines a stencil data
>> member) is more work but seems less kludgy than creating a stencil
> primitive
>> containing skylines.
> 
> Again: this is _totally_ orthogonal to the issue at hand.  If you want
> to talk about that, create a new issue rather than drive an existing
> issue into the ground.

You're right that this discussion would be better on the issue tracker than on 
a review of a patch - we can move it over there.

> 
>> >> It would be better and more consistent with currently practices in
>> >> the code base if stencils carried their own skyline information (as
>> >> they do their own dimensions), which would require a lot of
> juggling
>> >> code around.
>> >
>> > In the context of reviewing this patch, this is a straw man
> argument.
> 
>> In the context of figuring out the best way to do things, this is
> important.  It
>> would be better to decide what problem we're trying to solve and
> implement it
>> correctly now rather than creating a temporary solution that we do
> away with
>> later.
> 
> Ok, let's get to the gist of it: for arranging items inside of a
> markup, there are several concepts: stencil geometry, reference
> points, escapement values (after placing a glyph at the current
> reference point, move by the respective escapement for the current
> direction of alignmen).  For lining up stencils, _only_ escapement
> values and reference points are of interest.  The outlines come into
> play _between_ independent markups, when we create a graphical
> arrangement on the page.
> 
> So in general, we don't need outlines until the finished markup.
> \with-dimensions operates on the dimensions interesting for working
> within markups.  Unfortunately, we raised the expectation that those
> are the same that are valid outside and advertised \with-dimensions
> accordingly.  This is what this issue is about.
> 
> Generating a skyline from individual elements is a complex operation.
> When done all at once, we have a complexity of O(n lg n) for n
> elements.  When integrating a single element at a time, the complexity
> rises to O(n^2).  So we don't want to assemble skylines one by one if
> we can avoid it.  Markup functions assemble stencils to stencils.  If
> we can calculate the skyline (when needed) in one go from the complete
> stencil arrangement, we save a lot of effort, and that's the rule
> rather than the exception.
> 
> So we don't want to carry skylines along with stencils that will not
> be used individually on the page but will rather be integrated into a
> markup.
> 

I agree.  If stencils have both dimensions and skylines, we can use merging 
based on dimensions as the default and skylines only when asked.  This would 
avoid the time cost you talk about above while at the same time allowing one to 
use skyline placement in the interior of a stencil when needed, as currently 
skylines are only available for use between grobs.

>> It seems like stencil expressions should not contain dimensional
>> information.  Where it does (like, for example, the stencil command
>> 'translate-stencil defined in define-stencil-commands.scm), this
>> seems like legacy code that has not evolved with LilyPond and is
>> barely used.
> 
> The dimensional information is used for stencil-add-at-edge, and most
> certainly for all the various stencil stacking operations, forming
> lines and columns.  "barely used" is a mischaracterization if I ever
> saw one.

I believe you are talking about dimensional information in the stencil 
dimension cache (dim_ in C++).  Above, I'm talking about the "stencil 
expression" (expr_ in C++).  Currently, stencil dimension information contained 
in the expression is _only_ used to tell the backends where to place a stencil 
or how to make the stencil skyline.  It is not used to line things up: the dim_ 
cache is used for this.

> 
>> So, as long as we're going to solve this problem, we should have a
>> broader discussion about how stencils are put together.
> 
> In the course of this issue, we should fix the perceived regression.
> It seems like Keith's code does that just fine.

It does.  But we should only add a new stencil primitive if we're not convinced 
that there is a better way to go about things.

> 
>> I argue that we should not be putting dimension information in the
>> stencil expression itself.
> 
> Markups plug together stencils based on dimension information,

But not based on dimension information in the stencil expression itself.  This 
is all in the dim_ cache.  My whole argument is that putting dimension 
information to be used for placing stencils in the stencil expression (expr_) 
goes against the current stencil model.

> and
> that is what fonts do as well.

This is a good example.  Font escapement values are contained in tables outside 
of the actual data holding the visual representation of the fonts.  Keith's 
proposed patch and my first patch are the equivalent of rolling the escapement 
data in with the data structure holding the letter.

To summarize: stencil expressions (expr_) currently do not contain information 
for how to place stencils with respect to others.  They contain information 
passed to the backends on how to lay out stencils.  If we adopt either Keith's 
patch or my first one (which I created before I thought this fully over), we 
will create one stencil primitive that uses the stencil's expression to 
influence layout decisions.  This does not seem consistent with current 
practice and I believe we should find a solution that avoids it.

Cheers,
MS