Jonathan Kew wrote:
This raises the question of what state the TeX engine should return to
when the hypothetical \nextpdf primitive is executed. Does it return
to a pristine "initex" state, or a "freshly-loaded .fmt file" state,
or is the current state completely unchanged (does \jobname reflect
the new output name?), or what? Should the \count variables that are
by convention used to record page numbers get reset?
Does a new .log file also get started? What about \write output files
-- are they flushed and new files started?
It's true there would be a difference if there are macros etc. defined
while processing the first file, and then used while generating the
second. But I'm not sure this is really a commonly-required use case.
Consider me not yet persuaded......
I think that "not yet persuaded" is a perfectly reasonable position when
such a radical change has been proposed, but I remain completely
unconvinced of the alleged benefits of so-called "use cases". "Use
cases" are only what we can think of today — tomorrow, someone may think
of something totally different. When considering whether an idea is a
good one or not should not depend on whether or not one can find valid
use cases for it — the idea should be considered solely on its merits.
With Jonathan's earlier points, I completely agree — I can envisage
scenarios in which one would want to simply close the PDF file (having
first flushed any pending insertions), open a new one and carry on. I
can also envisage scenarios in which one would want the engine to behave
as if it had just been freshly launched. I would therefore suggest that
\newpdf be defined to inspect a mask variable (a count variable treated
as a bit set) which a user could elect to set as he or she wishes,
indicating which elements are to be carried over and which elements are
to be re-set.
Philip Taylor
