<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">Jonathan Kew wrote:<br>

      <br>

    </div>

    <blockquote type="cite"

      cite="mid:0443d4d5-89cb-71d4-1735-38a705a277bd@gmail.com">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.

      <br>

      <br>

      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.

      <br>

      <br>

      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.<br>

    </blockquote>

    <br>

    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 ?<br>

    <br>

    <i>** Phil.</i><br>

  </body>

</html>