[Dev-luatex] Feature request: busy pdf
Jérôme LAURENS
jerome.laurens at u-bourgogne.fr
Thu Apr 7 21:30:03 CEST 2022
Yes, this does work on a per document basis, but what I request is a builtin feature that simply applies out of the box and is backwards compatible.
> Le 7 avr. 2022 à 14:32, luigi scarso <luigi.scarso at gmail.com> a écrit :
>
>
>
> On Thu, Apr 7, 2022 at 12:10 PM Jérôme LAURENS <jerome.laurens at u-bourgogne.fr <mailto:jerome.laurens at u-bourgogne.fr>> wrote:
> New CLI options --busy related to typesetting
>
> luatex --busy=0
> default behavior, nothing new
> luatex --busy=1
> Instead of writing the pdf output to jobname.pdf, write to jobname.pdf(busy)
> At the end remove any jobname.pdf and move jobname.pdf(busy) to jobname.pdf
> luatex --busy=2 foo.tex
> If there is a jobname.pdf(busy) bail out with a diagnostic message « typesetting already in progress »
> Otherwise do like --busy=1
>
> Actually, the pdf is removed at the start of the typesetting process such that it is no longer available during that whole time.
> When the typesetting is a bit long, it is not practical at all. For continuous typesetting neither.
> Considering that we work in general on the end of a document, the first pages will not change a lot but are no longer available.
>
> synctex already supports this « busy » busyness such that the previous .synctex file is available during next typesetting process.
>
>
> hm, perhaps you can process the command line as below
>
> \directlua{print(); print("===========================");
> for k,v in pairs(arg) do print(k,v) end;
> print("===========================");
> }
> hi
> \bye
>
> and use the wrapup_run callback .
>
> --
> luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ntg.nl/pipermail/dev-luatex/attachments/20220407/16705d06/attachment.htm>
More information about the dev-luatex
mailing list