Skip to content

history.md

Latest commit

 

History

History
80 lines (59 loc) · 3.62 KB

history.md

File metadata and controls

80 lines (59 loc) · 3.62 KB
title History & Future
navTitle History & Future
section More
order 1
description Project background and roadmap

History

texd came to life because I've built dozens of Rails applications, which all needed to build PDF documents in one form or another (from recipes, to invoices, order confirmations, reports and technical documentation). Each server basically needed a local TeX installation (weighing in at several 100 MB, up to several GB). Compiling many LaTeX documents also became a bottleneck for applications running on otherwise modest hardware (or cloud VMs), as this process is also computationally expensive.

Over time I've considered using alternatives for PDF generation (Prawn, HexaPDF, gofpdf, SILE, iText PDF, to name but a few), and found that the quality of the rendered PDF is far inferior to the ones generated by LaTeX. Other times, the licensing costs were astronomical, or the library didn't support some layouting feature, or the library was in an early alpha stage or already abandoned...

I'll admit that writing TeX templates for commercial settings is a special kind of pain-inducing form of art. But looking back at using LaTeX for now over a decade, I still feel it's worth it.

Future

One item on the wishlist is asynchronous rendering: Consider rendering monthly invoices on the first of each month; depending on the amount of customers/contracts/invoice positions, this can easily mean you need to render a few thousand PDF documents.

Usually, the PDF generation is not time critical, i.e. it should finish in a reasonable amount of time (say, within the next 6h to ensure timely delivery to the customer via email). For this to work, the client could provide a callback URL to which texd sends the PDF via HTTP POST when the rendering is finished.

Of course, this will also increase complexity on both sides: The client must be network-reachable itself, and keep track of rendering requests in order to associate the PDF to the correct invoice; texd on the other hand would need a priority queue (processing async documents only if no sync documents are enqueued), and it would need to store the callback URL.

Related work

Of course, this project was not created in a void, other solutions exist as well:

  • latexcgi, MIT license, GitHub project, Website

    Project description:

    The TeXLive.net server (formally known as (LaTeX CGI server) (currently running at texlive.net) accepts LaTeX documents via an HTTP POST request and returns a PDF document or log file in the case of error.

    It is written as a perl script accepting the post requests via cgi-bin access in an apache HTTP server.

  • Overleaf, AGPL-3.0 license, GitHub project, Website

    Project description:

    Overleaf is an open-source online real-time collaborative LaTeX editor. We run a hosted version at www.overleaf.com, but you can also run your own local version, and contribute to the development of Overleaf.

  • overleaf/clsi, AGPL-3.0 license, GitHub project

    Project description:

    A web api for compiling LaTeX documents in the cloud

    The Common LaTeX Service Interface (CLSI) provides a RESTful interface to traditional LaTeX tools (or, more generally, any command line tool for composing marked-up documents into a display format such as PDF or HTML).