rinohtype renders reStructuredText to PDF with a CSS-like stylesheet, without LaTeX

A document processor with its own layout engine instead of a LaTeX round trip

rinohtype is described as a batch-mode document processor. It renders structured documents to PDF based on a document template and a style sheet, and the stated design goal is that document layout and style customization be user-friendly.

The distinguishing decision is that the layout engine is written in Python rather than delegated to LaTeX. The documentation says it should be able to replace the Sphinx LaTeX builder in most cases, and that claim is the whole pitch: a Sphinx project that currently shells out to a LaTeX toolchain, with all its system packages and font configuration, can produce PDF from the same sources through a pure-Python path.

The feature list gives a sense of how much of the typesetting stack is implemented rather than delegated. There is a page layout system supporting columns, running headers and footers, floatable elements and footnotes. Figures and large tables are supported and can be rendered sideways. The table of contents and the index are generated automatically, and section headings, figures and tables are numbered and cross-referenced automatically.

The modular design is what makes the rest plausible. The document model, the layout engine and the frontends are separate, so multiple input formats can be supported, with reStructuredText as the primary one and CommonMark and DocBook also present in the tree.

The project is honest about its status. It says it is still in beta and that you might run into some issues, and it asks for bug tickets rather than pretending the edges are settled.

The style sheet is CSS, and the stylesheets are the contribution the project needs

The style system is the part of rinohtype most unlike a typical document generator, and the one that makes it interesting to adopt. The style sheet is described as intuitive and inspired by CSS, allowing changing almost every aspect of how document elements are rendered.

That single decision has a large consequence for the surrounding project. The call for contributions says that rinohtype is a fairly sizable project currently maintained by a single person, and lists the first thing that would help as development of professional-looking stylesheets and document templates. Stylesheets are easy to write and hard to make genuinely good, which is exactly why a single maintainer asking for help there makes sense.

The same list asks for help maintaining the documentation and developing new features such as widow and orphan handling, Knuth-Plass line breaking, mathematics typesetting and performance improvements. Those four are named as future work, and they are also the four features most likely to make you pause. Widow and orphan handling is basic for a serious typesetting system, and Knuth-Plass line breaking is what produces the even colour of justified text you would want in a printed manual. Mathematics typesetting is handled through a separate dependency path, described below.

So the honest reading is that rinohtype is a capable engine with an incomplete set of the refinements a professional typesetter would consider non-negotiable, and the project itself lists them as known gaps.

Font handling is where the typographic claim lives

The font support is the most concrete technical claim in the feature list, and it is more specific than the usual font support in a PDF tool.

rinohtype handles OpenType, TrueType and Type1 fonts, with support for advanced typographic features such as kerning, ligatures, small capitals and old style figures. Small capitals and old style figures are the two that matter most in practice for a document that has to look professionally set, and they are exactly the features that a naive text layout engine drops on the floor because it treats the font as a flat table of glyphs.

Old style figures are the ones worth flagging for a technical manual, since they have ascenders and descenders that sit with lowercase text, which is a detail that only matters if the layout engine knows where the baseline and x-height are. The project is built on Unicode and is described as ready for non-latin languages, which implies the same machinery has to cope with non-Latin metrics as well.

There is built-in support for the 1000 plus libre licensed fonts on Google Fonts, and the dependency list shows the mechanism. Instead of shipping font binaries, the project depends on separate typeface packages such as rinoh-typeface-dejavuserif, rinoh-typeface-texgyrecursor and rinoh-typeface-texgyreheros, each pinned to a narrow version range. Those are the DejaVu Serif and the TeX Gyre Cursor and TeX Gyre Heros families, with the TeX Gyre families being the standard open substitutes for the PostScript core fonts.

Images are handled in the same spirit: PDF, PNG and JPEG are embedded with transparency and colour profiles preserved.

The rinoh command renders a document, the Sphinx builder handles the project

There are two entry points, and they solve different problems.

The first is the rinoh command line tool, which renders reStructuredText documents. The documentation calls this the easiest way to get started, and the example it gives is to render a reStructuredText document such as CHANGES.rst from the repository:

   rinoh CHANGES.rst

When rinoh finishes, you will find CHANGES.pdf alongside the input file. The output lands next to the source with the same base name, which is a small detail that makes the tool pleasant to experiment with.

By default rinoh renders the input using the article template, and rinoh --help is the documented way to see how to select a different template and style sheet.

The second is the Sphinx builder, which rinohtype can use as a drop-in replacement for the LaTeX builder. The one condition is that the latex_documents configuration variable has to be set, which makes sense, since that variable is what tells Sphinx which documents to build and in what order.

The input format story is layered. reStructuredText is the primary format, and for parsing reStructuredText and CommonMark documents rinohtype depends on docutils and myst-parser respectively. So a Markdown document goes in through myst-parser, and reStructuredText goes in through docutils, and both land in the same document model before the layout engine sees them.

Installation is one pip command, with an extra for equations

The installation section calls it trivial, and for the base case it is:

    pip install rinohtype

The requirement is Python 3.10 or newer. The packaging metadata says requires-python >=3.10,<4.0, and the classifiers list Python 3.10 through 3.14, plus CPython and PyPy implementations. The documentation also notes that rinohtype supports all stable Python 3 versions that have not reached end-of-life status.

There is one extra worth knowing about. Rendering equations requires ziamath and cairosvg, and to get those alongside rinohtype you ask for the math extra:

    pip install rinohtype[math]

Two more optional pieces are installed implicitly. Syntax highlighting of code blocks is enabled if Pygments is installed, and Pygments is installed automatically with Sphinx. And if you want to include images other than PDF, PNG or JPEG, you also need Pillow.

If you want bug fixes and features that are not in a release, the documentation gives the development install as a direct archive URL:

    pip install https://github.com/brechtm/rinohtype/archive/refs/heads/master.zip

The project describes itself as easy to install and deploy, pure-Python with few dependencies, and that claim holds: there is no system LaTeX to install and no separate font server to configure.

One maintainer, a slow release cadence, and an AGPL licence

The maintenance picture is the part to weigh before committing a documentation pipeline to this.

The project says it is fairly sizable and currently maintained by a single person, and it asks for volunteers to become maintainers, specifically to fix issues that pop up when new versions of dependencies are released, Python and Sphinx among them, or to handle platform-specific regressions. The parenthetical is telling: development is mainly on macOS. So if your team is on Linux or Windows, you are running on a platform the maintainer does not primarily develop against, and the project is asking for help precisely there.

The release history shows the same pattern. Version 0.5.6 was released on 2026-05-15, version 0.5.5 on 2024-07-13 and version 0.5.4 on 2022-06-17, and the last push to the repository was on 2026-09-19. The package metadata carries version 0.5.7, so there is work in the tree beyond the last tagged release. The gap between 0.5.4 and 0.5.5 is two years, which tells you this is not a project with a predictable release rhythm, and that matters when your build depends on a specific version.

The licence is AGPL-3.0, declared as AGPL-3.0-only in the packaging metadata with the licence files listed as LICENSE*. The AGPL is a materially different choice from the permissive licences a typesetting library might otherwise use, and the reason to read the licence text rather than assume is that it applies to how you offer the software to users over a network. This is a documentation point, not legal advice, but for a tool that renders your internal documentation into PDFs for a paying audience, the distinction is worth checking with whoever owns that decision.

The tree also shows the packaging machinery. There is a poetry.lock and a poetry.toml, a noxfile.py and noxutil.py for test automation, a run_tests.py, a wininst.py and wininst.cfg for Windows installers, a macapp.py and macapp directory for a macOS application wrapper, a gitlabpypi.py script, and a pyenv_setup.py. The .python-version file pins a specific interpreter for development.

Where rinohtype is the wrong tool

The first wrong-tool case is a team that needs a maintained toolchain. A documentation build that breaks when Sphinx or Python releases a new version, and where the fix depends on one person noticing an issue tracker, is a different risk profile from LaTeX with a distro package manager. The project itself names dependency-version churn as the thing it needs help with.

The second case is a team that needs the typographic refinements the TODO list names. Knuth-Plass line breaking is how you get even word spacing in justified text, and widow and orphan handling is how you keep a single line of a paragraph alone at the top or bottom of a page. If your output goes to print or to a customer-facing PDF where uneven spacing is noticed, the absence of these is a visible quality gap rather than a nitpick.

The third case is mathematics. Equation rendering is available, but only through the separate math extra with ziamath and cairosvg, which is a different rendering path from the text layout engine rather than an integrated one. For a scientific manual where equations are the point, that distinction is worth checking before you commit.

The alternative approach, and the one most teams already have, is the Sphinx LaTeX builder with a LaTeX toolchain. The difference in approach is fundamental rather than incremental. LaTeX delegates typesetting to a mature, decades-old engine whose line breaking and hyphenation are the reason it won the field, and it gives you fine control through macros you have to learn. rinohtype replaces that with a Python layout engine and a CSS-like style sheet, which is easier to learn and easier to theme, and which produces PDF without any system packages. If you already have a working LaTeX pipeline and the layout is good enough, rinohtype is a rewrite with a quality risk attached. If you are starting from scratch and want styling without learning macros, the trade runs the other way.

Editorial conclusion

rinohtype suits a documentation team that wants PDF output with fine typographic control, including OpenType features and CSS-style customization, and that is willing to accept a beta tool maintained by one person. It does not suit a team that needs a stable, heavily maintained toolchain, or one that requires the equation and advanced line-breaking features the project lists as still to be done. Before adopting, render one representative document with the rinoh command and compare it against your LaTeX output, and check whether the AGPL-3.0 licence fits how you intend to distribute the result.

Frequently asked questions

Official sources

1. brechtm/rinohtype on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases