Re: New grob-stencil needs to look at Beam-dimensions

[Thomas Morley]

Am Sa., 1. Juni 2019 um 14:33 Uhr schrieb David Kastrup <address@hidden>:
>
> Thomas Morley <address@hidden> writes:
>
> > Hi,
> >
> > currently I continue my work to create a Slash-grob for automatic slashed 
> > Beams.
> > The Slash-stencil needs to know Beam-properties (X-positions,
> > positions) to be adjusted. If I call those beam-properties directly
> > the Beam collopses, because this call is done before the Beam is
> > ready.
> > But if I wrap the Slash-stencil in another procedure like
> > (define slash-stil (lambda (grob) (lambda (grob) ...)))
> > all works.
> >
> > Questions:
> > - Why does it work? (it seems the outer procedure is called
> > before-line-breaking, the inner after-line-breaking)
> > - Is this something I can rely on (I'm thinking of patch) or am I
> > doing bug-using?
>
> Depends on whether someone asks for your stencil prematurely.  We have a
> lot of those implicit dependencies though.
>
> > - Is there a better/different method?
>
> An unpure/pure container has somewhat more defined semantics when its
> respective callbacks are exercised.  But if it works without, go for it.

So far I didn't encounter other problems, apart from my insufficient math...
I just asked on -user for some problem.

> If it doesn't and the Beam uses unpure-pure-containers, you can also use
> an unpure-pure-container and work with ly:pure-call and ly:unpure-call
> in your respective callbacks: those work even when the definition of
> Beam changes significantly.

Beam uses `grob::unpure-vertical-skylines-from-stencil´ for vertical-skylines.
I plan to use `grob::always-vertical-skylines-from-stencil´ there for Slash.
Though, as far as I know this has no direct impact on the used stencil
procedure.


Thanks,
  Harm