[XeTeX] [tex-implementors] Proposal : that TeX engines generating PDF directly should be able to close the output file without terminating.

[Jonathan Kew]

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