markdown to powerpoint · compared

Lutrin vs Pandoc

Start with the correction, because it is the thing most pages of this kind get wrong: Pandoc's PowerPoint output is genuinely editable. Native text boxes, native tables, real OMML equations, highlighted code. Anyone telling you Pandoc exports pictures is repeating something that was never true. The real difference is narrower, and more interesting: who chooses the layout, and whether anything gets measured.

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 reads text and nothing else — its own DSL, plus Marp Markdown when the frontmatter says marp: true — and can never open a .pptx. That is not a gap we intend to close.
  • 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, and Pandoc honours its layouts — the placeholder boxes included. Lutrin now reads a template too (lutrin kit import brand.potx), but only for what a kit is allowed to carry: the colour scheme and the two type families. The layouts and every placeholder position are deliberately left behind, because honouring a coordinate is the one thing this engine refuses. If what you want is your designer's boxes, that is Pandoc's, not ours.
  • 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 prints the lot as JSON anchored to source lines — the positioned geometry is a second command, lutrin inspect. A build whose validation holds an error-severity diagnostic writes no file at all, short of an explicit --force.
  • 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 — the cards are drawn in the .pptx as native rounded rectangles and text, while the charts, the diagrams and the icons arrive as pictures — each one carrying its vector alongside its raster, where a Pandoc filter's image would carry only what the filter drew.
  • 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.

Side by side

 PandocLutrin
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 Markdown, its own DSL or Marp's.
Is the .pptx editable? Yes. Native text boxes, native tables, OMML equations, highlighted code. Not images. Yes for text, tables, shapes and equations — the maths is native OMML with the picture kept underneath as a fallback. Charts, diagrams and icons are pictures, each one carrying its vector as well as its raster, so PowerPoint 2019+ keeps them sharp at any zoom and every other reader draws the raster — pictures all the same, not editable objects.
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. lutrin kit import brand.potx derives one from your template's colour scheme and type families; its layouts and placeholder positions are left behind on purpose, and the command counts what it left rather than letting you assume it travelled.
Speaker notes Yes, via a ::: notes div — and since 3.9 also on the generated title slide, through a metadata field. Yes, <!-- notes: … --> on any slide you write — a cover slide included — surfaced in the HTML presenter mode and in the .pptx. The cover Lutrin generates itself takes a frontmatter notes: line, the same answer to the same problem; a flat one-liner, where Pandoc's metadata field takes a block.
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. OMML too, wrapped the way PowerPoint wraps its own: the equation in mc:Choice, the MathJax picture in mc:Fallback for readers without OMML. An expression the converter cannot map exactly keeps the picture alone, and the build says how many did.
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, no paid tier, no watermark.

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.