[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pure/impure?!?!
From: |
David Kastrup |
Subject: |
pure/impure?!?! |
Date: |
Thu, 21 May 2015 10:01:49 +0200 |
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?
--
David Kastrup
- pure/impure?!?!,
David Kastrup <=