0xProto: a legibility font whose Makefile uses three variables it never defines

The install steps name two platforms and stop there

Installation is two numbered steps. The first is to download the font files from the releases page at its latest tag. The second is to unzip the archive and install the font, and here the file splits by platform: on macOS you drag and drop the font file to Font Book or another font management app, and on Windows you right-click any of them and pick `Install` from the menu. No third platform is named. There is no line for a Linux package manager, no fontconfig directory, and no note about a package repository, even though the release artifacts include woff2 files produced by the build. A reader on any other system is left to unpack an archive and place the files where the platform expects them. The two links the file gives for obtaining the font also differ: the numbered step points at the releases page for the latest tag, while the Quick Q&A answer points at the releases index with no tag, so only one of the two is pinned to a version. Nothing in the steps offers a checksum or a signature.

The ligature policy reads against the instruction to turn ligatures on

The fourth feature is titled ligatures that don't deform shape, and the argument is that sequences such as `:=` or `=>` function as single logical tokens even though they are two characters on screen, which is the reasoning Fira Code gives. The objection raised is to ligatures that change appearance and meaning together, with `!=` becoming `≠` named as the example, on the grounds that if any part of the string is erased you cannot anticipate the meaning. The stated decision is to abstain from ligatures that modify both meaning and form, and ligature users are pointed to Fira Code. Yet the VS Code section still documents turning ligatures on by setting `"editor.fontLigatures"` to `true`, which is consistent with a font that keeps the shape-preserving ones.

The no-ligatures variant is a build step, not a separate design

The build pipeline explains the distinction the prose leaves implicit. Three Python scripts run against the compiled output: one adds the OpenType stat table to the Regular, Bold and Italic files, one removes `calt` and writes to a directory named `No-Ligatures`, and one builds the alternate-named fonts. So the ligature table that the feature list declines to abuse is still present in the main font and is stripped programmatically for the variant sold as 0xProto NL. The Quick Q&A answers what that variant is in one line, No Ligatures fonts, and points at issue 116 for the reasoning. The same section explains Zx Proto as the same font under a different name and points at a pull request instead. The removal step is handed the output directory and writes to a subdirectory inside it, so the no-ligatures faces land beside the main faces rather than replacing them, and one build yields both families with the choice left to whoever installs. The alternate-name script runs last, after the stat table has been added and the variant split off, so the order of the three steps is doing real work: shared OpenType housekeeping first, then the forks.

Two targets read variables that nothing in the Makefile sets

The variable block at the top of the Makefile defines the font name, the family list of Regular, Italic and Bold, the source and output directories, the scripts directory, and the archive naming pieces. Three variables appear later in the file but are never assigned. Two targets use them:

compile-woff2-roman: $(OUTPUT_DIR)/$(FONT_NAME)-$(MAIN_WEIGHT).ttf $(OUTPUT_DIR)/$(FONT_NAME)-$(BOLD_WEIGHT).ttf

compile-woff2-italic: $(OUTPUT_DIR)/$(FONT_NAME)-$(ITALIC).ttf

Since the assignments are missing, those prerequisites expand to names like `fonts/0xProto-.ttf` that the build never produces. The main path avoids them, because `compile-all` calls `compile-woff2`, which loops over the family list instead. So the damage is limited to anyone invoking those two targets by name, and they are also the only targets in the file not marked `.PHONY` or reached by the build chain.

The build deletes the fonts directory before it writes it

The build target runs three steps in order: it calls `clean`, then `compile-all`, then the three Python scripts. The clean target removes the output directory outright if it exists, and the output directory is the top-level `fonts/` entry in the repository. Since `fonts/` is a tracked directory holding the built faces, the effect is that a contributor's build deletes the committed font files and replaces them with freshly compiled ones, including a new `No-Ligatures` directory and whatever the alternate-name script produces. Nothing in the build restores the previous state, and nothing warns about it, which is worth knowing before running the target on a tree with uncommitted work in that directory.

The archive version defaults to dev, not to the release scheme

Archive naming is controlled by one variable with a default:

ZIP_VERSION ?= dev

The archive name is built from the font name and that value, so a local build produces something like `0xProto_dev.zip` unless the variable is passed in. Meanwhile the published releases are numbered 2.502 on 2026-01-16, 2.501 on 2026-01-06, and 2.500 on 2025-05-24. Those three numbers follow none of the convention the Makefile encodes, so nothing in the build system ties a commit to a release number, and the default of `dev` is the only place the two schemes touch. A contributor therefore has to know the intended version out of band to produce a correctly named archive.

The build package is versioned 0.0.0 and the sources are Glyphs packages

The Python side is a project named `0xproto-build` at version `0.0.0`, requiring Python 3.10 or newer, with fontmake, fonttools, glyphsLib and ttfautohint-py as runtime dependencies and fontbakery in a development group. The version is not connected to the font releases, so neither is the package. The sources are `.glyphspackage` files, which is why glyphsLib is a dependency: the design format is Glyphs, and the build compiles it without needing that application installed. Hinting runs through ttfautohint-py. The woff2 step is separate and heavier, since setup clones Google's woff2 repository with submodules and runs `make clean all` inside it before any compression can happen. Two more things sit in the tree for anyone reading the build. A `uv.lock` is committed, so the dependency versions above are pinned for everyone who syncs, including the development group. And the file ends partway through its last target: the name `install-ot` is present with nothing after it, so whatever install-related step it sets up is not visible in the Makefile as it stands.

Enabling the script variant is a stylistic set and a note

There is one OpenType feature described, the Script Variant, available in the italic family only. It has no settings block of its own, just two links: one to a Visual Studio Code issue and one to a document on enabling stylistic sets. The second link points at Fira Code's own wiki page, and the file adds a correction for that reason, stating that the Script Variant for 0xProto is `ss01`. Italic-only is worth flagging before you plan a typeface around it, since a script face that only exists in one of three shipped weights is a narrower feature than the family list implies.

Editorial conclusion

0xProto is a reasonable choice if you care about letter differentiation and small sizes, and the reasoning behind its ligature policy is stated well enough to argue with. Two things to check before you commit. The install steps name macOS and Windows only, so anyone on Linux is reading a release archive and improvising. And the build system is for contributors rather than users: it clones the woff2 tool from Google and compiles it, it deletes the tracked fonts directory before regenerating it, and two of its targets cannot work because they read variables nothing sets. For an end user the release archive is the whole story, and the last push is dated 2026-03-21.

Frequently asked questions

Official sources

1. 0xType/0xProto on GitHub
2. Issues
3. License: OFL-1.1
4. README
5. Releases