PDF Export Consistency Matters More Than It Sounds

Today Continuum reached an important usability milestone: PDF exports now work consistently across all supported build types instead of depending entirely on one rendering engine. This sounds small on the surface, but it represents something much larger about portability, durability, and local-first software design.
PDF Export Consistency Matters More Than It Sounds

Andrew G. Stanton - Monday, May 18, 2026


A surprisingly large amount of software assumes the environment will always behave perfectly.

The right dependencies. The right OS libraries. The right runtime. The right package manager. The right container image.

But reality does not work that way.

Especially when building local-first software.

Today Continuum improved PDF export support so that it now works consistently across all build types.

If WeasyPrint is available, Continuum uses it (that was what I used initially in the docker builds but it requires additional os dependencies. Weasyprint will NOT work in a pure python environment.

If it is not available, exports still function using the fallback renderer instead of silently disabling the feature.

That sounds like a tiny implementation detail.

It is not.

One of the goals of Continuum is portability across environments:

  • native desktop builds
  • Docker deployments
  • local Python installs
  • partially offline systems
  • constrained environments
  • future sovereign hardware setups

A feature that only works “under ideal conditions” is not truly portable.

This became especially obvious while testing different builds and environments.

Some systems had WeasyPrint available immediately. Others did not. Some builds lacked the necessary rendering dependencies entirely.

The easy solution would have been:

“Disable PDF export unless WeasyPrint exists.” (which is what I had done in the native and local builds)

But that approach quietly shifts control back to the environment.

Instead, the export flow was redesigned so PDF generation remains available everywhere.

Higher quality rendering when possible (in docker builds) Graceful fallback when not.

That principle matters far beyond PDF generation.

The same philosophy increasingly shapes Continuum itself:

  • authorship should work offline
  • signing should work locally
  • identities should remain portable
  • exports should remain durable
  • backups should remain usable
  • workflows should degrade gracefully

A sovereign system cannot depend entirely on ideal infrastructure.

It must continue functioning even when conditions are imperfect.

That does not mean every environment will look identical.

It means the core capability survives.

This is one of the reasons I continue emphasizing the distinction between:

  • local keys
  • and local-first authorship

Those are not automatically the same thing.

Many applications technically store keys locally while still making authorship dependent on network availability, cloud APIs, or external services.

Continuum keeps moving in the opposite direction.

The environment should support the user. The user should not become dependent on the environment.

Even a “minor” feature like PDF export reveals that philosophy in practice.


Write a comment
No comments yet.