# SILE typesetting with Lua, frames, XML, and PDF output

> SILE is a Lua-based publishing engine for producing PDF documents with frame-based layouts, grid typesetting, and direct XML input. It suits programmers who want programmatic control, but native Windows support remains a documented weakness.

**sile-typesetter/sile** — The SILE Typesetter — Simon’s Improved Layout Engine

- Repository: https://github.com/sile-typesetter/sile
- Website: https://sile-typesetter.org
- Stars: 1,788 · Forks: 107
- Language: Lua
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/sile-typesetter-sile

## The publishing problem SILE addresses

SILE is designed for producing printed PDF documents when a conventional word processor does not provide enough control over page composition. Its intended users include publishers, technical writers, and programmers who are comfortable encoding layout rules rather than arranging pages through a graphical interface. The README describes SILE as a typesetting system and emphasizes complex layouts, frames, grid-based text, and output suitable for print.

The project borrows concepts and algorithms from TeX, but the documentation is explicit that SILE is not a TeX derivative. That distinction matters for teams choosing a document tool. A TeX workflow usually centers on TeX syntax, packages, and its established ecosystem. SILE instead exposes its typesetting system to extension in Lua and presents page composition as a programmable layout problem. The repository also includes inputters, outputters, page builders, shapers, classes, and language components, which reflects a modular engine rather than a single PDF wrapper.

SILE can be installed locally or invoked as a remote CI job. Its published container also supports a self-contained workflow for projects that already keep source files and generated output in one directory. This makes it relevant to automated publishing systems, although the documented CI workflow does not describe rollback behavior, output validation, or deployment orchestration.

## SILE's Lua layout and document pipeline

The most important architectural fact is that Lua is not merely an optional scripting attachment. SILE is written as a typesetting and layout engine that can be extended in a high-level programming language, and the repository is primarily Lua. The top-level directories give the pipeline a visible shape: `inputters/` handles source acquisition, `core/` contains engine behavior, `pagebuilders/` manages page-level construction, `shapers/` relates to glyph arrangement, and `outputters/` produces backend output.

Two documented input paths have practical value. Users can create native SILE documents, while SILE can also process XML directly into PDF without inserting XSL stylesheets. The latter route is different from a conventional XML publishing stack in which an XML processor first generates an intermediate document through XSLT. According to the README, SILE consumes XML and PDF output within its own system. The documentation does not specify every supported XML dialect, so a project should confirm its document model before choosing this route.

SILE also provides frame-based composition and grid typesetting. These features place it between simple document conversion and full page-design systems. The repository contains page builders and shapers, while the documentation explicitly names frames as a way to produce complex layouts. However, the documentation does not expose a small SILE source example that demonstrates frame declarations, so adopters should consult the usage examples for the exact syntax required by their chosen document class.

## Installing SILE and rendering the first document

The shortest documented path on macOS is Homebrew. This installs the latest prebuilt stable release. The package does not install the default font automatically, so Gentium Book must be added separately before a document that depends on it can rely on that font.

```bash
brew install sile
brew install font-gentium-book
```

The README also documents installation through Homebrew from the latest Git commit. That option is intended for users who want a development build rather than the stable package.

```bash
brew install sile --HEAD
```

For a first real invocation, the README provides a Docker alias that mounts the current directory at `/data`, makes input and output available to the container, and runs the `latest` image interactively. Create or obtain a file named `input.sil` in the current directory, then run:

```bash
alias sile='docker run -it --volume "$(pwd):/data" siletypesetter/sile:latest'
sile input.sil
```

The alias adjusts the container user and group IDs to match the mounted directory. That matters because a document processor needs somewhere to write its output. The documentation does not specify the generated filename or provide the source syntax for a minimal page, so neither should be assumed. Use the documented command to render an existing `.sil` source and inspect the PDF emitted into the mounted directory.

Linux users have several package-manager choices. Arch Linux uses `pacman`, Fedora uses `dnf`, openSUSE uses `zypper`, Ubuntu uses its documented PPA, and NixOS has stable and unstable package channels. These are useful when fitting SILE into an existing managed workstation. The container route is easier to isolate, but it does not automatically see host fonts. A Docker deployment must arrange access to fonts through font configuration.

## Docker, native packages, and the build system boundary

The `siletypesetter/sile` image offers tagged release containers, `latest`, and `master`. Tagged release containers are the more predictable choice for a publishing workflow because their names correspond to SILE releases. The `master` tag represents a fresh development build, so it can change independently of published releases. The README's first-use alias selects `latest`, which the documentation identifies as the latest release.

The container uses an Arch Linux base in its `Dockerfile`. It installs runtime dependencies, initializes package keys, prepares LuaJIT-related LuaRocks configuration, separates build dependencies from the final image, and uses a build stage to avoid carrying build tooling into the runtime layer. The repository also contains `Dockerfile`, `CMakeLists.txt`, `configure.ac`, a `Justfile`, a `Makefile`, and Nix files. Those files show several supported build and packaging paths, not a requirement to use all of them.

There is also a Rust build definition in `Cargo.toml`. It declares the `sile` binary and optional Lua runtimes including `lua54`, `lua53`, `lua52`, `lua51`, and `luajit`. The package identifies Rust `1.91.1` as its minimum version. These declarations concern the Rust packaging path; the README still presents SILE as a Lua typesetting project. A build team should treat those layers as related build surfaces rather than assuming that installing Rust replaces Lua extension compatibility.

## Native Windows and font constraints

Native Windows is the clearest rejection case. The README says there is no installer, nobody is currently maintaining Windows compatibility, and the project expects the state to be "a bit broken." It points Windows users toward WSL instead. This is not a minor polish issue in the documentation. It changes the supported operating-system boundary for teams that need a normal native Windows publishing environment.

Early CMake and Visual Studio work exists, but the README says it needs refreshing for current dependencies. Azure build artifacts may include prebuilt binaries from a particular pipeline build, yet artifact availability does not change the stated lack of a maintained Windows installation path. An organization should therefore validate SILE under WSL or in a Linux-based container rather than treating a downloadable build as a supported Windows distribution.

Fonts are the second operational boundary. macOS Homebrew does not install the default font automatically. Fedora documentation calls for additional font packages, and Docker cannot see the host's fonts by default. A successful installation is therefore not proof that a document will resolve its intended typography. Font packages must be installed in the native environment or made visible to the container, and the document's font configuration must be checked separately.

## SILE compared with TeX and containerized command-line publishing

TeX is the most relevant alternative because the README directly compares SILE with it. TeX is the established route for reproducible academic and technical publishing, with TeX syntax and a large body of document classes and packages. SILE borrows some concepts and algorithms but implements a separate engine, supports Lua extension, frames, grids, and direct XML-to-PDF processing. A team whose source and templates already depend on TeX packages should not assume those assets transfer directly.

For teams that only need reproducible command-line PDF generation, a generic containerized document tool may be simpler if it supports their existing source format without Lua customization. SILE becomes more relevant when layout behavior itself must be extended in code. Its repository contains language and class components, making customization part of the project model rather than an incidental plugin layer.

Docker versus native installation is also a genuine choice, although not a competing typesetter. A native package integrates more directly with system fonts and local package management. Docker provides release tags, directory mounting, and an isolated runtime, but requires explicit font access. CI use is documented as a supported execution model. Neither route resolves the absence of maintained native Windows compatibility.

## Maintenance, upgrades, and MIT licensing

The repository is not archived, and the last push was on 2026-10-01. That is current repository activity, but it does not by itself establish compatibility for a particular production deployment. The listed releases are v0.15.13 from 2025-05-31, v0.15.12 from 2025-04-10, and v0.15.11 from 2025-04-10. The version gap between the latest listed release and the later repository push means developers on `master` should not be treated as running the same tested version as a pinned release tag.

Upgrades require attention to fonts, Lua classes or extensions, inputters, page builders, and output behavior. The repository's `package.json` defines `make check` as its test command and `make lint` as its lint command. These are concrete project checks that can form part of an adoption review, although this review did not execute them.

The package metadata and `LICENSE.md` identify the project under the MIT license. The manifest version is `0.15.13`, matching the latest listed release and the Rust package version. The MIT label permits use and modification under its terms, but redistribution, notices, and third-party components still require review by the adopting organization. Font files and extensions may carry separate terms that the top-level SILE license does not replace.

## Conclusion

SILE is appropriate for programmers and publishers who need programmatic document layouts, Lua extensions, or direct XML-to-PDF processing. It is a poor fit for teams that require supported native Windows installations or assume TeX package compatibility. Before adoption, verify that the required fonts, document class, Lua extensions, and target operating system are available, then run the project's `make check` suite in the intended environment.

## FAQ

### How do I install SILE on macOS?

The README documents `brew install sile` for the stable release and `brew install sile --HEAD` for the latest Git commit. Homebrew does not install the default font automatically, so the documentation also lists `brew install font-gentium-book`.

### How do I run a SILE document with Docker?

The documented alias mounts the current directory into the container and runs `sile input.sil`. The container cannot see system fonts by default, so a usable publishing setup must also make the required fonts accessible.

### Does SILE support native Windows?

The README says there is no Windows installer and that Windows compatibility is not currently maintained. It points users to WSL, although CMake and Visual Studio work remains and needs refreshing for current dependencies.

## Sources

- [License: MIT](https://github.com/sile-typesetter/sile/blob/master/LICENSE)
- [Project website](https://sile-typesetter.org)
- [README](https://github.com/sile-typesetter/sile/blob/master/README.md)
- [Releases](https://github.com/sile-typesetter/sile/releases)
- [sile-typesetter/sile on GitHub](https://github.com/sile-typesetter/sile)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sile-typesetter-sile