[XeTeX] [tex-implementors] Proposal : that TeX engines generating PDF directly should be able to close the output file without terminating.
Philip Taylor
P.Taylor at Hellenic-Institute.Uk
Sat Jul 4 14:17:28 CEST 2020
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
More information about the XeTeX
mailing list.