[luatex] Is there a hook that could be used by a pdf postprocessor?

[Knut Petersen]

Am 11.12.2017 um 21:27 schrieb Hans Hagen:
>
>> A "stat lyInLatex.pdf" after luatex finished shows that 40 bytes are not written at the time of callback execution.
>
> Which doesn't mean that there cannot be something written via lua scripts. Also, there is be more to be wrapped up: the log file, file recording, closing of the synctex file, etc.
>

Yes. In currently stop_run is documented as cited below:

    8.5.3 stop_run
    function()
    end
    This callback replaces the code that prints LuaTEX’s statistics and ‘output written to’ messages.

In 2012 <http://tug.org/pipermail/luatex/2012-May/003647.html> Patrick Gundlach discussed on this list if the sentence "The output file is not complete at this point and thus you cannot use this callback to post process the output file."  should be added to the documentation. The subject that 
stop_run is not executed in draftmode, the subject of a postprocessing hook and that stop_run cannot be used for that purpose also came up on stackexchange. It might be a good idea to extend the documentation, I propose:

    8.5.3 stop_run
    function()
    end
    This callback replaces the code that prints LuaTEX’s statistics and ‘output written to’ messages.
    It is not executed in draftmode, and the output file is not complete at the point of execution.
    Thus you cannot use this callback to post process the output file.

> Anyway, managing your workflow can best be done with a wrapper (make was already suggested but many other solutions are possible).

Anything might be done using wrappers, but it's a pitty that some tasks currently need a wrapper. A few examples where a pdf_closed callback would be usefull:

  * I do not consider it to be good programming practice to remove temporary files that are still opened by the lualatex process, but I would like to remove those files from within the .sty file. [Ok, it is possible to remove files used by \includegraphics in the stop_run callback. They are still
    open, but they will not be used anymore and the library will probably silently handle the situation. But is this good programming practice?]
  * I take the pdf produced by *TeX, split it into pages and combine those pages and an audio recording to produce a final x.264 video. That could be done from within the .sty file, but with current luatex the best I can do is to write a script from within the style and typeout a message that tells
    the user to execute that script. [There is a hackish solution at the end of the mail]
  * If \includegraphics is used to include a lot of pdfs with embedded fonts the pdfs produced by luatex and other tex engines often produce big files that waste a lot of disk space because of duplicated font data. A solution is to include pdfs without embedded fonts and to post process the output
    with ghostscript. [There is a hackish solution at the end of the mail]

So there really would be reasonable use for a pdf_closed callback

    8.5.x pdf_closed
    function()
    end
    This callback is executed immediately after the output pdf has been finished and closed.
    It might be used topost process the output file.

In 2012 Taco Hoekwater wrote <http://tug.org/pipermail/luatex/2012-May/003648.html>:

    At this point I am not sure any more but there definitely is a use case
    for a callback that runs after the pdf has been closed already. I am not
    sure whether we should change stop_run or create a new callback.

> Pre- or postprocessing as part of the run is not part of the concept. What works for you can fail for someone else as timing is very application specific.

I don't understand your last sentence about timing, but I hope that you rethink about the implementation of an additional pdf_closed() callback.

Now here is the hackish solution to the problem that works on my system. I really don't like it, but it works here. Obviously it depends on the availability of a unix environment and the tools used, no error handling is implemented. The unfinished pdf is copied and fixed, mutool is used to obtain 
the correct xref offset. After that tmp.pdf should be identical to the final pdf and might be used as desired.

    \def\tmpScriptName{tmpfixpdf.sh}
    \newwrite\tmpScript
    \immediate\openout\tmpScript=\tmpScriptName
    \immediate\write\tmpScript{cp \jobname.pdf tmp.pdf}
    \immediate\write\tmpScript{echo endstream>> tmp.pdf}
    \immediate\write\tmpScript{echo endobj>> tmp.pdf}
    \immediate\write\tmpScript{echo startxref>> tmp.pdf}
    \immediate\write\tmpScript{\unexpanded{echo $((`mutool show tmp.pdf xref 2>/dev/null
                                                     | grep :
                                                     | tail -1
                                                     | sed -e 's/[[:digit:]]*: 0*\([[:digit:]]*\)
    [[:print:]]*/\1/'` + 1))
                                                     >> tmp.pdf}}
    \immediate\write\tmpScript{echo \%\%EOF>> tmp.pdf}
    \immediate\write\tmpScript{\unexpanded{echo -e "\nHave a look at tmp.pdf"}}
    \immediate\closeout\tmpScript

    \directlua {
       os.execute("chmod 700 \tmpScriptName")

       function my_stop_run()
         os.execute("./\tmpScriptName")
       end

       luatexbase.add_to_callback('stop_run', my_stop_run, 'TEST')
    }

I think is time to quote Hans Hagen: "so far my experience with tex is that there's always a solution" ;-)

Knut
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/luatex/attachments/20171212/02f46aad/attachment.html>