[passerine]

I can relate quite well to the author's pursuit in tinkering with their typesetting workflow. When I wrote my bachelor's thesis, I also spent a great deal of time coming up with a custom LaTeX template and workflow. Like the author, one of the pain-points was the relatively slow edit-compile-review cycle of modern LaTeX engines like LuaLaTex.

In my case, I was mainly concerned with making the resulting thesis.pdf PDF/A compliant. PDF/A is a archival compliance standard that's dedicated to the long term digital preservation of PDF files.

Predictably, I got way too carried away as well, and ended up trying to create fully-reproducible LaTeX PDFs as well. It was probably overkill for my use-case, but it did result in a fun blog post where I documented the process [1]

[1] https://shen.hong.io/reproducible-pdfa-compliant-latex/

[nicce]

> Like the author, one of the pain-points was the relatively slow edit-compile-review cycle of modern LaTeX engines like LuaLaTex.

This depends a lot. In most of the cases delay is only about 1 second on modern PCs. A bit more when you cite and build the document twice.

You can use LaTeX in many different ways. There are built-in editors and web services such as Overleaf. In the end, they all use the same workflow or dependencies for building the document, but might add an additonal delay.

I too have ended up tweaking my environment a lot. I ended up testing almost every LaTeX workflow.

I finally ended up for just using vim and zathura. Optimised docker image with LuaLatex builds the document. Second favorite would be LaTeX plugin for Jetbrains products. Overleaf is only good for collaborating.

On my desktop pc which has 16 CPU cores, there is only very little latency when compiling. But for text editing, it is a bit rare that you need such PC…

[passerine]

> This depends a lot. In most of the cases delay is only about 1 second on modern PCs. A bit more when you cite and build the document twice.

I agree that for many (or even most) documents, LaTeX's compilation delay is generally manageable. However, when it comes to documents with bibliography management, footnotes, margin-notes, and multiple figures, the compilation delay can get quite high.

In my own experience, I had a document of notes containing over a hundred citations managed by biblatex and bibmla [1]. It also had footnotes and margin-notes, requiring an additional repaint. The compilation time on that document was well over several seconds on my laptop, up to dozens of seconds when on battery-power.

> I finally ended up for just using vim and zathura. Optimised docker image with LuaLatex builds the document. Second favorite would be LaTeX plugin for Jetbrains products. Overleaf is only good for collaborating.

I'm very curious to hear about the docker image that you are using. What purpose does the docker image serve in the build pipeline? I know that for compiled software, sometimes having a build environment allows you to better define the environment variables, but to my understanding this is not a worry for LaTeX.

[1] https://github.com/ShenZhouHong/sartre-notes

[nicce]

> I'm very curious to hear about the docker image that you are using. What purpose does the docker image serve in the build pipeline? I know that for compiled software, sometimes having a build environment allows you to better define the environment variables, but to my understanding this is not a worry for LaTeX.

Using Docker brings several benefits. I allows me to share the same build environment for multiple different machines. I can even use my desktop remotely for building the documents if I want, just by sharing Docker Daemon.

Sometimes some package breaks after an update, and Docker allows me to roll back to working environment. I also can declare additional packages and fonts deterministically if I need them. Overall, LaTeX is quite complicated and huge system, and I rather keep it away from my host machine. Maybe Docker is a bit overkill, but I have never wasted time on fighting with package conflicts or installing Latex once again with extra packages for different machine.

[yockyrr]

Surely PDF/A can be created just by passing any PDF through Ghostscript with the right flags such as -dPDFA and -sPDFACompatibilityPolicy=1 ?

[passerine]

I don't have any experience with using Ghostscript as a post-processing step, and I am curious to know if it works well for complex documents.

LaTeX does have a native way of generating PDF-A compliant documents, using the pdf-x package. It's still in beta, but it is quite stable and works very well. The advantage of enforcing PDF-A compliance using native LaTeX is that it allows you to take the further step of implementing reproducible builds. Once that is done, you can be certain that given a LaTeX source file, you will be able to generate a bit-for-bit identical document.

Additional post-processing steps will have to be at least documented, and will probably tie the output on the specific version of your post-processor.