The speedata Publisher has now more verbose change logs. With the new documentation, I add a summary line, a more detailed description and, if possible, links to related commits. Hopefully this makes it easier to see what has changed. See
https://doc.speedata.de/publisher/en/manual/changelog/version-5/
for example.
If nobody complains, I will remove the deb packages from the distribution. The ZIP file is (and will be) the preferred way to download the package.
I have moved the documentation from asciidoctor to markdown (using Hugo instead of a self-created static site generator). Also, reorganized the structure and fixed a lot of wording.
It now builds in less than a second and has live preview, which makes it much nicer to edit..
Version 5.5.2 released. Enhanced PDF/UA accessibility and fixed a few bugs.
Download at https://download.speedata.de
Version 5.4 released!
from the news.md file (vs 5.2):
* Massive speed improvements!
* More unit testing and refactoring
* More HTML/CSS support
* More XPath functions
* Section element to structure layout
* New VScode extension (separate repository)
* Fix margin protrusion (also harfbuzz mode)
* Letterspacing
There is a new (optional) <Section> element for structuring the speedata layout.xml file. It does not produce a different output.
See https://news.speedata.de/2026/02/23/section-element/ for details.
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.
Massive speed improvements. The last benchmarking led me to reworking the code and I got some major improvements:
1m25 seconds for a 1828 pages catalog (previously 5 minutes)
32 seconds for a bible (719 pages Arabic), previously 47 secons.
Identical output.
Version 5.3.22
Typst does 500 pages in 157 milliseconds. My own engine needs 4.4 seconds. So why would anyone use the slower tool?
Because "how many pages per second" is the wrong question. The right question is "how many pages until you need a human to check."
I wrote up the full benchmark with 6 PDF engines: https://news.speedata.de/2026/02/10/typesetting-benchmark/
#speedatapublisher #typst #fop #TeXLaTeX #weasyprint #benchmark
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’ve switched off GitHub sponsorship on my profile for the moment.
Thanks a ton for your generous support of speedata Publisher. Don’t worry: the build machine keeps humming, and development stays steady. 🙂
New blog post on https://news.speedata.de/2025/11/24/macossigningerror/:
I rebuilt the macOS packages of the speedata Publisher and fixed some tricky notarization/signing issues.
macOS is now at 5.2.1, Windows/Linux stay at 5.2.0.
If you’re interested in macOS notarization for CLI tools, this one’s for you.
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).
speedata