speedata news

Version 5.4 released

Tue, 24 Feb 2026 10:00:00 +0100

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.

Speed

This version is noticeably faster. Several internal optimizations — grid allocation, paragraph post-processing, and general typesetting — add up to a real difference, especially for larger documents. There is also a new option html="off" on text elements to skip the HTML parser when you do not need it, which speeds things up further.

Letterspacing

You can now set letter spacing in <Textformat>. This has been requested a few times, especially for headings and display text.

Section element

A new <Section> element lets you group parts of your layout file. It does not affect the output — it is purely for organization. The new vscode-speedata extension uses it for code folding and outline navigation. More about this in the previous blog post.

HTML and CSS

Many improvements in this area:

Better table handling (borders, splitting, empty tables)
More list style types
Font family normalization
CSS font size setting via cssfontsize
Various border and color fixes

Bug fixes

Fix margin protrusion values
Fix infinite loops in HTML tables and paragraph post-processing
Fix ForAll context loss with the new XPath parser
Fix absolute positioning height calculation
Fix Until with new XPath mode
Set correct exit code when errors occur

VSCode extension

The new vscode-speedata extension replaces the older RedHat XML setup. It brings proper syntax support, validation, autocomplete, and the Section-based code folding mentioned above.

As always, downloads are at download.speedata.de. The detailed changelog is in the manual.

Structuring layouts with the new Section element

Mon, 23 Feb 2026 09:00:00 +0100

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.

The Section element

<Section> is a new element in the speedata Publisher layout language. It has one attribute: name. It wraps other elements. And that is all it does.

<Layout
    xmlns="urn:speedata.de:2009/publisher/en"
    xmlns:sd="urn:speedata:2009/publisher/functions/en">

  <Section name="Font definitions">
    <LoadFontfile ... />
    <DefineFontfamily ... />
  </Section>

  <Section name="Page types">
    <Pagetype name="default" test="true()">
      ...
    </Pagetype>
  </Section>

  <Section name="Data processing">
    <Record element="catalog">
      ...
    </Record>
  </Section>

</Layout>

The speedata Publisher simply ignores <Section> during processing. It does not create a scope, it does not affect variables, it does not change page handling or anything else. The PDF output is identical whether you use sections or not.

So why bother?

Code folding and outline

The real benefit shows up in the editor. The new vscode-speedata extension for Visual Studio Code understands <Section> elements and uses them for two things:

Code folding. You can collapse a section and hide everything inside it. When your layout has 2000 lines and you are working on the data processing part, you can fold away the font definitions, the page types, and whatever else you are not interested in right now.

Outline symbols. The VS Code outline panel (and the breadcrumb bar) shows your sections as a navigable tree. Instead of scrolling through the file looking for the right <Record> element, you click on “Data processing” in the outline and jump right there.

This is a small thing, but it makes a noticeable difference when you work with larger layouts. You spend less time navigating and more time actually editing.

The speedata-vscode extension

The Section support is part of the new vscode-speedata extension, which replaces the older RedHat XML mode. Besides sections, it brings proper syntax support, validation, and autocomplete for the speedata Publisher layout language. If you use VS Code for editing your layouts, it is worth installing.

Do I need to restructure my layouts?

No. <Section> is entirely optional. Existing layouts work exactly as before. You can add sections gradually, wherever you feel they help — or not at all. There is no performance cost and no behavioral change.

If you do want to add them, I would suggest starting with the obvious top-level groups: font definitions, page types, and record handlers. That alone gives you a nice outline and makes folding useful immediately.

The Section element is available in the current development version of the speedata Publisher. The vscode-speedata extension is available on the VS Code Marketplace.

I benchmarked 6 PDF engines — the fastest is not the one I’d pick

Tue, 10 Feb 2026 15:02:22 +0100

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 tested with 1 record and with 500 records. All templates produce more or less the same visual output. Same A4 page, same Helvetica (or the similar TeX Gyre Heros clone), same logo, same layout with the sender on the right side and body text at 105mm width with hyphenation turned on.

The tools:

speedata Publisher (sp) — my own engine, written in Go, Lua which uses LuaTeX in the background
Typst — the new kid, written in Rust, has native XML support
pdflatex — the classic, with Python/Jinja2 for the templating
LuaLaTeX — basically pdflatex but with Lua scripting and a more modern font system, also with Python/Jinja2
WeasyPrint — HTML/CSS to PDF, Python based
Apache FOP — the enterprise XML/XSL-FO thing, Java

All benchmarks ran with hyperfine on a macBook air M4 (16 GB). You can find the full setup on GitHub if you want to try it yourself.

The numbers

1 page

Tool	Time	Relative
sp	95 ms	1.0x
Typst	106 ms	1.1x
pdflatex	329 ms	3.5x
WeasyPrint	335 ms	3.5x
LuaLaTeX	519 ms	5.5x
Apache FOP	532 ms	5.6x

With one page, sp and Typst are basically the same. Both under 110ms. Everything else is 3.5 to 5.6 times slower.

500 pages

Tool	Time	Per page	Relative
Typst	157 ms	0.3 ms	1.0x
pdflatex	712 ms	1.4 ms	4.5x
Apache FOP	1.6 s	3.2 ms	10x
LuaLaTeX	2.4 s	4.7 ms	15x
sp	4.4 s	8.7 ms	28x
WeasyPrint	8.7 s	17.3 ms	55x

OK so this is where it gets interesting. Typst does 500 pages in 157 milliseconds. That is not a typo. Once it is running, it spends about 0.3ms per page. sp, which was basically equal at one page, needs 4.4 seconds — 28 times slower.

At one page they are tied, at 500 pages it is not even close. Typst has maybe 60ms startup cost, and after that it just flies. The per-page cost of sp is roughly 28 times higher.

Also worth noting: WeasyPrint really does not scale well. It goes from “ok” at one page to “maybe go get a coffee” at 500. pdflatex on the other hand scales surprisingly well — the per-page cost is only about 0.8ms if you subtract the startup.

So if speed is all you care about, just use Typst, right?

But look at the actual output

This is where it gets more complicated. Open the PDFs next to each other and look at the body text:

You see the difference? The justified text looks different. Not because of different fonts — the decisions are different. Where to break the lines, where to hyphenate, how to distribute the whitespace.

pdflatex and sp use algorithms based on Knuth & Plass (the TeX line breaking algorithm). They look at the whole paragraph at once and find the best set of breakpoints for all lines together. The result is even word spacing, no rivers of white, and good hyphenation.

~~Typst~~, WeasyPrint, and FOP seemingly use a much simpler algorithm. It looks like they go line by line from top to bottom and decide for each line separately. This is faster — and that is probably part of the reason why Typst scales so well. But you can see it. Some lines are too loose, some too tight. Hyphenation sometimes feels a bit random. Edit Typst’s author has clarified: “However, one thing we noticed is your assertion in the justification section that Typst is not using Knuth-Plass – we do, by default when justification is enabled. The only thing of the original paper we don’t implement are tightness classes to prevent a very tight line and a very wide line directly next to each other.”

For a simple letter, honestly both are fine. But try a narrow column with a technical text full of long words, and then you really see the difference. The Knuth-Plass output looks like a properly typeset book. The first-fit output looks like a web page that somebody printed.

A benchmark cannot capture this.

What benchmarks cannot measure

Here is what actually matters in production, and it has nothing to do with milliseconds: what happens when the content does not fit?

Think of a product catalog. Each product gets one page: a data table at the top, product photos at the bottom. Simple enough. But then product number 47 has a table with 30 rows instead of 10. Now what?

In Typst, you can use measure() to get the height of the table and compare it with the available space. That is a reasonable approximation. But Typst cannot do a real trial layout across page breaks — it measures content in a single frame only.

In the speedata Publisher, you can do this:

<SavePages name="attempt">
  <PlaceObject>
    <Table>...</Table>
  </PlaceObject>
</SavePages>

<Switch>
  <Case test="sd:number-of-pages('attempt') > 2">
    <!-- does not fit — shrink font, split differently, whatever -->
  </Case>
  <Otherwise>
    <InsertPages name="attempt"/>
  </Otherwise>
</Switch>

This is real trial typesetting. It actually lays out the full content, with real page breaks, counts how many pages it needs, and then you decide: keep it, or throw it away and try with different settings. No other tool in this benchmark can do that.

Is this slower than just going through the content without looking back? Of course. And maybe that is part of why sp is 28 times slower at 500 pages — it is built for careful layout, not for fast layout. But the alternative is that a human opens each PDF and manually checks if page 47 looks right. That is not a millisecond problem, that is a “you need to hire someone” problem.

A real-world example: the product catalog page

Here is an actual page from a spare parts catalog, built with the speedata Publisher. This is a very typical use case for a product catalog.

Look at what is happening on this page. The data table grows from top to bottom — model by model, row by row. The product images at the bottom grow from bottom to top, in rows of up to four. The table and the images share the same page, and neither is allowed to overlap the other. The number of table rows varies per page, the number of product images varies per page, and the layout has to figure out on its own how to divide the available space.

This is not a fixed template. It is an adaptive layout. The engine places the table, measures how much room is left, and fills the remaining space with as many product images as will fit — bottom-aligned, in rows of four. If a page has fewer products, you get two images in the last row instead of four. If the table is longer, the images get pushed to the next page. All of this happens automatically, without a human touching any page.

How would you do this with the other tools?

In Typst, you could get close. You would measure() the table height, calculate the remaining space, and manually arrange images in a grid at the bottom. But you are doing layout math by hand, and if the table happens to break across pages, things get complicated fast. Typst has no built-in way to say “fill the rest of this page from the bottom up.”

In pdflatex or LuaLaTeX, you enter the world of TeX float placement — \vfill, \bottomrule, maybe a minipage at the bottom. For a single page with a known table height, you could hack something together. But for hundreds of pages where the table height varies? You would likely write a Lua callback in LuaLaTeX that inspects the page after layout and inserts the images. Possible, but painful.

In WeasyPrint, this is essentially not possible. CSS has no concept of “fill the remaining page from the bottom.” You would have to pre-calculate the table height outside of the rendering engine and generate custom CSS per page. At that point, you are not really using a layout engine anymore — you are the layout engine.

In Apache FOP, XSL-FO has some support for this kind of thing with region-after and fo:block-container, but in practice FOP’s implementation is limited. You might get a rough approximation, but the automatic “grow from bottom” behavior is not something FOP handles well.

In the speedata Publisher, this is roughly a dozen lines of layout XML. Place the table, ask how much space is left, arrange the images in the remaining area. It is exactly the kind of problem the tool was built for.

The difficulty ladder

The real comparison is not “which tool is the fastest at a trivial task.” It is “which tool can even handle the task.”

Task	Typst	sp	WeasyPrint	FOP
Simple mail merge	fast	fast	medium	slow
Justified text quality	ok	excellent	ok	ok
“Does this fit on 2 pages?”	approximate	exact	no	no
Dynamic layout fallbacks	manual	built-in	no	limited
200-page product catalog with conditional layouts	in theory	core use case	no	sort of

For a mail merge, use Typst. Seriously. It is fast, the source files are nice to write, and the output looks good enough.

But once your layout needs go beyond “fill in a template, output PDF” — once you need the software to actually make decisions — things change. And that is where tools like sp become worth it, even if they need a few hundred milliseconds more per page.

What I actually learned

I went into this benchmark hoping that sp would be fastest at everything. It is not. Typst is 28 times faster at 500 pages, and I cannot really argue with that — they have done amazing engineering work.

But I also realized that the benchmark I set up — a simple mail merge — is exactly the kind of task where the strengths of sp do not show up at all. It is like you compare a sports car and a pickup truck on a flat highway. Sure, the sports car is faster. But that is not what you bought the truck for.

The right question is not “how many pages per second.” It is “how many pages until you need a human to check.” And that is much harder to measure.

The complete benchmark setup (all templates, scripts, and data) is on GitHub. Run ./benchmark.sh to reproduce on your own machine.

Fixing macOS notarization issues in the speedata Publisher 5.2.0

Mon, 24 Nov 2025 10:10:32 +0100

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).

The initial problem

The first hint that something was wrong came from a helpful macOS error message: the sp binary from the downloaded ZIP refused to run and macOS complained about signature / security issues.

At first glance, everything looked fine:

codesign -dv --verbose=4 bin/sp

showed a valid Developer ID Application signature with hardened runtime, the correct team identifier, and a recent timestamp. So far, so good.

However, Gatekeeper (the actual decision-maker on whether something is allowed to run) disagreed:

spctl -a -vvv bin/sp

returned:

bin/sp: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: PATRICK GUENTER GUNDLACH (3Y98DLKYBJ)

In other words: “Nice signature, but this binary (or rather the package it lives in) is not notarized. Rejected.”

The usual suspects: quarantine, signature, notarization

There are a few common reasons why macOS complains:

The file still has the quarantine attribute from the browser download:

xattr bin/sp
xattr -d com.apple.quarantine bin/sp

The binary is unsigned or only ad-hoc signed.
The binary is signed, but the archive is not notarized.
The wrong artifact was notarized (e.g. a different build or a different ZIP).

In my case, the binary itself was correctly signed. The problem appeared at the notarization step.

Looking at the notarization log

The key tool here is Apple’s notarization service and its logs.

I submitted my ZIP for notarization using:

xcrun notarytool submit speedata-publisher-macos-arm64-5.2.0.zip \
    --apple-id "..." \
    --team-id 3Y98DLKYBJ \
    --keychain-profile "..." \
    --wait

The result: status: Invalid – the archive contained “critical validation errors”.

The interesting part is in the JSON log, which looks roughly like this (simplified):

{
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "issues": [
    {
      "severity": "error",
      "path": "speedata-publisher-macos-arm64-5.2.0.zip/.../jline-2.14.6.jar/META-INF/native/osx/libjansi.jnilib",
      "message": "The binary is not signed.",
      "architecture": "x86_64"
    }
  ]
}

This is where the real debugging starts.

The important insight: Apple doesn’t just inspect your main executable (bin/sp), it walks through the whole archive and looks at every Mach-O binary it can find:

.dylib, .so, .jnilib, helper executables, and so on
even native libraries inside JAR files

If any of those are unsigned or signed incorrectly, notarization fails.

The unexpected culprit: `jline-2.14.6.jar`

One of the problematic paths stood out:

.../jline-2.14.6.jar/META-INF/native/osx/libjansi.jnilib

This is a native library (libjansi.jnilib) embedded inside the JLine 2 JAR, originally used by Saxon for its interactive “Gizmo” tool. It contained old macOS code and was not signed at all.

For the Publisher, I don’t actually need this library:

The Publisher uses Saxon for XML/XSLT processing.
The interactive JLine-based console is not part of the normal Publisher workflow.
Shipping that native library is therefore unnecessary.

Once I realized that, the simplest solution was: remove JLine from the macOS package.

That avoids the need to sign libjansi.jnilib at all, and it removes old native code that is irrelevant on modern macOS systems (especially on arm64).

Making sure the remaining binaries are signed

The notarization log also showed which other binaries Apple considers interesting in the archive, for example:

.../bin/sp
.../bin/sdluatex (a universal binary in my case)
.../share/lib/libsplib.so
.../share/lib/luaglue.so

All of these need a proper Developer ID Application signature.

Instead of manually calling codesign on every single file, I use gon to automate this. Gon lets you define a configuration file that lists:

which binaries to sign
which certificate to use
and how to submit the final ZIP for notarization

So the process for a macOS release looks like this now:

Build the binaries and shared libraries.
Run gon with my configuration:
- it calls codesign with hardened runtime and timestamp
- it signs all relevant Mach-O binaries
- it submits the ZIP to Apple for notarization
Wait for the notarization result from notarytool.

After removing JLine and letting gon sign all the relevant binaries, I rebuilt the ZIP and resubmitted it to Apple.

This time the log looked much nicer:

{
  "status": "Accepted",
  "statusSummary": "Ready for distribution",
  "ticketContents": [
    {
      "path": "speedata-publisher-macos-arm64-5.2.1.zip/.../bin/sp",
      "arch": "arm64"
    },
    {
      "path": "speedata-publisher-macos-arm64-5.2.1.zip/.../bin/sdluatex",
      "arch": "x86_64"
    },
    {
      "path": "speedata-publisher-macos-arm64-5.2.1.zip/.../bin/sdluatex",
      "arch": "arm64"
    },
    {
      "path": "speedata-publisher-macos-arm64-5.2.1.zip/.../share/lib/libsplib.so",
      "arch": "arm64"
    },
    {
      "path": "speedata-publisher-macos-arm64-5.2.1.zip/.../share/lib/luaglue.so",
      "arch": "arm64"
    }
  ]
}

“Accepted / Ready for distribution” is exactly what you want to see.

Final check with Gatekeeper

After downloading and unpacking the ZIP on a fresh system, the final sanity check is:

spctl -a -vvv speedata-publisher/bin/sp

Now the result is:

speedata-publisher/bin/sp: accepted
source=Notarized Developer ID
origin=Developer ID Application: PATRICK GUENTER GUNDLACH (3Y98DLKYBJ)

At that point, macOS is happy and the package is ready to be used without scary warnings.

Summary

For macOS users of the speedata Publisher:

The macOS package is now 5.2.1 and properly notarized.
Windows and Linux stay at 5.2.0 for this release.
The changes are purely about:
- removing an unnecessary native library (JLine / libjansi.jnilib), and
- making sure all relevant Mach-O binaries are correctly signed and notarized.

For anyone fighting similar issues:

codesign -dv --verbose=4 helps you inspect signatures.
spctl -a -vvv tells you what Gatekeeper thinks.
xcrun notarytool submit ... --wait plus the JSON log tell you exactly which file is causing notarization to fail.
Using a tool like gon makes it much easier to consistently sign and notarize all the right files.

And sometimes the best fix is not to sign more, but to ship less.

Version 5.2 released

Tue, 14 Oct 2025 14:41:48 +0200

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.

We’ve also added a comprehensive set of automated tests to ensure the parser behaves consistently across all edge cases. This rewrite lays the foundation for future extensions such as XML entity support and better error recovery.

Smarter XPath Engine

XPath support has grown significantly:

New functions: translate() and distinct-values()
Improved numeric functions like format-number() and round-half-to-even()
The doc() function now returns the document node, aligning better with the XPath standard
More consistent boolean logic across the board

This means fewer surprises and more predictable results when working with complex expressions.

Typographic and Language Support

We’ve added initial Japanese typesetting support, refined character fallback logic, and improved handling of multi-character glyphs. These changes improve the Publisher’s internationalization capabilities and text layout quality — especially for multilingual projects.

Better HTML and CSS Handling

The internal HTML/CSS engine continues to evolve:

Support for pseudo-class selectors (like :first-child, :last-child)
Improved border and padding calculations in tables and blocks
list-style-position: inside|outside now supported
font-family accepts multiple fallback fonts
Better behavior with custom @font-face and relative font sizes (rem, px)

These refinements bring the output closer to what designers expect from modern HTML/CSS rendering.

Polished PDF Output

PDF metadata has been updated to use ISO-formatted dates, and new metadata fields such as Producer and default color profiles have been added automatically. These subtle improvements help ensure better interoperability with other PDF tools and workflows.

Reliability, Logging & Maintenance

You’ll notice better diagnostic information throughout:

More descriptive log messages
Multi-run jobs now continue even when earlier runs fail (useful for large builds)
Safer handling of file attachments and image conversions
Additional debugging details for developers and power users

Under the hood, we also performed many small cleanups and documentation improvements to make the Publisher more maintainable in the long run.

What’s Next

We’re already working on the next big milestones:

Rewrite of the dynamic Go runtime library in Rust — this will remove the last remaining cgo dependency, improving performance and portability.
More unit testing and refactoring to keep the core stable and future-proof.
Speed improvements across XML, XPath, and rendering.
Extended HTML/CSS support for modern layout features.
More XPath functions to make data processing even more powerful.

Thank You

A big thanks to everyone using and testing the speedata Publisher! Your feedback and real-world examples help guide our development and make the tool better every day.

If you’d like to follow ongoing work, check out the GitHub repository — and as always, happy publishing!

billingcat – invoicing software powered by the speedata Publisher

Tue, 07 Oct 2025 13:17:04 +0200

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.

What is billingcat?

billingcat is an open-source project that combines two essential tasks for freelancers and small businesses: creating invoices (including ZUGFeRD support) and managing customer data in a lightweight CRM.

The project is currently in the alpha stage and only available in German, but already allows users to create invoices, manage clients, and use their own letterheads for invoices.

Screenshot billingcat dashboard

Connection to the speedata Publisher

Under the hood, billingcat uses the speedata Publisher to generate ZUGFeRD-compliant PDF/A invoices. The Publisher handles the PDF generation, embedding of XML data, and layout rendering.

In the future, billingcat will also use the Publisher for other PDF outputs to take full advantage of its layout and automation features while keeping a simple web-based interface for end users.

Screenshot example invoice

Looking ahead

billingcat is still in its early stages, but the feedback from the first alpha testers has already been very encouraging. For me, this project is also a great example of how the speedata Publisher can be integrated into other systems to produce high-quality document output – even as part of modern web applications.

In an upcoming post, I plan to write about a brand-new feature in billingcat: the Letterhead Editor. It allows users to design their own letterheads and upload custom font files, making it possible to generate personalized layouts without additional coding effort.

High speed PDF generation with boxes and glue

Tue, 27 May 2025 08:28:23 +0200

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:

You need an XML file that contains the invoice data. This is usually generated by an accounting software. This must be conformant to the ZUGFeRD XML schema (EN 16931-1).
Attach the XML to the generated PDF.
Create a visual representation of the invoice data in the PDF.

There is an example of the script at GitHub. Get the software as described on https://github.com/boxesandglue/cli and run

bag main.rsr

Which generates a file out0.pdf from the sample zugferd.xml file.

The console output is something like

Define font family (name=text,id=0)
Load image (filename=img/logo.pdf)
Load font (filename=../../fonts/crimsonpro/CrimsonPro-Regular.ttf)
Load font (filename=../../fonts/crimsonpro/CrimsonPro-Bold.ttf)
Add attachment (filename=factur-x.xml)
Write image to PDF (filename=img/logo.pdf)
Write font to PDF (filename=../../fonts/crimsonpro/CrimsonPro-Regular.ttf,psname=CrimsonPro-Regular)
Write font to PDF (filename=../../fonts/crimsonpro/CrimsonPro-Bold.ttf,psname=CrimsonPro-Bold)
Output written (filename=out0.pdf,bytes=28073)
finished in 26.91ms

27 milliseconds (on my 2021 MacBook Pro) for a PDF is not bad, I guess. This includes loading fonts and the PDF logo, parsing the XML file and writing the PDF, subsetting and including fonts and attaching the XML file.

The 27 milliseconds include some startup time, so let me check what happens when I run the script 1000 times (set maxdocuments in the script to 1000):

...
finished in 14224.74ms

This is about 14 milliseconds for one document or approximately 70 documents per second.

Version 5 Released

Wed, 12 Mar 2025 14:43:15 +0100

Almost five years after releasing version 4.0 of the speedata Publisher, it is time for version 5.0. This is a short announcement, since most changes have been covered before.

The speedata Publisher looks the same since its beginning, but there have been major changes under the hood since version 4:

Integration of HarfBuzz for left to right and right to left text layout, even mixed (bidirectional) typesetting. Support for all kinds of fonts and font features.
Full accessibility support.
A rewritten XML and XPath 2.0 parser.
Attachment of ZUGFeRD invoices.
Greatly enhance enhance various subsystems such as HTML, MetaPost integration and paragraph builder.
SAAS available with the speedata Pro plan.

There have been a few entries here in the blog (4.16, 4.18, 4.20)

Some statistics:

There are 246 black box tests to check that all existing layouts keep working as before. This is 132 more than in version 4.
A bit more than 220 development releases and 10 stable releases between 4.0 and 5.0
906 commits since 4.0
Git stat tells me: 989 files changed, 66328 insertions, 18099 deletions
More than 250 closed bug reports.

This would not be possible without all the bug reports and helpful comments from the users. So thank you very much!

speedata Publisher and AI

Mon, 03 Feb 2025 20:58:20 +0100

Don’t worry, the speedata Publisher will not gain any half-baked, annoying artificial intelligence features. This post is about chatting with some of the more famous AI chats (ChatGPT, Google Gemini, DeepSeek). I have tried to find out how good these AI chats know the speedata Publisher and if they can help users to generate a layout.

There is still a long road ahead, but read on. A big warning upfront: None the following outputs work. Do not use them. I post abbreviated transcripts of the chats.

Table of contents:

Chat GPT

me: Do you know the speedata Publisher?

ChatGPT: Yes! Speedata Publisher is an open-source automated publishing system designed for high-volume and complex document generation, especially for structured data like catalogs, financial reports, and technical documents. It uses XML and Lua to define document layouts and logic, making it highly customizable for professional publishing needs.

It’s particularly useful when you need precise typography and layout control, similar to tools like TeX or InDesign scripting, but optimized for structured data.

Are you considering using it for a project?

me: can you generate a simple layout for the speedata publisher just printing a “hello chatgpt”?

ChatGPT: Sure! Here’s a simple Speedata Publisher layout file that prints “Hello ChatGPT” on a page. Save this as an XML file and run it with Speedata Publisher.

<?xml version="1.0" encoding="utf-8"?>
<document xmlns="https://www.speedata.de/2012/publisher/en">
    <setup>
        <pagelayout name="mainlayout">
            <positioningarea width="210mm" height="297mm">
                <text top="50mm" left="50mm" fontsize="20pt">
                    Hello ChatGPT
                </text>
            </positioningarea>
        </pagelayout>
    </setup>

    <record>
        <page>
            <usepagelayout name="mainlayout"/>
        </page>
    </record>
</document>

Explanation:

Defines a page layout (mainlayout) of A4 size.
Places “Hello ChatGPT” at 50mm from the top and left.
Creates a record that generates a page using the defined layout.

Would you like to extend this with styles, different fonts, or dynamic content? 🚀

me: The speedata Publisher needs a data file, can you show it to me as well?

ChatGPT: You’re absolutely right! Speedata Publisher requires a data file along with the layout. Here’s a minimal data file to use with the previous layout:

data.xml

<?xml version="1.0" encoding="utf-8"?>
<data>
    <text>Hello ChatGPT</text>
</data>

Updated Layout File (layout.xml)

Now, let’s modify the layout to fetch data dynamically instead of hardcoding the text:

<?xml version="1.0" encoding="utf-8"?>
<document xmlns="https://www.speedata.de/2012/publisher/en">
    <setup>
        <pagelayout name="mainlayout">
            <positioningarea width="210mm" height="297mm">
                <text top="50mm" left="50mm" fontsize="20pt">
                    <value select="text"/>
                </text>
            </positioningarea>
        </pagelayout>
    </setup>

    <record element="data">
        <page>
            <usepagelayout name="mainlayout"/>
        </page>
    </record>
</document>

How it Works:

data.xml contains the text inside a <text> element.
The layout file dynamically fetches the text using <value select="text"/>.
When you run Speedata Publisher with both files, it will output “Hello ChatGPT”.

…

Google Gemini

me: do you know the speedata Publisher?

Gemini: Yes, I do!

Speedata Publisher is a powerful and versatile typesetting software that’s particularly well-suited for creating complex documents with a high degree of automation. It’s known for its ability to handle large volumes of data and produce professional-quality output.

Here’s what I know about Speedata Publisher:

[…]

I’m ready to assist you further! Just let me know what you’d like to know.

me: can you generate a simple layout for the speedata publisher just printing a “hello gemini”?

Gemini:

<?xml version="1.0" encoding="UTF-8"?>
<document xmlns="http://speedata.org/2021/03/speedata">
  <layout>
    <page>
      <frame x="1cm" y="1cm" width="10cm" height="2cm">
        <text>Hello Gemini</text>
      </frame>
    </page>
  </layout>
</document>

Explanation:

<?xml version="1.0" encoding="UTF-8"?>: Standard XML declaration.
<document xmlns="http://speedata.org/2021/03/speedata">: The root element, declaring the Speedata namespace. This is crucial.
<layout>: Contains the layout definition.
<page>: Defines a single page. You can have multiple <page> elements for multi-page documents.
<frame x="1cm" y="1cm" width="10cm" height="2cm">: Defines a rectangular area on the page.
- x and y attributes specify the top-left corner’s position (1cm from the left and 1cm from the top).
- width and height define the dimensions of the frame.
<text>Hello Gemini</text>: The content to be printed within the frame.

How to use this:

Save: Save this code as an XML file (e.g., hello.xml).
Run Speedata: Open a terminal or command prompt and navigate to the directory where you saved the file. Then, run Speedata Publisher using the command: speedata hello.xml
This will generate a PDF file (usually named hello.pdf) containing your “Hello Gemini” text.

Key improvements and considerations:

Namespace: The xmlns attribute in the <document> tag is essential for Speedata to understand the XML structure.
Units: Using units like cm (centimeters) is good practice for defining sizes and positions. Speedata supports various units (mm, in, pt, etc.).
Frame: The <frame> element is important for positioning content precisely. Without it, the text might be placed at the default position.
Error Handling: If you encounter errors, double-check the XML syntax and make sure Speedata is installed correctly. The command-line output will often provide clues about the problem. This example provides a very basic layout. Speedata Publisher is capable of much more complex layouts with sophisticated formatting, data integration, and conditional rules. If you have more specific layout requirements, let me know, and I’ll do my best to help you create the appropriate Speedata code.

DeepSeek

me: do you know the speedata publisher?

DeepSeek: Yes, Speedata Publisher is a specialized software tool designed for automated typesetting and layout generation, particularly for complex documents like catalogs, directories, and price lists. It uses a data-driven approach, allowing users to define layouts through XML or JSON data and templates. This makes it highly efficient for handling large datasets and generating consistent, high-quality layouts.

Key features of Speedata Publisher include:

[…]

me: can you generate a simple layout for the speedata publisher just printing a “hello deepseek”?

DeepSeek: Certainly! Below is a simple example of how you can create a layout in Speedata Publisher to print “Hello Deepseek”. This example assumes you have a basic understanding of XML and how Speedata Publisher works. Step 1: Create the Data File (data.xml) This file contains the data you want to display in your layout.

<?xml version="1.0" encoding="UTF-8"?>
<data>
    <message>Hello Deepseek</message>
</data>

Step 2: Create the Layout File (layout.xml) This file defines the layout and how the data should be displayed.

<?xml version="1.0" encoding="UTF-8"?>
<Layout xmlns="urn:speedata.de:2009/publisher/en"
        xmlns:sd="urn:speedata:2009/publisher/functions/en">

    <!-- Define a page template -->
    <Pageformat width="210mm" height="297mm" /> <!-- A4 size -->
    <DefinePage name="main" width="210mm" height="297mm">
        <PlaceObject column="1" row="1">
            <Textblock>
                <Paragraph>
                    <Value select="/data/message" /> <!-- Insert the message from the data file -->
                </Paragraph>
            </Textblock>
        </PlaceObject>
    </DefinePage>

    <!-- Start the layout with the "main" page -->
    <Record element="data">
        <ClearPage />
        <UsePage name="main" />
    </Record>
</Layout>

Step 3: Run Speedata Publisher

To generate the PDF, run the Speedata Publisher command with the data and layout files:

sp data.xml layout.xml

This will produce a PDF file with “Hello Deepseek” printed on an A4-sized page. Explanation:

data.xml: Contains the message “Hello Deepseek” in a structured format.
layout.xml: Defines the layout, including the page size (A4) and where the message should be placed (column 1, row 1).
Speedata Command: The sp command processes the data and layout files to generate the PDF.

Conclusion

The correct answer would be something like this:

The data.xml file:

<data>Hello world!</data>

and the layout file (layout.xml)

<Layout
  xmlns="urn:speedata.de:2009/publisher/en"
  xmlns:sd="urn:speedata:2009/publisher/functions/en">

  <Record element="data">
    <PlaceObject>
      <Textblock>
        <Paragraph>
          <Value select="."/>
        </Paragraph>
      </Textblock>
    </PlaceObject>
  </Record>
</Layout>

and to run the speedata Publisher, just call sp on the command line.

To be honest: all three chat AI gave really bad answers. The ChatGPT and the Gemini answers were totally useless, the DeepSeek AI gave a bit better answer, at least it outputs some commands that are actually part of the speedata Publisher layout language.

I know that the speedata Publisher is a niche product where you cannot find many examples on the web. So it is hard for the limited AI data models to output anything useful. I was impressed by DeepSeek that it outputs at least a few sensible speedata Publisher commands. I should re-visit the chats in a few years and update this blog entry.

Electronic invoices

Tue, 21 Jan 2025 11:34:52 +0100

The following text is written from a German perspective. This should apply to all parts of the European Union, although with likely differences in other countries.

Since the beginning of 2025, all companies in Germany have had to send and receive electronic invoices (with overriding deadlines and a few exceptions). This affects me too, so I asked myself (out of curiosity), what is an electronic invoice and how can I process it?

E-invoice

An e-invoice is defined in the EN 16931 standard. This consists of several parts:

the first part of the standard describes in general terms how an invoice must be structured. For example, a seller must be specified, the types of VAT are defined and the necessary and optional contents of an invoice are described. There is also a series of (business) rules that check the semantic validity of an invoice.
The second part consists of an analysis of various existing XML standards with regard to compatibility with the first part of the standard. The result of this analysis is that there are two allowed XML standards: CII and UBL (which are two different standards but have the same roots).
the third part describes an assignment of the invoice terms to the XML elements of the CII or UBL implementations.

ZUGFeRD and Factur-X / CII

The German ZUGFeRD and the French Factur-X are identical standards that are based on CII (cross industry invoice). These are hybrid formats that have a human-readable and a machine-readable part, implemented as a PDF document with an XML attachment. The invoice visible in the PDF is also saved as XML in the attachment:

UBL

UBL based invoices (Universal Busines Language, defined in ISO 19845 by OASIS) is a different approach to electronic invoicing. Many countries have ULB based invoices (or a subset of it), for example Denmark has OIOUBL, Norways EHF and you can find many more such examples.

In Germany, UBL based invoices are popular in government agencies, not so much among b2b invoices.

XRechnung

There is yet another invoicing standard in Germany which might lead to confusion. The XRechnung standard is based on both ZUGFeRD CII and UBL format. It also defines some further business rules which are important for government agencies.

Peppol

Peppol (Pan-European Public Procurement OnLine) is a set of applications which includes electronic invoicing (based on the UBL standard). Many countries around the world implement the Peppol standard, see the country profiles list on peppol.org.

Other Countries

There are several sites on the internet that show the standards for electronic invoicing regulations for a lot of countries around the world, for example the page at edicomgroup.com/electronic-invoicing.

ZUGFeRD (and UBL based) XML

How does an XML for the ZUGFeRD/Factur-X format look like? This is described in detail in the documentation which can be downloaded from ferd-net. ZUGFeRD comes in several “conformance levels” (profiles), the EN16931 level should be used for electronic invoices. There are some examples at https://github.com/ZUGFeRD/corpus/tree/master/XML-Rechnung/CII. See the other directories for UBL based invoices.

Attaching an electronic invoice to a PDF

The ZUGFeRD format is (as described) a PDF with an attached XML. The PDF must conform to the PDF/A-3 standard and also include some special metadata. Both are described in the ZUGFeRD documentation.

Attaching a ZUGFeRD invoice with the speedata Publisher is very easy. Just call <AttachFile> with the type ZUGFeRD invoice and the speedata Publisher does the rest automatically. See the

<AttachFile description="Electronic invoice"
            type="ZUGFeRD invoice"
            filename="invoice.pdf" />

Development

I have setup the site erechnung.berlin (in German) mainly for my own purposes to check and visualize ZUGFeRD files and to show a hierarchical list of all allowed XML elements and their cardinality. The checker uses a Go library to read the XML file and is implemented as a WASM program, so it runs in the browser and does not transfer any data to a server.

Conclusion

The whole topic “e-invoices” looks complicated, but once the sender and the receiver have setup a process for these XML files, many new applications for automation can be developed. As a simple example, the banking account number and the due payable amount are stored in well known fields, so you might be able to drop an electronic invoice on the banking software which creates a money transfer template for you.

Release stable version 4.20

Wed, 15 Jan 2025 13:00:01 +0100

After more than half a year, 150 commits and 40 minor releases, I have now published version 4.20, which is hopefully the last stable version before the “big five”.

As always, old document should run without any changes. You might have to switch on compatibility modes with --xpath=lxpath and --option fontloader=fontforge on the command line, but in most cases, the new defaults should not change your document output

There are some major enhancements compared to the previous stable version (4.18):

Fully accessible documents (PDF/UA)
XPath parser now well tested and with more functionality
ZUGFeRD attachment compatible with version 2.0

And some minor enhancements

Spot color saturation
Ability to flip (mirror) objects
Derived glyphs now copy-able in HarfBuzz mode
PDF/A-3 selectable as an output format
Font sizes and shift for superscript and subscript can be configured
Inner and outer margins in Pagetype
New strategy for NoBreak: reduce=fontfit
Font expansion setting configurable

Fully accessible documents (PDF/UA)

You can now create accessible PDF documents in a fully automatic workflow. You need to define the roles of each element (“this is a heading…”) and take care of the correct order of the elements in the PDF. The PAC (PDF accessibility checker) is very happy with the PDFs that come out of the speedata Publisher. There is a whole section in the documentation dedicated to PDF/UA output.

XPath parser (lxpath)

The (not so) new (anymore) Lua XPath 2.0 parser has been thoroughly tested and is now recommended for all new projects. It can be set into a strict namespace mode which makes it easy to work with mixed namespace data.

It also handles variables more consistent than before.

ZUGFeRD attachments

ZUGFeRD (electronic invoices, also known as Factur-X in France) have got an overhaul. The file name of the attached file is now factur-x.xml for version 2. The PDF/A-3 conformance has also improved by writing output intents for CMYK colors (configurable) and a few other minor improvements.

You can download the version 4.20 as always at https://download.speedata.de. Enjoy!

Creating PDF with JavaScript

Mon, 14 Oct 2024 12:33:55 +0200

I have created JavaScript bindings for boxes and glue. These bindings are made with goja. Let me show you an example:

const bag = require("bag:backend/bag")
const fe = require("bag:frontend")


const f = fe.new("out.pdf")

const str = `In olden times when wishing still helped one,
there lived a king whose daughters were all beautiful;
and the youngest was so beautiful that the sun itself,
which has seen so much, was astonished whenever it shone
in her face. Close by the king’s castle lay a great dark
forest, and under an old lime-tree in the forest was a well,
and when the day was very warm, the king’s child went out
into the forest and sat down by the side of the cool
fountain; and when she was bored she took a golden ball,
and threw it up on high and caught it; and this ball was her
favorite plaything.`.replace(/\s+/g, ' ').trim()

const fontsource = new fe.fontSource(
    { location: "CrimsonPro-Regular.ttf"}
    );
const ff = f.newFontFamily("text");
ff.addMember(fontsource, fe.fontWeight400, fe.fontStyleNormal);
const para = fe.newText();

para.settings[fe.settingSize] = 12 * bag.factor;
para.items.push(str);

const ret = f.formatParagraph(
    para,
    bag.mustSP("125pt"),
    fe.leading(14 * bag.factor),
    fe.family(ff));

const p = f.doc.newPage();
p.outputAt(bag.mustSP("1cm"), bag.mustSP("26cm"), ret[0]);
p.shipout();
f.doc.finish();

Which look familiar when you know at the “getting started” document in the manual.

Tun run the JavaScript file above, you need to download the software ets (see the Readme file in the repository), download the font and run

ets myfile.js

on the command line.

This produces two files (hopefully): a PDF file (out.pdf in this case) and a log file (ets-protocol.xml) which contains information about errors and warning, in case something goes wrong.

The JavaScript bindings are documented at boxesandglue.dev/ets/. Examples are found in a repository.

Currently ets is at version 0.0.2, you can conclude from that version number that this is still in the beginning of development. My next steps are including input and output of regular files, a JSON and XML reader as well as http-bindings to access assets without download.

New XPath variables semantics

Tue, 03 Sep 2024 20:21:36 +0200

Something that was a bit inconsistent for a while is variable assignments of element structures.

Take this snippet for example:

<SetVariable variable="myvar">
	<Element name="Foo">
		<Attribute name="attr" select="'foo1'"/>
	</Element>
	<Element name="Bar">
		<Attribute name="attr" select="'bar1'"/>
	</Element>
</SetVariable>

Now, what exactly is the contents of $myvar? With the old XPath parser, this used to be a table with two entries (two elements). But inconsistent: Both count($myvar) and count($myvar/Foo) return 2, which is incorrect in both cases.

From now on (the new XPath parser) tries to stay as close as possible to the XPath / XSLT standards. count($myvar) now returns 1 (the XML fragment) and count($myvar/Foo) returns 1 (the element node Foo), and count($myvar/*) returns 2 (all element nodes in the fragment $myvar).

This would be the equivalent in XSLT:

<xsl:variable name="myvar">
  <Foo attr="foo2" />
  <Bar attr="bar1" />
</xsl:variable>

<xsl:message select="count($myvar)" />
<xsl:message select="count($myvar/Foo)" />
<xsl:message select="count($myvar/*)" />

which prints out the messages 1, 1 and 2, as expected.

This looks a bit hair-splitting, but has quite a few consequences, which have incompatible backwards behavior.

Breaking backwards compatibility

Breaking backwards compatibility is something I really try to avoid, but in this case I cannot see a way around it. The good news is that you can always switch to the old behavior by setting xpath=luxor in the configuration file. And for new projects, you will have a much more sensible setup.

Show me the pitfalls

Every time you access a variable that has a data structure (constructed with <Element> and <Attribute> commands), you need to have an explicit node selector.

All commands that use the attributes select and test are affected. See the index example in the GitHub repository. It now has

<Makeindex select="$indexentries/indexentry"  ...

instead of

<Makeindex select="$indexentries"  ...

Explanation: the variable $indexentries is constructed as follows (in a loop):

<SetVariable variable="indexentries">
	<Copy-of select="$indexentries" />
	<Element name="indexentry">
		<Attribute name="name" select="@word" />
		<Attribute name="page" select="@page" />
	</Element>
</SetVariable>

so it is an XML fragment containing several nodes of type element. To get all of these elements, an explicit selection of $indexentries/indexentry is necessary.

Also <ProcessNode select="$index" /> has been changed to <ProcessNode select="$index/index" /> because the former just selects the (unnamed) XML fragment and the latter selects a sequence of elements which gets processed individually.

A bit surprisingly comes <Copy-of>, although it is not a special case.

<SetVariable variable="myvar">
	<Element name="Foo">
		<Attribute name="attr" select="'foo1'"/>
	</Element>
	<Element name="Bar">
		<Attribute name="attr" select="'bar1'"/>
	</Element>
</SetVariable>

<SetVariable variable="myvar2">
	<Copy-of select="$myvar" />
	<Element name="Foo">
		<Attribute name="attr" select="'foo2'"/>
	</Element>
</SetVariable>

The variable $myvar2 now contains a copy of $myvar and an additional element Foo. You could also explicitly select the desired nodes:

<SetVariable variable="myvar2">
	<Copy-of select="$myvar/Foo" />
	<Element name="Foo">
		<Attribute name="attr" select="'foo2'"/>
	</Element>
</SetVariable>

Both ways ($myvar and $myvar/Foo) work. The first expression, which selects the whole fragment, works by copying the contents of the fragment to the result sequence, and the second expression explicitly selects the two elements which are copied to the result sequence.

Summary

If you have an old layout, you can keep using it by selecting the old XPath parser. If you use the new XPath parser, make sure you update your code if you use the <Element> and <Attribute> commands.

Microtypography and font expansion

Thu, 11 Jul 2024 12:38:01 +0200

The speedata Publisher is built on top of LuaTeX, a typesetting software with a strong focus on typography. Therefore it inherits all the possibilities offered by the layout engine. One of the older features is the ability to stretch or shrink glyph widths on demand to allow even better line breaking.

TeX already uses the famous line breaking algorithm that optimizes the appearance of a full paragraph as a whole, not a line-by-line approach that might lead to large inter-word spacing.

The ability to stretch or shrink glyphs by a little amount can lead to many more possible line breaks and thus enhancing the overall visual outcome of a paragraph. The famous Gutenberg 42 line bible (B42) has a similar approach to line breaking.

The speedata Publisher by default uses a little percentage to stretch or shrink glyphs. This helps text in narrow columns to be typeset nicely.

The speedata Publisher

As mentioned above, the speedata Publisher turns on font expansion by default. The option fontexpansion is used to control this behavior:

<Options fontexpansion="yes" />

The allowed settings are:

no: All characters retain the width specified by the font designer.
some: The line break is carried out with the original widths, after the break the characters can be changed slightly in width so that the spaces between the words are slightly reduced.
yes: (default setting) The paragraph break is tried out with different character widths and then the best result is used.

To see the effect of some, here is a German text that is typeset with none (left) and some (middle) and a comparison of both (right), where the green text is identical to the middle example. German texts are known to have long words…

Text typeset with font expansion off (left), some (middle) and a comparison (right)

The result of yes is more drastic. Many more possible line breaks can be considered if words can be squeezed a little to fit in to a line or stretched so the inter word spacing would be a little smaller. See the following figure. With fontexpansion="yes" you have to experiment a little to determine a good degree of stretching and compression so that the paragraphs also look “good”. On the left, fontexpansion is set to no, for the other two to yes. The paragraph on the right is set with the values 5% stretch and 3% compress (50 and 30 for fontstretch and fontshrink).

Text typeset with font expansion no (left) and yes (middle and right). The text to the right has higher values for stretching and shrinking.

You can influence the values either on a font basis or via the global <Options> command.

fontstretch: Specifies the percentage by which the characters may be stretched. Specification is in 0.1 per cent: a value of 20 means 2%. The default setting is 40 (= 4%).
fontshrink: Like fontstretch, only as an indication of the compression. The default setting is 30 (= 3%).
fontstep: The steps in which the wrapping algorithm "tries out" the stretching or compression. The default setting is 10.

These settings are also available for <LoadFontfile> (without the font prefix), but beware that the settings must be the same for all fonts in a paragraph.

speedata Publisher and accessibility

Mon, 17 Jun 2024 09:28:42 +0200

Version 4.19.8 has a completely written module for creating tagged PDF for accessibility.

First, you need to set the output format to PDF/UA with

<PDFOptions format="PDF/UA" />

Tagged PDF also needs an outline of the structure of the document. See the previous blog entry for more details on tagged PDF. To summarize: you create an description of what is visible in the PDF. Each visible part gets tagged with a structure type (“this is a label for a table of contents link”, “this is a heading” and so on).

The new command <StructureElement> in the speedata Publisher adds an entry to a hierarchical list. For example

<StructureElement role="Document">
	<StructureElement role="Sect">
		<StructureElement role="Art" />
		<StructureElement role="Art" />
	</StructureElement>
	<StructureElement role="Sect">
		<StructureElement role="Art" />
		<StructureElement role="Art" />
	</StructureElement>
</StructureElement>

creates two sections in document, each section contains two articles. To add text or images to a structure part, you need to create a unique id for entry, for example:

<StructureElement role="Document">
	<StructureElement role="Sect">
		<StructureElement role="Art" id="s1a1" />
		<StructureElement role="Art" id="s1a2" />
	</StructureElement>
	<StructureElement role="Sect">
		<StructureElement role="Art" id="s2a1"  />
		<StructureElement role="Art" id="s2a2"  />
	</StructureElement>
</StructureElement>

and add contents to the structure, for example:

<PlaceObject>
	<Textblock>
		<Paragraph role="H1" parent="s1a1">
			<Value>A short story</Value>
		</Paragraph>
		<Paragraph role="P" parent="s1a1">
			<Value select="sd:dummytext()" />
		</Paragraph>
	</Textblock>
</PlaceObject>

This adds a level 1 heading and a paragraph to the first article in the first section (id s1a1).

The document has the following outline:

Dynamic structure elements.

Depending on the data, you may not be able to predict the structure elements. Therefore you can add a child entry to a parent when you pass a parent id:

<StructureElement role="Document" id="doc" />

<StructureElement role="Sect" id="s1" parent="doc" />
<StructureElement role="Sect" id="s2" parent="doc" />

<StructureElement role="Art" id="s1a1" parent="s1" />
<StructureElement role="Art" id="s1a2" parent="s1" />
<StructureElement role="Art" id="s2a1" parent="s2" />
<StructureElement role="Art" id="s2a2" parent="s2" />

This is equivalent to the example at the beginning.

Defaults

The speedata Publisher starts with a default root element:

<StructureElement role="Document" id="doc" />

and the default parent of each element that is placed in the PDF is doc, so each element is a direct child of the document, unless you provide a different structure.

speedata news

Version 5.4 released

Speed

Letterspacing

Section element

HTML and CSS

Bug fixes

VSCode extension

Structuring layouts with the new Section element

The Section element

Code folding and outline

The speedata-vscode extension

Do I need to restructure my layouts?

I benchmarked 6 PDF engines — the fastest is not the one I’d pick

The setup

The numbers

1 page

500 pages

But look at the actual output

What benchmarks cannot measure

A real-world example: the product catalog page

The difficulty ladder

What I actually learned

Fixing macOS notarization issues in the speedata Publisher 5.2.0

The initial problem

The usual suspects: quarantine, signature, notarization

Looking at the notarization log

The unexpected culprit: jline-2.14.6.jar

Making sure the remaining binaries are signed

Final check with Gatekeeper

Summary

Version 5.2 released

Big Improvements Under the Hood

Rewritten XML Parser

Smarter XPath Engine

Typographic and Language Support

Better HTML and CSS Handling

Polished PDF Output

Reliability, Logging & Maintenance

What’s Next

Thank You

billingcat – invoicing software powered by the speedata Publisher

What is billingcat?

Connection to the speedata Publisher

Looking ahead

High speed PDF generation with boxes and glue

Version 5 Released

speedata Publisher and AI

Chat GPT

Google Gemini

DeepSeek

Conclusion

Electronic invoices

E-invoice

ZUGFeRD and Factur-X / CII

UBL

XRechnung

Peppol

Other Countries

ZUGFeRD (and UBL based) XML

Attaching an electronic invoice to a PDF

Development

Conclusion

Release stable version 4.20

Fully accessible documents (PDF/UA)

XPath parser (lxpath)

ZUGFeRD attachments

Creating PDF with JavaScript

New XPath variables semantics

Breaking backwards compatibility

Show me the pitfalls

Summary

Microtypography and font expansion

The speedata Publisher

speedata Publisher and accessibility

Dynamic structure elements.

Defaults

The unexpected culprit: `jline-2.14.6.jar`