# Future-Proof Formats for Technical Content and Page Design

I've been working on desktop publishing, design and technical documents since the early 80s, so you can imagine how many times I've lost and found old documents, a few happily recovered, but too often either corrupted or orphaned by obsolete software. Think of those spoiled TIFF images, or a QuarkXPress document you can no longer edit. This panic on document loss has kept me focused for years on future-proofing my work, or anyone else's document collection.

## Premise

With the previous context in mind, a format would qualify as future-proof only if it meets all of:

1. **Text-based or markup** — a plain-text serialization exists, even if a binary artifact is also produced (XML derivatives count).
2. **Documented standard** — a published specification ("white book") plus at least one conformant, independent implementation, so the format doesn't die with a single vendor.
3. **Single-binary preference** — a self-contained compiler/interpreter beats a modular toolchain with a package manager and transitive dependencies. Typst is preferred over LaTeX, Rust/Go tooling over Node/npm stacks.
4. **Graceful failure** — if the processor disappears, the *source* should still be readable and re-implementable by a human, not just re-parseable by another program. Considering this premise, we can see how Markdown degrades better than HTML; also Typst source degrades better than compiled SVG.

We are doing this study on three different layers:

* The **structured data** layer, which doesn't have a predefined order or composition
* The **authoring** layer, containing ordered information such as a sequential text with a semantic structure, or a specific graphic composition
* The deliverable or **layout** layer, including the previous parts, and the post-processing rules for print or electronic publishing.

While layers define the final purpose, or stages before delivery, territories define the nature or internal structure of documents. Each territory is owned by a chosen format, and this format belongs to its specific territory.

We're exposing our chosen formats in reverse layer hierarchy, starting from the layout formats. Chosen formats are not necessarily the best existing format, feature-wise or by any other specification, but the one qualifying best in the 4 previous rules.

## Layout formats

| Format | Spec / reference | Processor | Territory | Weak at | If the tool disappears |
|---|---|---|---|---|---|
| **Typst** | Typst's own published syntax reference + open compiler source | `typst` binary (Rust, single executable) | Typesetting, page layout, long-document structure with precise control | Free-form illustration; not a drawing tool | Source (`.typ`) is plain markup, readable and re-implementable; single implementation today is the main risk, mitigated by an open spec |
| **Scribus** | `.sla` is a documented XML schema | Scribus (Qt/C++, single app) | WYSIWYG desktop publishing, repetitive layouts (newsletters, forms, brochures) | Precise typesetting logic, programmatic/repeatable builds | `.sla` survives as XML even without Scribus, but re-editing without the GUI is hard — layout-by-coordinates isn't hand-writable the way Typst markup is |
| **SVG** | W3C SVG spec | Any conformant renderer (browsers, Inkscape, resvg, librsvg) | Standalone one-page deliverables where shape carries the layout — flyers, cards, stationery | Long text, running page layout, typographic control | Source is XML, human-legible, but hand-editing paths/transforms is impractical without a GUI |

**Typst.** Owns the document. Where LaTeX would traditionally sit, but compiled by a single Rust binary instead of a TeX distribution plus package manager. Strong at programmatic layout (templates, repeatable structure, citations, cross-references) with a syntax that's actually pleasant to hand-write and diff in git — which matters for the "legible if abandoned" criterion, since a `.typ` file is closer to Markdown-with-superpowers than to LaTeX's macro soup.

**Scribus.** Owns the case Typst is bad at: layouts driven by *placement*, not *flow* — a page where a photo, a pull-quote, and three text blocks all need to sit in exact visual relationships that don't derive from a logical document structure. That's a WYSIWYG problem, not a typesetting problem, and Typst deliberately doesn't try to solve it. Scribus is the right tool exactly because it's a canvas with frames rather than a compiler with a layout algorithm — but that means it can't be scripted/repeated as cleanly as Typst can for a document template.

**SVG / Inkscape.** Owns anything where shape, not text flow, is the content. Considering it a layout format, that would apply to flyers or one-page business documents (cards, stationery). It technically supports `<text>` and even multi-line flow via `<flowRoot>` (Inkscape-specific, non-standard), but there's no real notion of pagination, running headers, footnotes, or reflow — it's a canvas, not a document. Use it for the graphic, not the page. This format can both be considered in the deliverable or authoring layer, depending on the structure and scope of the overall design (see below).

## Authoring formats

| Format | Spec / reference | Processor | Territory | Weak at | If the tool disappears |
|---|---|---|---|---|---|
| **SVG** | W3C SVG spec | Any conformant renderer (browsers, Inkscape, resvg, librsvg) | A component feeding a larger document — diagrams, icons, illustration, logos meant to be embedded, not read on their own | Long text, running page layout, typographic control | Source is XML, human-legible, but hand-editing paths/transforms is impractical without a GUI |
| **Markdown** | CommonMark spec | Any of dozens of independent parsers | Authoring content and structure, when final design is outsourced elsewhere | No layout or typographic control at all — by design | Near-zero risk: it's already the most degraded, most legible state a document can be in |

**SVG / Inkscape, here.** The distinction from the layout-layer row above is the destination: a diagram or icon authored to be embedded in a Typst document or Scribus frame belongs here; a standalone one-page piece that *is* the finished deliverable belongs in the layout table.

**Markdown.** Owns the raw content — the writing itself — whenever the final visual form is somebody else's problem, or a later step in the pipeline. It's the natural interchange point: content gets written once in Markdown, then either compiled to a document via Typst (for typeset output) or hand-placed into Scribus frames (for WYSIWYG collateral), or converted straight to SVG-embedded text for illustration captions. \
Other excellent formats like reST and AsciiDoc are excluded by the same criteria that admit Markdown: equally legible, but their practical processing paths — Sphinx, Asciidoctor/Ruby — pull in exactly the modular-dependency weight rule 3 rules out. They're not disqualified on legibility; they're disqualified on toolchain weight.

## Decision guide

- **Is the deliverable a document meant to be read start to finish** (report, article, book, normativa)? → **Typst**.
- **Is the deliverable a fixed visual composition where position matters more than flow** (flyer, one-off form, repeated-template newsletter)? → **Scribus**.
- **Is the deliverable a standalone graphic, icon, or diagram**, with at most short embedded labels? → **SVG**.
- **Is this step just "write the content," with layout to be decided or outsourced later**? → **Markdown**, then route into one of the above.

## How they compose

Typst, Scribus, SVG, and Markdown span the layout and authoring layers above, and they aren't really competitors — they chain:

- **Markdown** (content) →
- **Typst** (layout/typeset) → PDF/print
- **Scribus** frames (manual WYSIWYG placement)
- **SVG** (standalone graphics) → embedded into either Typst or Scribus

Markdown is the durable authoring layer; Typst and Scribus are the two layout engines, split by whether the layout is *rule-driven* (Typst) or *placement-driven* (Scribus); SVG is the graphics layer that either can consume.

## Structured data

Tables, citations, hierarchized records, and indexes aren't competitors to the four formats above — they're a layer that feeds into them. None of the four represent raw structured data on their own terms; they consume or display it.

| Format | Spec / reference | Processor | Territory | Weak at | If the tool disappears |
|---|---|---|---|---|---|
| **CSV** | RFC 4180 (informational, not prescriptive — real-world CSV is a family of dialects) | any parser or spreadsheet | flat tabular records | hierarchy, typed fields | already at maximum legibility — nothing to degrade to |
| **TOML** | formal, versioned spec | any conformant parser | shallow, config-shaped hierarchized records | deep/arbitrary nesting | plain text, unambiguous, safely hand-editable |
| **YAML** | YAML 1.2 spec | any conformant parser; native to Typst via Hayagriva | deep hierarchized records; citations | implicit typing ambiguity ("Norway problem") | plain text, but re-editing needs care around ambiguity |
| **BibTeX / Hayagriva** | BibTeX's de facto grammar / Typst's Hayagriva spec | Typst natively, or biber/bibtex for LaTeX-legacy pipelines | citations | verbose (BibTeX) or young (Hayagriva) | text-based either way, always parseable |

**Indexes fall off the grid.** A page index is *derived* by whichever layout engine (Typst or Scribus) computes final positions — it's an output of the typesetting step, not an independent source format to pick.

**Practical routing:**
- Flat records you'll bulk-edit in a spreadsheet → CSV, even for a lightweight tree (a `parent_id` column keeps it flat and spreadsheet-editable, trading elegance for bulk-editability).
- A one-off, genuinely nested structure a human authors directly → YAML if it needs to feed Typst's bibliography anyway (one less format to hold in your head); TOML if it's closer to config and correctness matters more than depth.
- Citations → Hayagriva/YAML by default in a Typst pipeline; BibTeX only if the same source must also serve a LaTeX-legacy path.

**Concrete case — genealogical records.** This is the real-world instance of the hierarchized-record trade-off above, playing out between two actual standards: **GEDCOM** is the broad-interoperability choice — text-based (its own line/level tag syntax rather than XML, but text-based regardless), a documented spec stewarded by FamilySearch, and readable/writable by nearly every genealogy tool in existence, at the cost of historic ambiguity across vendor dialects (largely tightened by GEDCOM 7). **Gramps XML** is the upgrade path when precision outweighs breadth: a properly documented XML schema that preserves the fuller research model — sources, citations, notes, media references — losslessly, at the cost of a narrower, closer-to-single-implementation profile, structurally the same trade-off as Typst against a wider LaTeX ecosystem, or Hayagriva against BibTeX.

**Neither CSV nor GEDCOM are as narrow as their usual context suggests, which matters for keeping this list short:**

- CSV's territory isn't "generic tabular data," it's *any* vertical whose specialist tools already round-trip through it — geo/mapping (point data: GPS tracks, sensor readings, geocoded addresses all interchange as lat/long columns), biotech lab instrument exports, and survey/statistical data all treat CSV as their common denominator for flat records. Real geometry — polygons, lines, multi-part features — needs its own format, and it's worth naming explicitly: **GeoJSON**, not the more entrenched Shapefile. GeoJSON is plain JSON text with a proper published standard (RFC 7946) and near-universal GIS/web-mapping support, and it degrades exactly the way this document rewards — readable and salvageable by eye. Shapefile is more entrenched in professional GIS practice and its technical spec is public too, but it fails the same two rules InDesign failed: the geometry itself (`.shp`) is raw binary, not text, and the format is fragile by design — split across three-plus sidecar files (`.shp`, `.dbf`, `.shx`, `.prj`), where losing just the `.prj` means the projection is gone with no way to recover it from what's left. Wide adoption doesn't offset either weakness here.
- GEDCOM's territory isn't strictly human genealogy either. Animal pedigree software genuinely imports/exports it (Pedigree Viewer, used in livestock breeding programs, is a real example) — that one's a natural fit since the underlying shape is identical. Enterprise org charts and abstract relation diagrams fit less naturally: GEDCOM's schema bakes in genealogical semantics (`INDI`, `FAM`, birth/death events), so reusing it there means overloading fields that don't mean what they say. **GraphML** is the better-fitting alternative — a genuinely generic XML graph format (nodes, edges, arbitrary attributes on either), with a published schema and several independent implementations (yEd, Gephi, NetworkX, igraph), and none of GEDCOM's baked-in domain assumptions. Most org charts don't even need it, though — a strict single-parent tree is already covered by the CSV adjacency-list pattern above (`id, parent_id`). GraphML earns its place once relationships stop being a clean tree: multiple relationship types (reporting line vs. dotted line vs. project assignment), attributes on the edges themselves, or genuine multi-parent structure. And if the deliverable is a *rendered* diagram rather than interchange data, Graphviz's **DOT** is the closer fit — plain text, a single compiled binary, laying out and rendering the graph directly instead of just describing it.

## Revised pipeline

- Structured data feeds Markdown:
- **CSV** (flat records)
- **YAML / TOML** (hierarchized records)
- **Hayagriva / BibTeX** (citations)
- **Markdown** (prose) →
- **Typst** (layout/typeset) → PDF/print → index (generated)
- **Scribus** (WYSIWYG)
- **SVG** (standalone graphics) → embedded into either Typst or Scribus

## Finalists — and what was ruled out

This was never a shortlist of "formats that seem fine" in the abstract — every territory had real, named alternatives that lost specifically on the four rules at the top of this document, not on capability. Naming them is what gives the selection empirical weight instead of just preference.

**Page layout / WYSIWYG → Scribus, not InDesign, Affinity Publisher, or QuarkXPress.**

- InDesign is, by capability, clearly the better tool. But `.indd` is a single-vendor proprietary binary, and Adobe's own workaround proves the underlying point: IDML, InDesign's XML export path, exists because Adobe doesn't fully trust `.indd` to stay openable long-term — and even that escape hatch is weaker than it looks, since its publicly maintained specification hasn't been updated since 2012, and round-tripping through it is lossy. On top of the format risk sits an account risk with nothing to do with price: InDesign is walled-garden software, and a suspended account can mean losing access to files you already own.
- QuarkXPress has the same profile historically, arguably worse — it was the dominant DTP format before InDesign existed, and old `.qxp` files from that era are a well-known category of orphaned files today.
- Affinity Publisher is the most interesting case, because it's a live experiment in the price-vs-openness question. Until 2025 it was a one-time purchase — closer to real ownership, which should in principle reduce vendor risk. Then Canva, which acquired Serif in 2024, relaunched the whole suite in October 2025 as a single free application. That looks like a win, but use of the app is now tied to a Canva account, and Canva's terms allow it to suspend or limit that access at any time. The price dropped to zero and the ownership position got *worse* at the same moment — clean evidence that price and future-proofing move independently, in either direction.
- The nearest real standards-body alternative is OpenDocument Graphics (`.odg`) — ISO/IEC 26300, multiple independent implementations (LibreOffice, Calligra) — but it lacks Scribus's prepress feature set (real CMYK, bleed, preflight), so it loses on capability rather than on format risk.

Scribus stays the finalist for the reason a return to an old document keeps proving in practice: it's the one that stays reopenable. That's rules 1, 2, and 4 doing their job, even while it visibly loses on rule 3 (single-binary minimalism) and on day-to-day usability to every tool it's being chosen over.

## On open source vs. proprietary

Worth being precise here, since price was never one of the four rules. What actually matters is whether continued access depends on a vendor's business model staying alive, or only on a published spec and at least one implementation existing. Open source correlates strongly with that but isn't identical to it — a single-implementation open-source project (Scribus itself, or Typst) still disappears if nobody maintains it. The difference is what's left afterward: a closed binary format becomes reverse-engineering archaeology, while an abandoned open-source codebase and its file-format documentation stay fully available to fork or study. That's the actual mechanism behind price "weighing in favor" of open source without being the deciding factor on its own — paying buys support and recourse *now*; it doesn't buy archival durability *later*, which is a different currency, and the one this whole document is trying to price in.

## Future-proofing risk, ranked

Scoped to the core pipeline formats actually chosen above — not the rejected alternatives (InDesign, Shapefile, QuarkXPress) or the domain-specific extensions (GeoJSON, GraphML, DOT), whose risk profiles are already covered inline where they're introduced.

1. **Markdown** — lowest risk. Trivial spec, dozens of parsers, degrades to something already legible.
2. **CSV** — lowest risk, same reasoning, despite the thinner spec — ubiquity of interpreters more than compensates.
3. **TOML** — low risk. Tight spec, unambiguous, plain text.
4. **SVG** — low risk. Mature W3C spec, many independent renderers; hand-editing is impractical but rarely necessary since the XML is at least inspectable.
5. **YAML** — low-to-moderate risk. Ubiquitous parsers, but the implicit-typing ambiguity is a real footgun on re-edit, not just a theoretical one.
6. **Typst** — moderate risk, mitigated. Younger and single-implementation today, but the spec is published and the source syntax is closer to prose than to a macro language — an eventual reimplementation (or a fork, given it's open source) is plausible in a way that reviving an abandoned proprietary format wouldn't be.
7. **Hayagriva** — moderate risk. Same single-implementation profile as Typst, since it's Typst's own bibliography format; BibTeX is the fallback if that specific risk matters more than the ergonomics.
8. **Scribus** — moderate-to-higher risk *for editing*, low risk *for archival*. The `.sla` XML will always be parseable, but without the app itself, meaningfully re-editing a placement-driven layout by hand is much harder than re-editing a Typst or Markdown source file.

## Scope boundary: raster image storage integrity

Deliberately excluded: how well raster formats (JPEG, TIFF, PNG) survive disk failure and bit-rot. That's a different risk axis from everything above — it's a storage-integrity problem, not a tooling/spec-obsolescence one. A format can have a perfect, permanently-implementable spec and still be destroyed by failing media; conversely, format choice affects *how gracefully* a partially corrupted file degrades, which is a real and separate question worth its own treatment rather than a footnote here.

Nice article to highlight in Boris https://reason.com/2024/08/13/can-nostr-make-twitters-dreams-come-true. But should check some wording (NIP is short for Nostr Implementation Possibility)

Love the feeling of multi- protocol posts reading in Flare. Just needs some polishing as a nostr client: image loading, zaps. Just posted a couple issues in github

Pa de pessic (pinch bread) is how we call it in Catalan, but for this specific recipe with no yeast, in Spanish we call it bizcocho genovés (Genovese cake)