[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pure/impure?!?!
From: |
Mike Solomon |
Subject: |
Re: pure/impure?!?! |
Date: |
Fri, 22 May 2015 12:59:39 +0300 |
On 21 May 2015, at 11:01, David Kastrup <address@hidden> 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
- pure/impure?!?!, David Kastrup, 2015/05/21
- Re: pure/impure?!?!,
Mike Solomon <=