Lutrin vs Pandoc — two ways to write an editable PowerPoint from Markdown

What Pandoc does better

Pandoc is a universal document converter for which PowerPoint is one writer among dozens, maintained for decades without a revenue model. Grading it on deck aesthetics would be bad faith. Here is where it is straightforwardly ahead.

Four things Pandoc does that Lutrin does not

It converts in every direction — including out of PowerPoint. Since 3.8.3 it reads .pptx as an input format: hand it a deck somebody else wrote and get Markdown, docx, LaTeX or EPUB back. Lutrin has one input — its own DSL — and can never open an existing deck. That is not a gap we intend to close.
Math survives as math. Pandoc writes equations into the .pptx as OMML: real PowerPoint equations the recipient clicks into and edits. Lutrin renders LaTeX through MathJax and drops a picture into the slide. For anything equation-heavy, Pandoc's output is strictly more editable than ours.
The brand arrives as a file your designer already knows how to make. --reference-doc takes any recent PowerPoint template containing the seven layout names it needs, and the manual notes that templates shipped with recent PowerPoint already qualify. Your brand team edits the corporate template in PowerPoint, with no new format to learn. A Lutrin kit is JSON plus assets, authored in a separate editor.
It is programmable and scholarly. Lua filters rewrite the document tree between reading and writing, and --citeproc resolves citations and builds a bibliography from a CSL style. Lutrin has no filter hook and no citation machinery at all.

Where Lutrin is different

Who chooses the layout. Pandoc's PowerPoint writer applies a fixed rule table over seven layouts — Title Slide, Section Header, Two Content, Comparison, Content with Caption, Blank, Title and Content — keyed to the presence of column divs and to "text followed by non-text". Lutrin infers across a larger catalogue from the structure of the content, with further layouts you can name when the intent is not visible in the content alone. Counting layouts is not the point: Pandoc's seven come from your reference file and a designer can style each of them arbitrarily. The difference is who decides which layout a given slide gets.
Nothing is measured on Pandoc's side. The manual documents no fit checking, no overflow report and no image-resolution warning for PowerPoint output. lutrin validate measures the overflow, flags images under-resolved for the area they land in, suggests a better-suited layout, and returns it as positioned JSON; a build holding an error-severity diagnostic writes no file at all.
Column widths. Pandoc states it plainly: specifying column widths does not currently work for PowerPoint. Lutrin does not accept widths, coordinates or explicit columns anywhere — same outcome, opposite reason. A known limitation on one side, a design contract on the other.
Presentation components. Pandoc's document model has paragraphs, lists, tables, code and images; it has no notion of a chart, a metric card, a progress bar or a status board, and getting one means writing a filter that produces an image. Lutrin ships ```chart, :::metric, :::progress, :::status, Mermaid and Lucide icons as DSL blocks, sized by the engine — though in the .pptx those particular blocks arrive as rasterised images, exactly as a Pandoc filter's would.
Fonts. Lutrin embeds the theme's fonts into the .pptx it writes, after reading each font's embedding permission. Pandoc inherits whatever the reference document carries.
How the brand is distributed. A Lutrin kit is data only — never code — installable from an https URL with a reproducible checksum, refusing any entry that would escape the kit. A Pandoc reference doc is a binary Office file passed around by hand, which is simpler until eleven people have a slightly different copy.
Licence. Pandoc is GPL, free, with no watermark and no paid tier. Lutrin is MIT and free to use, but marks every slide until a seat is bought. The honest framing of that is not a feature-gating story: it is that we charge for something you can get for free elsewhere, and the argument for it has to be the engine, not the absence of an alternative.

Side by side

	Pandoc	Lutrin
What it is	A universal document converter; slide shows are one destination among dozens.	A deck compiler: one DSL in, `.pptx` or standalone HTML out.
Reads `.pptx`	Yes, since 3.8.3 (2025-12-01).	No, and never will — the input is always the Markdown DSL.
Is the `.pptx` editable?	Yes. Native text boxes, native tables, OMML equations, highlighted code. Not images.	Yes for text, tables and shapes. Charts, equations and icons are rasterised images.
Layout selection	Seven layouts chosen by a fixed rule table.	Inferred from content structure, plus layouts you can name and parameterised official ones.
Where the brand lives	`--reference-doc`: a real `.pptx`/`.potx` carrying the seven required layout names. A missing name warns and falls back.	A kit — theme JSON, layouts, fonts, logos — resolved through a documented precedence chain.
Speaker notes	Yes, via a `::: notes` div — and since 3.9 also on the generated title slide through a metadata field, which Lutrin's cover has no equivalent for.	Yes, `<!-- notes: … -->`, surfaced in the HTML presenter mode and in the `.pptx`.
Background images	Yes, on the slide heading. Whole-deck backgrounds go through the reference doc's layouts.	A cover image makes the engine choose the hero layout.
Tables	Native PowerPoint tables. 3.10.1 keeps a table and its surrounding text on one slide rather than splitting them.	Native PowerPoint tables. The delimiter row's alignment is the one place something written in the Markdown decides where ink sits.
Math	OMML — native, editable equations.	MathJax rendered to an image.
Charts and diagrams	No chart or diagram concept in the model; needs a filter that produces an image.	```chart and Mermaid are DSL blocks sized by the engine (images in the `.pptx`).
Column widths in PPTX	Documented as not currently working.	No widths, coordinates or explicit columns exist in the DSL at all.
Validation of the result	Warns when a reference doc lacks a required layout name. No documented fit, overflow or resolution checking.	Measures overflow, under-resolved images and layout mismatch; `--json` for agents; `build` exits 1 on any error.
Extensibility	Lua filters over the document AST, citeproc bibliographies, dozens of readers and writers.	Kits and layout JSON — data, never code.
Licence and price	GPL, free, no paid tier, no watermark.	MIT, free to use, with a mark on every slide until a seat is bought.

Run the comparison yourself

This is the fairest demo of the four, but the source has to be written twice, because the two inputs are genuinely different languages. Pandoc needs ::: {.columns} divs to get its Two Content layout; Lutrin needs two ## headings and picks two columns itself. Six slides is enough: a title from metadata, a two-column slide, a table, an image, speaker notes and a code block.

pandoc deck-pandoc.md -o pandoc.pptx --reference-doc=brand.potx
npx lutrin build deck-lutrin.md -o lutrin.pptx

Open both in PowerPoint and open the Selection pane. Both files are made of real, named, editable shapes. That is the honest headline, and it kills the "Pandoc exports pictures" myth on the spot.

What the side by side actually shows is four things. Pandoc's slide is laid out by the reference file's placeholders, so its look is entirely the template designer's; Lutrin's is composed by the engine. An equation added to both is clickable in Pandoc's file and a picture in ours. A chart added to both exists only in ours. And padding the two-column slide until it overflows produces a silent overrun from Pandoc and a measured diagnostic plus repagination from lutrin validate.

Every claim about Pandoc on this page was checked against the Pandoc manual and changelog on 2026-07-30, against Pandoc 3.10.1 (released 2026-07-21). Pandoc ships roughly monthly, so behavioural claims here are dated deliberately. If a statement has stopped being true, tell us. Sources: the manual, PowerPoint layout choice, the release notes.

See what Lutrin compiles Compare with Marp