speedataVersion 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.
Structuring layouts with the new Section element
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 benchmarked 6 PDF engines — the fastest is not the one I’d pick
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.
Fixing macOS notarization issues in the speedata Publisher 5.2.0
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).
@tajpulo is now talking about digital typesetting on the Grazer LinuxTage https://streaming.media.ccc.de/glt25/i1
#glt25 #digitalTypesetting #speedatapublisher
#glt25 #digitalTypesetting #speedatapublisher
🧊 freezr 🥶Standard interchange image format for Open Source DTP
Hi people,
with all the mayor GUI #DTP software reaching their peak: #GIMP, #Scribus and #Inkscape; and the well established #TeX software #ConTeXt and #SpeedataPublisher, and #ImageMagick we need a serious discussion about which image format we should adopt that works seamlessly across all these applications and it is generally accepted in the press workflow, whereas is embedded or not into a PDF file.
It should be something that has good quality, supports #CMYK and Alpha channels and it is #opensource friendly and perhaps an #openstandard.
I would dare to say that perhaps jpeg2000 matches most of them, it exists from a very long time and can be adopted as common ground, however it is need a combined effort, if what I am writing makes sense for you.
ImageMagick supports it, Gimp 3 currently doesn't, #LuaTeX and #LuaMetaTeX neither. I guess that Inkscape once it will be able to export in CMYK it will decide which format using to store images in CMYK with alpha into a PDF.
It would be very beneficial if we can adopt a format that works everywhere and it is press friendly, thanks.
Testing Gimp 3 Out...
I am testing #Gimp 3 out (#appimage) to see how I can integrate it in my new workflow.
The new #GEGL framework is much better of anything else, but still in rough shape, anyway I am totally impressed, potentially GEGL can do almost anything, now it is just a matter of time (and love 🥰).
Exporting in #JPG, #JXL and #TIFF in #CMYK is feasible although not so intuitive, however #ImageMagick was unable to convert the last two in PDF... I am on #Devuan stable which means #Debian stable, my #ImageMagick version might miss new features.
You can apply GEGL operations on a group and those are inherited by the sub-layers, and this is good and expected.
I had some confusion while exporting in grayscale. The soft proofing wasn't working even though active and the dialog would asked me to save in CMYK which doesn't make sense.
The whole topic about CMYK, besides Gimp itself, looks very confusing to me. I need CMYK because my software, for instance #SpeedataPublisher can't convert from RGB in CMYK. The purpose is because I need to go on offset printing and it is expected to prepare four plates for each colors (Cyan, Magenta, Yellow and Black[Y]); However I could need to go just black and white (grayscale) thus if I have already a grayscale image what is the purpose to export in CMYK? Nothing.
I would recommend to change this line to Press Output and to add more voices such as: Grayscale; CMYK; CMYK + Spot Colors.