Cozette: a 6x13 bitmap font whose vector version is declared unsolvable

It is six by thirteen pixels, and the metrics are printed

The About section opens with a font specification rather than an adjective, and it is worth quoting in full because it removes the most common source of disappointment with a small bitmap font.

The bounding box is thirteen pixels high and six wide. The average character is five pixels wide, with three pixels of descent, ten of ascent and eight of cap height.

So you know what you are getting before you install it: a font whose caps are eight pixels tall. That is the single number that decides whether a font is usable for you, and this project prints it in the second sentence.

The lineage is equally explicit. The font is based on another bitmap font, which is itself based on an older one, and it is also heavily inspired by a third. The author says he used that third font until a higher-resolution screen made it slightly too small, and that this prompted him to make the font he had always wished existed.

That is a small origin story with a useful moral: the design target was a specific person's screen at a specific size, and the readme is honest that the coverage is the author's terminal work rather than a claim about yours.

The vector version is auto-generated, and the author has given up on it

This is the most valuable paragraph in the readme, and it is a refusal rather than a feature.

The font ships in three shapes: normal and doubled-for-high-density bitmaps in four formats, and a vector format. The readme says the vector formats are provided as a compatibility feature, and that rendering of vectorised bitmap-like fonts is, in the author's word, terrible on virtually all operating systems.

Then the instruction that follows a bad installation: if the font looks awful on your system, you probably have a vector version, and please use the bitmap format if you can.

And then the commitment: issues with the vector formats will almost certainly not be fixed or addressed. The font is a bitmap font first and foremost, and the readme calls building a font from a single source that looks good both as a bitmap and as an auto-vectorised format on every operating system an unsolved problem.

That last sentence is the one to keep. It tells you the author tried, that the failure is a general one about hinting and rasterisation rather than a bug in this project, and that further reports about the vector format will be closed by that reasoning rather than investigated.

The tree confirms the mechanism: the vector is derived from the bitmap by a build script, so the two cannot diverge in content, only in rendering.

Supported sizes are listed per system, including the awkward one

Font scaling is said to vary wildly between systems, sometimes between programs and even between formats, and then the author gives measurements rather than advice.

On his own system, the bitmap format looks right at thirteen point. The doubled version looks right at twenty-six point and downscales cleanly to ten. And the vector version does not look right at any size, with a parenthetical that it is technically correct at one size on a hundred-dots-per-inch screen on Linux.

That parenthetical is the most useful sentence in the section. If your setup is exactly that, you have a size. If it is not, you have an admission from someone who has tried more configurations than you have.

The general principle is then stated: bitmap fonts are bitmaps, they scale badly and look sharp and pixel-correct at one specific point size, while vector fonts scale well and here would look wrong at small sizes because of antialiasing.

So the guidance reduces to two lines. Use the bitmap at thirteen point if you can control your terminal's size, and if you cannot, accept the vector knowing that its problems are documented and unaddressed rather than unknown.

Windows gets the format the readme calls terrible

The platform instructions are short, and the asymmetry between them is the story.

On Linux the preferred format is the bitmap one, with the vector named as an alternative, and installation means putting the file in a fonts directory. Two named community members have packaged it for Void and for Arch, each with a single command:

$ yay -S cozette-otb

On macOS you download a font file and open Font Book, and the readme says both the bitmap and the vector should work there.

On Windows the instruction is to take the vector file, with a link for the bitmap versions if you want to make those work.

So the platform where the author considers the vector format broken is the platform where the vector format is the documented recommendation. The bitmap route exists there, but it is behind a link to someone else's instructions rather than a set of steps.

Two smaller notes from the same section. On Ubuntu, enabling bitmap fonts is a distribution setting rather than a font setting. And under a heading for other systems, the readme says you know what you are doing.

One major terminal refuses bitmap fonts, and the readme documents the workaround

There is a whole subsection for a single terminal emulator, and it is the most practically useful part of the application notes.

A third party built a package repository entry for that terminal patched to accept bitmap fonts. The readme links the patch as well as the package.

And then it quotes the terminal's own author, who is unambiguous: the terminal does not, and never will, support bitmap fonts.

So the advice is a ladder. Use the patched package. Or apply the patch yourself. Or, if that fails, set two properties in the font configuration system: a spacing value of a hundred and a scalable flag set to true, which the readme says should be enough for the terminal to accept the font. And if that still fails, the last suggestion is to stop using that terminal, which the text was in the middle of saying when the copy here stops.

That is a font whose most popular terminal needs a patch, handled with four rungs and a link at each one.

The other application notes follow the same pattern: where spacing goes wrong in a launcher and a terminal multiplexer, try the size-suffixed font name rather than making the font the system default, which the author advises against because many applications have problems with bitmap fonts.

A graphical editor and a build script produce the whole family

The repository is small and its layout tells you how the font is made.

There is a directory holding the font source, a build script, and a separate directory whose name says it builds the font. That pairing matches the readme's own phrase for the vector format, which is auto-vectorised: the bitmaps are the source of truth and the vector is produced from them.

The tool that draws the bitmaps is named in the repository too, in a shell script. It is a bitmap font editor, so the original artwork was drawn by hand in a graphical tool and the vector is a derived artefact rather than a second design.

That is exactly the arrangement the unsolved-problem paragraph describes, and seeing it in the tree explains why the two formats cannot be tuned independently: a change to the bitmap changes the vector, and the author's stated fear is a bitmap that cannot survive that translation on every system.

The rest of the root is build and configuration. There is a Python build script and a directory of build modules, a lockfile for one Python dependency manager and a lockfile for a Nix environment, and a Python project file that contains nothing but two tool configurations.

Two Python dependency managers, and a project file with no project in it

The repository lists a dependency manifest and lockfile for one Python dependency manager, and a Nix flake with its own lockfile. It also has a Python project file.

Open that project file and there is no project table, no build system declaration and no dependencies. It contains two sections: one configuring import sorting with a line length of seventy-nine characters, and one configuring a linter and a formatter with a declared target Python version and the same line length.

So the Python tooling in this repository exists to keep two source files tidy. The font is not installed as a package, and there is nothing to publish to an index; the artefacts are files in a releases tab, and the build is a script.

That is a coherent arrangement for a font project with a two-file build script, and it is also why the readme points people at a releases page rather than at a package name.

One small inconsistency is worth flagging for anyone reading the badges: the licence badge in the readme links into the repository's other branch while the default branch is the main one. The licence file is present in the tree, so the link is a stale reference rather than a missing file.

Editorial conclusion

Cozette fits someone writing code in a terminal who wants one small, sharp font and is willing to read a font-specific note before installing it, which this readme provides generously. Two things to weigh first. The vector variant exists for compatibility and the author says so plainly, so on any platform that cannot render bitmaps you are getting the format he considers broken unless you put in the specific work his application notes describe. And one terminal he uses every day refuses bitmap fonts outright, so the choice of terminal constrains the choice of font. Neither is hidden. The metrics are published, the supported point sizes are named per system, and the failure cases have their own sections.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. the-moonwitch/Cozette on GitHub