> > And (b) additional data types has to be introduced for (e-)TeX to be
> > able to save all different kind of nodes.
> Mostly, when I've wanted that in the past I'd have been happy if the new
> \lastxxx primitives had put the removed node into a hbox so it could
> be saved in a box register, rather than introducing new register types
> for each node type. Admittedly new register types that allowed access to
> properties, such as, as you say, font information, would be useful, but
> if adding that is sufficiently hard to postpone indefinitely the ability
> to remove nodes from a constructed list, I'd take the simpler option of
> removing them to a box register.
i don't think this helps. the \accent primitive generates several nodes which
are individually depending on reals and only as a total block are device
independent, see §1125. and by the time they are constructed there may not be
a way to take them off as a block.
but even if one could remove individual kerns in such constructions safely,
the semantics and usability of the originally suggestions are questionable if
such constructs are part of the node list as i don't think one can safely
deduce what such a kern originally meant.
that said, i do agree that it is probably about time to get rid of the real
arithmetic or alternatively agree on standard real architecture (and as Morten
Said, Matthias already did the first step long time ago as a chance file).
But not by simply allowing random results. PS might get away with that as one
doesn't commonly implements line or page breaking solutions in this language
so the differences there are normally not wide ranging, but with TeX I like
to be able to take my documents safely from one computer to the next and see
identical results and not different line or page breaks, which would be the
> This e-mail has been scanned for all viruses by Star. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit: