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

[dak]

On 2013/08/26 09:11:39, mike7 wrote:
> On 26 août 2013, at 11:41, mailto: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.

I am not getting through to you at all.  You are conflating orthogonal
issues with the result of blocking everything.

The semantics of \with-dimensions and its advertised behavior create
the situation that we need to reserve space for a stencil in the
generated skyline.

Matching the corresponding expectations has a certain awkwardness, but
we decided to go along with it, making the non-match of expectations a
Critical Regression.

All the big plans and mechanisms you propose here do _not_, I repeat
_not_ change even the slightest bit of \with-dimensions having an
impact on skylines.

Stencil dimensions can _not_ be replaced by skylines when assembling
markups for _both_ conceptual as well as performance reasons.  So the
problem of \with-dimensions being an ugly duckling is not at all
addressed by your complex proposals far outside the range of
addressing a regression.

> I agree.  If stencils have both dimensions and skylines, we can use
merging
> based on dimensions as the default and skylines only when asked.

And that's exactly what we do now.

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

Skylines are available when you call the stencil-integrate stuff on
stencil expressions.

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

Not really a cache.  It's part of the stencil just like the stencil
expression is and assembled in parallel with it.

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

There is none.  We want to bypass stencil integration, and there is no
primitive for doing that right now.

What you call a "better way" is adding a new stencil primitive that
does something much more complex but that can be tricked into behaving
like the simpler stencil primitive implemented by Keith at the cost of
additional complexity and using unrelated existing primitives like
filled-box that map to a rounded-box for the backends which gets
calculated but never makes it anywhere.

It's like refusing to implement an abs(x) primitive since you can
write sqrt(x*x) instead with only a moderate loss of performance, some
new error cases and a slight loss of precision.

Or like saying that TeX does not need an expandable way to repeat a
given sequence a run-time specified number of times since it has the
\romannumeral primitive allowing for things like

\def\recur#1{\csname rn#1\recur}
\def\rn#1{}
\def\rnm#1{\endcsname{#1}#1}
\def\replicate#1{\csname rn\expandafter\recur
  \romannumeral\number\number#1 000\endcsname\endcsname}
\message{\replicate{100}{I shall not ask for primitives in class.
\space}}

Nobody wants to maintain that sort of thing.  So independent of the
theoretical possibility of abusing some kind of overgeneric construct
to-be-designed into the behavior we want to see, there is merit for
having a primitive that does just what we want it to do.


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