Mike Solomon <m...@jongla.com> writes:
> On 21 May 2015, at 11:01, David Kastrup <d...@gnu.org> 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.
Ignored or not: those are values indicating breakpoints of the current
system. They should not even be available for functions evaluated
before any line-breaking. Or maybe they are called for one of a set of
tentative not-final line breaks, but in that case it would make little
sense to call the post-linebreak (impure?) functions without the actual
linebreak information.
There is some definite piece of the puzzle missing here.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
