Marker: a GTK3 markdown editor built for scientific documents

A markdown editor whose real subject is the paper

Marker is a markdown editor for Linux built with GTK+ 3.0, described in the README as a native GTK+3 application, and licensed under GPL-3.0. The description in the repository says it plainly: a GTK3 markdown editor.

The feature list, however, is not the feature list of a plain markdown editor. Alongside viewing and editing markdown documents, the list covers HTML and LaTeX conversion, YAML headers, document classes, a Beamer and presentation mode selected with a class keyword, abstract sections, a table of contents, external document inclusion, equations, figures, tables and listings that all carry a reference id and a caption, and internal references.

That is a description of a scientific typesetting tool that happens to have a markdown syntax. The equations and figure references are the tell: a paper with numbered figures, cross references between sections and a bibliography is what the tool is built for, and the markdown is the input format rather than the goal.

The rest of the list confirms the audience. TeX math rendering with KaTeX or MathJax, support for mermaid diagrams, a plotting integration called charter, syntax highlighting for code blocks with highlight.js, an integrated sketch editor, custom CSS themes, custom syntax themes, and export through pandoc to PDF, RTF, ODT and DOCX.

The project is developed on the master branch, the last push was on 2026-08-20, and the releases are named by date rather than by version, with 2023.05.02, 2020.04.04 and 2019.11.06 among the most recent.

Scidown is the engine, and it owns the parser bugs

The most useful line in the README is a note about where to file issues. It says that issues regarding markdown parsing should go to the scidown repository, and the feature list points at the same project for HTML and LaTeX conversion and for the extra scientific syntax, which is documented on its own wiki.

That is an architectural decision worth understanding before you install anything. Marker is the desktop shell, and the document semantics live in scidown, a separate project. The consequence for a user is practical: when the preview renders something oddly, the fix or the answer is usually not in the Marker repository, and the README is telling you where to look so that you do not file a bug against the wrong project.

The syntax that comes with it is what gives Marker its character. YAML headers carry document metadata, document classes select the output type, and a class of beamer switches the document into presentation mode. Abstract sections and a table of contents are structural features rather than something you hand-write. External document inclusion lets a document pull in another file, which is how a long manual is split up.

The reference system is the part that makes it a paper tool rather than a note tool. Equations, figures, tables and listings can each be given a reference id and a caption, and internal references point at them. In a normal markdown editor, every figure is a picture you drag in and every cross reference is a number you type by hand and update by hand. Here they are declared, and the conversion resolves them.

So the honest summary is that Marker is a front end for scidown with a GTK3 interface, a preview, a sketch editor and an export pipeline, and the two projects have to be read together.

Preview rendering and export use two different toolchains

The dependency list shows that Marker uses two separate conversion stacks, and the split is deliberate.

The on-screen preview is the web stack. Math is rendered with KaTeX or MathJax, mermaid diagrams are supported, and code blocks are highlighted with highlight.js, all of which are web technologies, and the build dependencies include webkitgtk4-devel. The preview is therefore a web view inside a native window, which is what makes KaTeX, MathJax and mermaid possible at all without reimplementing them.

Export is the pandoc stack. The README calls it flexible export options with pandoc, and lists PDF, RTF, ODT and DOCX as the targets. Pandoc is also a hard build dependency, listed alongside the GTK development packages, which tells you it is not an optional extra but the export engine.

The distinction matters in practice. What you see in the preview is rendered by the web stack, and what lands in the exported file is produced by pandoc, and those two paths do not have identical feature sets. A construct that renders in the preview is not automatically preserved in the DOCX, and the README does not document a compatibility matrix, so the way to find out is to export and look.

The customisation surface follows the same logic. Custom CSS themes affect the preview, because the preview is a web view, and custom syntax themes affect the editor, because that is the GTK source view component. The two are different mechanisms for different halves of the application.

The integrated sketch editor is the odd one out. Screenshots in the repository show a separate sketching window, and a sketch editor inside a markdown tool is a way to draw a figure without leaving the application, which is exactly the kind of feature that would otherwise send a user to another program mid document.

Distribution packaging is the strongest part of the project

The README lists packages for a wide range of Linux distributions, and the list is a good indicator of who actually uses this project.

There is a Fedora package, a Flathub entry, an Arch Linux AUR package, an official Arch package, an Ubuntu PPA for stable builds, an Ubuntu PPA for daily builds, and a Snap Store listing. The credits name the individual maintainers for each one, which is a nice detail: this is a project whose reach comes from individual volunteers packaging it rather than from a company shipping binaries.

Two of those channels deserve a note. The Flathub entry corresponds to a flatpak manifest that sits in the repository root, com.github.fabiocolacio.marker.json, and a flatpak is the cleanest way to run a GTK application with a webkit preview on a distribution that packages webkit awkwardly. The Ubuntu PPA for daily builds is the opposite trade: it gives you the current master rather than a stable release, and the README itself warns against that route for a stable experience.

The repository supports the packaging story directly. There is a debian/ directory for the Debian packaging, a post-install.sh script, a configure script alongside the meson build file, a po/ directory for translations, a help/ directory holding the user guide and its figures, a data/ directory for the application's data files, and a test/ directory.

The GNU GPL-3.0 licence is what makes this model possible for the distributors. Each distribution can patch, repackage and ship the application, and the obligation to publish modifications is a normal condition of the licence rather than a negotiation. For a user on Linux, the practical answer is that installing Marker from a distribution package or from Flathub is easier than building it, and building it only makes sense when you want a version that is not packaged yet.

Building from source means meson, ninja and a clean extensions directory

The source build is documented with a dependency list and a short command sequence, and there is a warning in front of it that saves a broken installation.

The dependencies are meson at 0.37.0 or newer for installation only, gtk3-devel at 3.20 or newer, gtksourceview3-devel, webkitgtk4-devel, pandoc, gtkspell and itstool. The GTK source view component is the editor widget, webkit is the preview, pandoc is the export, gtkspell is the spell checker and itstool handles the translation catalogue.

The command sequence itself is conventional Meson practice:

$ git clone https://github.com/fabiocolacio/Marker.git
$ cd Marker
$ git submodule update --init --recursive
$ mkdir build && cd build
$ meson .. --prefix /usr
$ ninja
$ sudo ninja install

The submodule step is not optional, since the README notes the project uses submodules and the repository root carries a .gitmodules file. The out-of-source build in a separate directory is the Meson convention.

The warning is the part to notice. The README says to make sure to clean the extensions before updating, and gives the command:

rm /usr/share/com.github.fabiocolacio.marker/extensions/**

That path is inside the installed prefix, so the extensions are files that were installed alongside the application, and stale copies there survive an update and conflict with the new version. It is a slightly rough edge in an otherwise careful install story, and it is the kind of thing that shows up only after a few upgrades.

The README also recommends that users who want a stable experience download the release tarball rather than cloning from master, which is consistent with the distribution advice and with the release history.

One more line in the repository explains the export path in practice: the extension directory is where a custom export format would live, which is what makes the pandoc integration extensible rather than fixed.

The release trail and the source have drifted apart

The dates in this repository are unusual and worth reading carefully.

The most recent release listed is 2023.05.02, before that 2020.04.04 and 2019.11.06. The releases are named after their date rather than a version number, which is a convention the project uses instead of semantic versioning. The last push to the repository was on 2026-08-20, and the last push is not a release.

So the code is being worked on while the tagged releases have not moved for a few years. For a user this is mostly a non-issue, because the distribution packages are the delivery mechanism and they are maintained separately, and the Flathub build and the Ubuntu daily PPA both track something newer than the last tag. For a packager it matters more, because you are choosing between a released tarball, a distribution package that may be a few months old, and a build of master that includes fixes nobody has tagged.

The README steers users toward the release tarball for a stable experience, and the Ubuntu daily PPA exists for the opposite case, so the choices are laid out if you know to look for them.

What the repository does not say is which features landed after 2023.05.02 and which are in which distribution package, so a reader who wants a specific behaviour, say the sketch editor or the mermaid support, has to check the source or the package version rather than a changelog. There is a CHANGELOG-style file in the tree only in the sense that the repository listing shows no such file at all, and the archive.sh and docs/ directories suggest some release automation exists, but the version story lives in the tarball names.

That is the honest state of the project: an active codebase, a mature distribution footprint and a release trail that is kept loosely in step with the packages rather than with the commits.

Editorial conclusion

Adopt Marker if you write scientific or technical documents on Linux and want a native application with a live preview, Scidown's equation and reference syntax, and pandoc driven export without leaving the desktop. Do not adopt it if your documents live in a browser-based workflow, since the application is a native GTK3 program for Linux and nothing else, and do not expect the released version to match the current source, because the newest tag is from 2023 while the last push was on 2026-08-20. Before you install from a distribution package, check which version it carries, and if you build from source, clean the installed extensions directory first, since the README warns that stale extensions break an update.

Frequently asked questions

Official sources

1. fabiocolacio/Marker on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases