slipshow compiles Markdown into presentations you scroll, not slide

A slip is a slide without a bottom

The idea behind slipshow is a small change to a concept everybody already has. In a slipshow presentation, the equivalent of a slide is called a slip, and each slip is like a slide but with no bottom limit, so the content can be arbitrarily long. During the presentation, the camera scrolls down to reveal the hidden content, following a script given by the presenter.

That single change is the whole design. In a conventional deck, a slide is a fixed frame and advancing is a cut. Here, advancing is a camera movement over a continuous surface, and the presenter controls where the camera is and when it moves. The content of one thought can therefore be long, and the transition into the next thought can be a scroll rather than a replacement.

The audience for that is people who present technical talks, and the project is written by people who do. The format is aimed at talks where the structure is an argument with stages rather than a list of points, and where showing a diagram or a piece of code with the explanation happening as you scroll over it is more natural than having it appear all at once.

The implementation language is OCaml, the project is called an engine rather than an editor, and the project description says it is for displaying slips, the next generation version of slides. The homepage is slipshow.org, and the README makes a point of directing users there, because this repository is about the development of the tool rather than about using it.

Three capabilities beyond a scrolling deck

The README lists what slipshow does differently from traditional slide based presentations, and the list is short enough to quote in full.

- Scroll on a slip instead of changing slides, making content flow continuously
- Record hand-drawings when preparing your talk, edit them, and have them replayed during the presentation
- Include and execute custom scripts by steps, to make your presentation clearer through e.g. animation or interaction.

The first is the scrolling itself. The second is the most distinctive feature and the one with the most obvious use: you draw on a slide while preparing the talk, those drawings are recorded, you can edit them afterwards, and they are replayed live during the presentation. For a talk where you are explaining a diagram by drawing on it, that turns the drawing from a one off gesture into something you can prepare, correct and rehearse.

The third is step scripts. A presentation is divided into steps, and a step can carry a script that runs when you reach it, which is how animation and interaction are expressed. That is a different model from the timed transitions of a slide tool, and it is worth understanding that the script is attached to a step in the content rather than to a transition between two frames.

The one that is not on the list is live editing of the slides during the talk, and that is a deliberate difference. The recorded drawings are edited before the talk, not during it, and the presentation itself is a compiled artefact.

One Markdown extension in, one HTML file out

Slipshow compiles files written in an extension of Markdown to a standalone HTML file that can be viewed offline in any web browser.

That output contract is the most consequential decision in the project, and it drives several of the practical consequences. A standalone file means the presentation has no runtime dependency, no server, no network call and no install on the machine you present from. You can put it on a USB stick, attach it to a conference laptop, or email it to a co-speaker. It also means the output is inspectable: the HTML is the artefact, and there is no viewer application to install or keep current.

The input side is Markdown plus extensions, which keeps the source in a format that is easy to write, easy to diff and easy to put under version control. That matters more than it sounds for a talk that is being revised until the day before, since a presentation source that is a text file can be reviewed in a pull request like any other document. The repository layout backs this up, with the format extending Markdown and the output being plain HTML rather than a binary or a project directory.

The documentation is at docs.slipshow.org, and the README calls it extensive. It covers the tutorial, the API and the rest, and there is a separate page on writing a theme, which is what you would read if you wanted to change the visual design rather than the content.

The themes point deserves a note. A theme is a separate concern from a presentation, and the fact that the project documents theme authoring as a supported activity, with a dedicated page linked from the contribution guidance, tells you the rendering is parameterised rather than hard coded into the compiler.

An OCaml project built with dune, with the examples in the tree

The repository listing describes the shape of the project.

The build is dune, with a dune-project file at the root and a dune directory, and the formatting is handled by .ocamlformat. The package is published to opam, with slipshow.opam and a slipshow.opam.template beside it, which is the pattern for a project whose package metadata is generated from a template with the version substituted at release time. There is a release/ directory, which is where the release process writes its output, and a vendor/ directory for vendored dependencies.

The source is in src/, the tests in test/, the static assets that get embedded in the output in static_data/, and the documentation in docs/ with a .readthedocs.yaml configuration. There is a CHANGELOG.md at the root, which the README points to for recent changes.

The examples directory is the most interesting part of the listing for an evaluator, because it shows the format in use by real talks rather than by the project that wrote it. It contains BOBKonf, a conference presentation, campus-du-libre, a university event, edge-documentation, a documentation use case, funocaml-2025, a programming language conference, and undo-monad-short. There is a README in the example directory too, and the presence of an example/ subdirectory per talk, with its own assets, suggests that a talk is a self contained unit in the source tree.

The range of the examples is the point. A tool for talks that are only about slides would have one kind of example. Here you have a conference keynote, a university event, a documentation talk and a short conference talk, which suggests the format is meant to survive outside the conference room.

A GPLv3 project with parts under other licences

The licence position needs reading carefully, and the README is precise about it. Slipshow is distributed under the GPLv3 license, with parts in ISC, DBS 3-Clause, Apache-2.0 and SIL OPEN FONT LICENSE Version 1.1, and the LICENSE.md file in the repository root has more information.

So the project itself is copyleft, and the vendored or included parts carry their own terms. The ISC and Apache-2.0 parts are permissive. The SIL Open Font License covers the font, which is a separate permission set that exists precisely so that embedding a font does not force the whole document into the copyleft terms. The BSD 3-Clause variant, listed here as DBS 3-Clause, is a permissive licence too.

The licence field on the repository itself records a custom licence that GitHub cannot classify, which is what happens when a project ships a mixed licence set that the metadata schema has no way to express. The authoritative statement is the README's paragraph and the LICENSE.md file.

For a user, the practical question is what you distribute. If you compile a presentation and hand the resulting HTML to an audience, you are distributing the output rather than the program, and the terms that attach to the fonts and the vendored assets in that output are what matter most. If you want to embed the engine in a product of your own, the GPLv3 terms on the program itself are the constraint to evaluate. This is not legal advice, it is a description of which files to read.

Sponsorship, codename releases, and a documentation split

The support section records something unusual for a project of this size. The NLNet Foundation is sponsoring Slipshow development in 2025 and 2026 through the NGI Commons Fund with funds from the European Commission, and the README thanks them prominently.

That funding explains the release cadence. The recent releases are v0.13.0 on 2026-09-05, v0.12.0 on 2026-08-12, which carries the subtitle The Lord of the Slips: The Two Editors, and v0.11.0 on 2026-05-24, which is titled Lspishow 0.11.0: Brazlip. The last push to the repository was on 2026-10-13, and the repository is not archived. So the project is at version 0.13, actively worked on, and naming its releases with a joke, which is a strong signal about the tone of the project.

The names are not random either. The Two Editors in the 0.12.0 title points at a real area of the project, since the engine and the editing tooling are separate concerns, and Brazlip in the 0.11.0 title is the name of a type, a Brave new System type, which is the kind of OCaml feature the project would want to show off. A version number is not only a number in this project.

The documentation is split in two, and the split is deliberate. The README is explicitly about the development of Slipshow, and it tells a user who wants to use it to go to the official website at slipshow.org. The development documentation, the tutorial, the API and the theme guide live at docs.slipshow.org, with the README describing it as extensive. Contributors are pointed at GitHub for bugs, feature requests, documentation improvements, theme creation and pull requests, with a note to read the contributing guide first, which is the CONTRIBUTING.md file in the repository root.

Editorial conclusion

Adopt slipshow if you give talks where the argument is a continuous flow rather than a sequence of fixed frames, if you want the output to be a single HTML file that works offline with no runtime dependency, and if you are prepared to learn a format extension rather than adapt an existing tool. Do not adopt it if your workflow depends on the standard slide deck format, on a specific presentation tool's editing model, or on the way that tool handles animation, because a slip is a different unit of content. Before you commit, read the documentation site, look at the example presentations in the example/ directory to judge whether the scrolling model suits your talk, and check the licence file, since the project ships GPLv3 code alongside parts under ISC, DBS 3-Clause, Apache-2.0 and the SIL Open Font License.

Frequently asked questions

Official sources

1. Issues
2. panglesd/slipshow on GitHub
3. Project website
4. README
5. Releases