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:
For your example, I was going to suggest that a simpler solution than "make"
ought to work: all it requires is a two-line batch file or shell script (or
similar: tools like Lua or Python or Perl would be fine) that performs the
two xetex runs you need. Then you'd call that script or batch file as your
"engine" in TeXworks, instead of calling xetex directly.
But I see that you have been offered a solution anyway now, basically using
(xe)tex as both the scripting language (to call another instance of itself)
and as the typesetting process. I don't normally wield tex in that way, as I
find other scripting languages easier and more flexible, but it should indeed
work.
As for closing the output PDF mid-job, and allowing you to start a new one:
I'm not sure how I feel about that. Is tex the right language to be using to
define and control complex multi-stage processes? While this *can* be done
(as the \write18 solution demonstrates for a simple case), I tend to think
it's the wrong tool for the job. There are languages that are much more
amenable to manipulating files and managing pipelines of processes; my
inclination would be to use one of those, with (xe)tex being called as
required to perform individual steps, rather than using tex as the overall
control language.
Thank you for your comments, Jonathan, which are much appreciated. While I
fully appreciate that [Xe]TeX is not a tool for "manipulating files and
managing pipelines of processe", I nonetheless think that the ability to
generate two or more distinct PDFs in a single run might be of some benefit.
May I ask if you would agree that that might be the case, without, of course,
any committment on your part to implementing such a feature ?
I would agree that it *might* be the case; I am at the moment some way from
being convinced that it *is* the case.
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?
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......
JK
