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
