Press: A web-to-print pipeline for generating our document series August 2026
- Service: https://press.criticalinfralab.net/ (requires username and password)
- Code: https://codeberg.org/criticalinfralab/publication-pipeline
Press is our homegrown publication pipeline for generating the critical infrastructure lab document series. It is for writing plain text markdown sources and turning them into print-ready PDFs. In the spirit of *learning in the open*, we share the means of production behind it.
Bracketing the three research tracks that define the public identity of the critical infrastructure lab — i.e. standards, geopolitics and the environment — a fourth track has been just as significant for establishing a singular institution: and that is the lab itself as an infrastructure. As the lab was going to serve as an interface between academic, activist, and policy practices and knowledges, we felt that it needs its custom-crafted mode of disclosure, able to bridge cultural worlds and work for different audiences. We hope that our publication pipeline can fulfil such a purpose, as a key to unlock and connect multiple ways of knowing and doing, not just for the infralab, but for all who might need to travel between dimensions.
Our publication pipeline is an implementation made possible through free/libre web-to-print culture. It was originally created by Ulrike Uhlig, who composed a command-line toolchain primarily based on pandoc, which is still the core component of its inner workings, and is now maintained by Anders Aarvik and maxigas with a focus on usability and maintainability.
Focus on the everyday user
The pipeline, as many technical endeavours begin, was a tool that could only be used by people comfortable with the command-line and comfortable managing a vast amount of disparate software dependencies. The publication pipeline is an attempt to reflect, build and dream about the different scopes of interfaces, and thereby usability, that can make web-to-print usable for a wide range of backgrounds: to enable the user to dabble between the different interfaces, entrance points, and skillsets that each of the interfaces require.
Interfaces
Web interface
The web interface lets a wider range of users run the publication pipeline than those who prefer the command-line or the API. It includes a minimal file explorer for basic file management that extends functionality beyond the API. By navigating the web interface, you can list, view, create, delete, edit and render reports, upload images and markdown files, create directories, and edit files using a simple built-in markdown editor with a live preview.

Screenshot: web interface, 2026-07-26
CLI
For those who prefer working in a terminal, the publication pipeline includes a command-line interface (CLI). The CLI is a wrapper around the API and it sends the same requests under the hood, but lets you interact with the pipeline using shell commands instead of constructing HTTP requests, listing reports, listing the files within one, creating, rendering and deleting.
API
The web interface and the command-line interface do not handle report management directly. They communicate with the underlying API that does the work of creating and deleting reports, managing files, and invoking pandoc to render your markdown into PDFs. You can also call the API directly using any HTTP client, such as `curl`, a browser, or API-specific tools, which is useful for automation, scripting, or integrating the publication pipeline into other workflows.

Diagram: the three interfaces are means to the same end
Technical notes
The source code can be found on [Codeberg](https://codeberg.org/criticalinfralab/publication-pipeline), and the core architecture has been the same since the beginning. pandoc does conversion from Markdown to HTML, and WeasyPrint renders that HTML to PDF with CSS that can altered through the interface or your editor of choice. WeasyPrint is not reliant on a full browser engine but rather built from bits and pieces, thereby smaller, with fewer dependencies, and written in Python like the interfaces of our toolchain, avoiding introducing one more programming language into the pipeline, as well as enabling OS diversity as it can run on any OS with pandoc and a typical Python toolchain installed.
Whitebox adoption
It is possible to adapt the publication pipeline for your organisation, both in terms of the document output, but also the visual identity of the wider tooling such as the web interface itself. The document structure, series prefix, rendering quality, styling, the name and the logo, can be customised. The immediate advantages of running such a pipeline can be – depending on the use case ̣- economic [continous and autonomous production of design artefacts], privacy [run it on your own servers], collaborative [researchers, editors, programmers and designers can overlap on an equal footing to produce publications] and political [for the cause of decentralized and free/libre web-to-print culture and software].