I have been writing the speedata Publisher manual for almost 17 years now, pretty much since the first lines of code in 2009. And from the beginning, completeness was the goal: every command documented, every attribute explained, every concept covered somewhere. Over the years the manual grew into hundreds of pages, in German and English, and whenever a user asked something that was not in there, that was a bug to me — the answer went in.

And yet, for all those years, a nagging feeling never quite went away. The manual told you everything about the Publisher. But it did not really tell you how to write a layout.

A lot of what I do with the speedata Publisher ends up as accessible PDF. PDF/UA-1 is a common customer requirement, and the Publisher has been producing tagged PDFs for a while now. So I spend more time than I would like to admit checking PDFs for accessibility compliance.

Version 5.6 of the speedata Publisher is out. The last stable release (5.4) was at the end of February, so it has been about 100 days of work, 25 small patch releases in between, and quite a few new things. Get a coffee, there is a lot in this one.

Version 5.4 of the speedata Publisher is now available. This is a solid update with speed improvements, better HTML support, and a few nice additions. Here is what changed since 5.2.

Layout files in the speedata Publisher can get long. Really long. A product catalog with conditional page types, fallback logic, index generation, and a dozen different record types easily grows to a few hundred lines of XML. And at that point, scrolling through the file becomes a chore.

I have been wanting a way to organize layout code into logical groups for a while — something like regions or sections that you can collapse and navigate. The problem: any new element in the layout language usually does something. It affects the output, it changes behavior, it needs to be documented and tested and maintained.

So I added an element that does nothing.

I’m building a typesetting engine for a living (speedata Publisher). People keep asking me “why not just use Typst?” or “isn’t WeasyPrint good enough?” and I never had a good answer with real numbers. Just gut feeling. So I decided to actually measure it.

I set up a simple benchmark, same document with all six tools. And what I learned was maybe not what I expected.

The setup

The task is simple: a mail merge. You have an XML file with name and address records, you fill in a letter template, and you get a PDF out. One page per letter, with a logo, sender info, recipient address, and some body text. Nothing special, really every tool should be able to do this.

I have rebuilt the macOS packages of the speedata Publisher and released them as version 5.2.1. The Windows and Linux packages remain at 5.2.0, because the changes are macOS-specific.

This post is a short write-up of what broke, how I debugged it, and which tools I used along the way. If you ever need to get a macOS command line tool notarized, this might save you some time (or at least a bit of frustration).

Big Improvements Under the Hood

We’re happy to announce a new development snapshot of the speedata Publisher! This release comes with major internal improvements, cleaner architecture, and a bunch of small but meaningful user-facing enhancements.

Rewritten XML Parser

The XML parser has been completely reimplemented in Go, with a stronger focus on correctness, performance, and test coverage. It now keeps track of the originating file when using XInclude, which makes debugging and error reporting much easier.

It has been a while since my last post on this blog. This time I would like to introduce a project that is a bit different in scope but technically closely related to the speedata Publisher: billingcat – an open-source application for invoicing and simple customer relationship management.

This article is not up to date anymore, I will leave it online. Risor is not supported anymore Lua is now the choice of scripting language. I will post a follow-up soon.

I have been playing with electronic invoices (especially the German and French ZUGFeRD/Factur-X format) for a while now. The speedata Publisher has support for ZUGFeRD since 2017.

The next step is to make (my other PDF generation software) boxes and glue work with electronic invoices. For that, I use the new command line interface for boxes and glue (which I will describe in a future blog post).

There only a few things that need to be done to make this work: