[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