On 21 May 2015, at 11:01, David Kastrup <[email protected]> wrote: > > > In the CG I read > > For certain grobs, the @code{Y-extent} is based on the @code{stencil} > property, overriding the stencil property of one of these will > require an additional @code{Y-extent} override with an unpure-pure > container. When a function overrides a @code{Y-offset} and/or > @code{Y-extent} it is assumed that this will trigger line breaking > calculations too early during compilation. So the function is not > evaluated at all (usually returning a value of @samp{0} or > @samp{'(0 . 0)}) which can result in collisions. A @q{pure} function > will not affect properties, objects or grob suicides and therefore will > always have its Y-axis-related evaluated correctly. > > Currently, there are about thirty functions that are already considered > @q{pure} and Unpure-pure containers are a way to set functions not on > this list as @q{pure}. The @q{pure} function is evaluated @emph{before} > any line-breaking and so the horizontal spacing can be adjusted > @q{in time}. The @q{unpure} function is then evaluated @emph{after} > line breaking. > > This is all very nice. Except that it is the function calls labelled as > *pure* that actually receive start/end values indicating particular > breakpoints of the system that the respective grob is in. What's the > deal with that?
I’d have to dive back into it to remember correctly, but I’m pretty sure that these values are ignored. Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
