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.
In practice this means that a committee notice, meeting paper, or technical note can start as a Markdown file and later become a PDF, a printed copy, or a web page without changing the source.
The aim is continuity: source files should remain readable, editable, and portable years later.
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 |
|---|---|
| fixed distribution and archive | |
| HTML | browsing and navigation |
| meetings and annotation | |
| Plain text | long-term preservation |
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.
A great deal of day-to-day drafting, correction, and maintenance happens directly in Vim. This keeps the Markdown source close to the surface: the file remains visible, editable, searchable, and suitable for version control without passing through a specialised writing environment.
In this arrangement, Vim is the primary direct editing environment, iA Writer is the PDF publication environment, and Obsidian is a useful review and navigation layer.
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
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 |
|---|---|
| Primary text editing | Vim |
| PDF publication | iA Writer |
| Review and navigation | 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.