Markdown With Superpowers

One text file. Four output formats. No export pipelines, no tool switching, no compromises. Quarkdown turns plain Markdown into a Turing-complete typesetting language.

We are a species that thinks in formats.

You write the book in Word. The slide deck in PowerPoint. The research paper in LaTeX. The wiki in Confluence. These are not arbitrary choices. Each format has a different runtime, a different mental model, and a different export pipeline. When the same idea needs to live in all four places, you copy, paste, reformat, and pray the styles survive the transfer.

This is the fragmentation tax. And most people pay it without noticing because it has always been this way.

**Markdown got us halfway there.**

Plain Markdown solved the authoring problem. Text is text. No proprietary containers, no binary blobs, no formatting dialects locked to a single application. A `.md` file is readable anywhere, writable anywhere, and diffable in any version control system.

But Markdown has a ceiling. It has no structural layout primitives. It cannot loop through data. It cannot declare a reusable component, execute a conditional, or adapt its output based on a build target. It is a great markup language that cannot compute.

That gap has forced a sprawling ecosystem of workarounds. MDX for React components. Pandoc for cross-format conversion. LaTeX for mathematical typesetting. Hugo shortcodes for templating. Each solution solves one problem and introduces two more.

**Quarkdown collapses the stack.**

Quarkdown is an open-source typesetting system built by Giorgio Galla. It starts from CommonMark Markdown and extends it into a Turing-complete language. The same source file can compile into a print-ready PDF, a reactive slide deck, a dense knowledge base, or a static documentation site. You pick the target with a single frontmatter property.

The key word is deterministic. Change `type: slides` to `type: paged` and the compiler produces a paginated book layout. Change it to `type: html` and you get a browsable site. The content does not change. The structure adapts around it.

**The syntax is still Markdown.**

That is the design decision that makes Quarkdown practical rather than theoretical. You do not learn a new language. You write raw Markdown and reach for Quarkdown's function system when you need more.

Functions are called inline with a dot notation: `.function {argument}`. They compose naturally, pass arguments, and return rendered content. You can declare your own functions directly inside the document, scope them to a section, and reuse them without boilerplate. The standard library ships math rendering, figure captions, code environments, bibliography management, and layout primitives out of the box.

Loops work. Conditionals work. You can iterate over a data source and render a structured output for each entry. You can define a variable once at the top of the document and reference it throughout. The document is a program. The output is its result.

**The toolchain is tight.**

Quarkdown ships a native VS Code extension that streams AST changes to a live visual preview as you type. The feedback loop is immediate. You see the compiled output updating alongside your source, which matters when you are working across layout targets that behave differently.

The compiler is written in Kotlin and runs on the JVM, which means it is cross-platform and fast. The extension handles syntax highlighting and the connection to the preview server. Offline-first, no cloud dependencies, no accounts.

**Why this matters now.**

The interesting thing about Quarkdown is not the feature list. It is the bet underneath it.

Document formats exist as separate silos because no single format was expressive enough to cover all use cases. LaTeX is too heavy for a quick reference doc. Markdown is too thin for a textbook. PowerPoint is too visual for a wiki. So organizations pick three or four tools and build bridges between them that break constantly.

Quarkdown's bet is that Markdown, extended far enough, can be all of them at once. A monorepo for thought. One source of truth that compiles to whatever format the audience needs.

That bet has tradeoffs. The learning curve for functions is real. Complex documents require thinking about compilation rather than just writing. Some output targets are more mature than others in the current release.

But the direction is correct. The fragmentation tax is not inevitable. It is an artifact of tools that were designed in isolation. When your text is also executable code, the traditional document stack starts looking like a legacy constraint rather than a permanent fact of life.

The `.docx`, the `.pptx`, the rigid export pipeline. These do not have to be the end state. They are just where we got stuck.