Skip to content

Publishing System

My publishing workflow is built around a simple principle:

Core principle

The source document should outlive the software used to create it.

Most documents begin as plain Markdown text and remain in that form permanently. From the same source material I generate PDFs, websites, notices, agendas, reports, meeting papers, and archival copies.

The aim is not merely efficiency. It is continuity.

A document should remain readable years later, editable on different systems, and portable between tools without requiring conversion or reconstruction.


Why Markdown

Markdown occupies an unusually useful middle ground.

It is structured enough to support headings, quotations, lists, links, references, and publication pipelines, while remaining readable as ordinary text.

# Heading

A paragraph remains readable as text.

- Lists remain visible
- Links remain understandable
- Structure survives

This matters operationally as much as philosophically. A great deal of institutional information becomes difficult to recover because it is stored inside proprietary systems whose surrounding context eventually disappears.

Failure mode

Markdown has a good failure mode.

Even if every supporting application vanished tomorrow, the source files would still remain understandable.


Source and artefact

In this workflow, the Markdown file remains the canonical source.

Generated outputs are treated as artefacts:

Output Purpose
PDF fixed distribution and archive
HTML browsing and navigation
Print meetings and annotation
Plain text long-term preservation
Markdown → Git → MkDocs / PDF → Archive

This distinction is important because it prevents the archive becoming dependent on a single output format.


Writing environment

Most writing takes place across:

  • iA Writer
  • Obsidian
  • Vim
  • terminal environments on Linux and iPadOS

The system is intentionally editor-agnostic. Editors are tools rather than repositories. The archive itself remains folder-based and transparent.

Working preference

Editors should improve the writing experience without becoming required for understanding the archive.


PDF generation

For formal publication I use custom iA Writer templates designed to produce restrained, print-oriented PDF output.

The templates are influenced by traditional technical publishing and LaTeX-style typography while remaining lightweight enough for day-to-day use on iPadOS.

Features

  • embedded fonts
  • structured title blocks
  • heading numbering
  • figure captions
  • footnotes
  • watermark support
  • notice layouts
  • table styling
  • dark/light web rendering

Typical workflow

Markdown source
iA Writer template
Generated PDF
Meeting / circulation / archive

Web publication

For websites I use MkDocs Material with a heavily customised visual layer derived from a restrained DOS/Borland-inspired palette.

The attraction of MkDocs is not simply appearance. It is structural clarity.

Pages remain:

  • file-based
  • searchable
  • version-controlled
  • static
  • portable

The resulting sites are fast, predictable, and comparatively easy to preserve.

Static preference

Most information does not need to be generated dynamically in order to be useful.


Version control

All significant material is version controlled using Git.

This provides:

  • change history
  • rollback capability
  • synchronisation
  • deployment
  • archival confidence

In practice, version control becomes especially valuable for administrative and technical documentation because small wording changes often carry operational consequences.


iPad-first workflow

An important constraint in the system is that it must work comfortably on iPadOS as well as conventional desktop environments.

That requirement strongly influences tool selection and workflow design.

Current components include:

Function Tool
Writing iA Writer
Knowledge management Obsidian
Git Working Copy
Terminal access blink.sh / Shellfish
Remote infrastructure Linux + Tailscale

The result is a workflow that remains portable without becoming dependent on cloud-native application ecosystems.


Long-term preservation

A useful publishing system should age slowly.

This means:

  • avoiding unnecessary complexity
  • preferring open formats
  • keeping source visible
  • separating source from output
  • reducing application dependency

The goal is not technological purity. It is operational resilience.

Archival principle

Good systems should remain understandable even after parts of the surrounding ecosystem disappear.


Current direction

Current work includes:

  • refinement of static private websites
  • improved PDF publication templates
  • integrated Markdown → PDF → web workflows
  • typography and accessibility adjustments
  • archival organisation of long-term notes
  • improved iPad-based administration workflows

The system continues to evolve gradually, but the underlying principles remain stable.

“Plain text is the closest thing we have to a universal interface.”