Hi Jonathan,

On 4 Jul 2020, at 8:55 am, Jonathan Kew 
<jfkth...@gmail.com<mailto:jfkth...@gmail.com>> wrote:

On 03/07/2020 20:13, Bruno Le Floch wrote:
On 7/3/20 6:50 PM, Jonathan Kew wrote:
On 03/07/2020 16:26, Philip Taylor wrote:
Jonathan Kew wrote:

Many potential use-cases, I think, can be equally well addressed by multiple TeX
invocations under the control of a higher-level script or tool of some kind.
Perhaps there are compelling examples where this would not be the case, but I'm
not aware of them at the moment.

JK

A major use case could be for AucTeX preview of equations, or other wysywyg-like
interfaces where one wants to compile chunks of TeX code always with the same
preamble, and with no relevant changes in macros: one could have an ongoing TeX
run producing pdfs when provided with further input.

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?

There’s currently a thread called “startup time” about \dump’ing a new format 
file.
Similar kinds of consideration exist there, but at a different level (of 
course),
in choosing the best place to make that  \dump  call.

At least there it is clear what is the purpose for making the new format.
It is much less clear here what would be the new use-cases made possible
if such a  \nextpdf  primitive were made available.

  A currently-working
variant of this is the following (in bash), which ships out a first page, then
waits 10 seconds, then ships out another one.

$ (echo '\relax Hello world!\vfill\break' && sleep 10 && echo '\relax Another
pdf.\bye') | xetex

One could imagine a primitive \nextpdf that would make xetex produce 2 separate
pdfs (in the present case texput.pdf and secondfile.pdf)

$ (echo '\relax Hello world!\nextpdf{secondfile}' && sleep 10 && echo '\relax
Another pdf.\bye') | xetex

This looks equivalent to (xetex '\relax Hello world!\bye' && sleep 10 && xetex 
--jobname secondfile '\relax Another pdf.\bye'), right?

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’m on the fence too.

Of course another possibility for Phil is to put all the pages of *both* his 
desired PDFs into the same “master PDF”,
then use a command-line tool like  pdftk  to extract the relevant pages for one 
or other into a new PDF.

This would likely not work with Tagged PDF documents.
There the extraction into separate files would need to be done by Acrobat Pro,
so as to preserve the tagging structures and the page-based relationships of 
marked content.
But that’s an issue for the future.


JK



All the best.
Stay safe.

Ross


Dr Ross Moore
Department of Mathematics and Statistics
12 Wally’s Walk, Level 7, Room 734
Macquarie University, NSW 2109, Australia
T: +61 2 9850 8955  |  F: +61 2 9850 8114
M:+61 407 288 255  |  E: ross.mo...@mq.edu.au<mailto:ross.mo...@mq.edu.au>
http://www.maths.mq.edu.au
[cid:image001.png@01D030BE.D37A46F0]
CRICOS Provider Number 00002J. Think before you print.
Please consider the environment before printing this email.

This message is intended for the addressee named and may
contain confidential information. If you are not the intended
recipient, please delete it and notify the sender. Views expressed
in this message are those of the individual sender, and are not
necessarily the views of Macquarie University. <http://mq.edu.au/>
<http://mq.edu.au/>

Reply via email to