search

raphaelreyna / latte

Programatic document generation as a HTTP service. Render PDFs using LaTeX templates and JSON.
MIT License
210 stars 14 forks source link

Feature proposal - multiple compilations of the same document #14

Closed maxiride closed 3 years ago

maxiride commented 3 years ago

TL;DR

As with any open source project I'd like to hear an opinion on [1] if the idea is of @raphaelreyna interest and [2] if this is the case how to proceed.

For the purpose, at the moment, I've brainstormed two paths:

The first path IMHO is the easiest as it would imply to repeat compile N times by wrapping it in a for loop.

The second path, while it seems to be more efficient as it automagically takes in account the iteration to perform it could have unpleasant surprises that would arise with time.

Personally I'd lean towards the first option, LaTTe after all is a tool thought for one template injected with different details each time. I don't see it as a tool meant for documents with bibliographies for instance. So the less impactful approach is better IMHO.

Personal thoughts: this idea comes from a personal need, I use the dapper-invoice latex template to make invoices, being a freelancer software developer myself I already have tools to log my work time and I thought it would be awesome to partially automate the invoice making by separating the template form the data itself. However, the latex document needs to be compiled a couple of times for a proper rendering of its elements.

raphaelreyna commented 3 years ago

I've been looking into latexmk and like that its a mature project that can hanlde a lot of edge cases automatically; however like you said, it could lead to surprises and would become yet another dependency.

Forcing N recompiles definitely works; however I dont think its the most elegant solution since it puts more work on the users of LaTTe since they'll have to think about how many compilations are needed. That said, it would be a great feature to have for those who want it.

I like the idea of going for both solutions: LaTTe should default to using latexmk (if its available) and also accept a compilation count integer value in the JSON for a generate request. If the user provided a compilation count, LaTTe will use pdflatex/pdftex instead of latexmk.

Ideally, it would be awesome to give LaTTe the abillity to detect the need for a recompile without relying on an external tool like latexmk. However, I've never looked into how latexmk detects this and it may actually be way more work than I'm thinking.

I'd love to hear any thoughts on this.

maxiride commented 3 years ago

I like the idea of going for both solutions: LaTTe should default to using latexmk (if its available) and also accept a compilation count integer value in the JSON for a generate request. If the user provided a compilation count, LaTTe will use pdflatex/pdftex instead of latexmk.

I'm unsure if defaulting to latexmk is a good idea, at the moment I don't have any fact or reasoning to provide, just a gut feeling. Nonetheless, I agree that having the choice on which engine to use\compilation count is a better approach, hence it might be a good occasion to address #7 too.

What about two new fields in the input JSON:

  1. A compilation count
  2. The typesetting engine to use

With this hypothetical logic:

Ideally, it would be awesome to give LaTTe the abillity to detect the need for a recompile without relying on an external tool like latexmk. However, I've never looked into how latexmk detects this and it may actually be way more work than I'm thinking.

The perl script is freely accessible, however it might not be this easy to port this feature.

however I dont think its the most elegant solution since it puts more work on the users of LaTTe since they'll have to think about how many compilations are needed.

I recognize that a fully automated process would be completely transparent to the end user, however, the use-case for this feature is definitively a niche and I reasonably expect that only more technical users will ever need it, hence I don't think that having to thinker on what engine to use or how many iterations to perform would be a hassle.

Let me know your thoughts!

raphaelreyna commented 3 years ago

I like the idea of adding a JSON field for selecting the typesetting engine. If this field gets added I think it would be a good idea to add a new route for users to query LaTTe for the available engines.

I'm on the fence about defaulting to using latexmk. The way I see it, if LaTTe finds latexmk it's most likely because the user installed and is already using latexmk (or wishes to use latexmk for LaTTe in the case of containers); I think LaTTe should try to fit into whatever environment the user places it into.

I'd be interested to hear your thoughts on this. Either way, I think a flag should definitely be added for users/admins to set the default engine (on top of the JSON field for end users to set the engine).

I'm on board with the logic you laid out regarding engine / recompilation count.

Also, I quickly looked into how latexmk works in regards to detecting the need to recompile. It seems that it just searches through the log file after each compile for variations on 'recompile/rerun' (re-compile,Recompile, etc), since every LaTeX package seems to define its own recompile message. Should be pretty doable.

gyllenfrans commented 3 years ago

Oh yeah! I'm very much looking forward to this feature in LaTTe.

raphaelreyna commented 3 years ago

Aplogies for the delay -- I was working on a free-lance job and that took up a lot of time. Theres a new branch called 'options' for this issue/feature.

maxiride commented 3 years ago

Aplogies for the delay -- I was working on a free-lance job and that took up a lot of time. Theres a new branch called 'options' for this issue/feature.

I'll fork from there and see what I can do in the spare time to contribute =)