Junicode 2: a rebuilt font for medievalists and searchable text

What Junicode 2 is for

This repository is the development and distribution site for Junicode 2, described as a radically rebuilt version of the widely used free font for medievalists, linguists and specialists in many academic disciplines. The previous series is not gone: Junicode 1.003, the last release in the Junicode 1 series, can also be downloaded from the same place.

The audience is stated, and it is narrow in a useful way. The people who need this font are working on medieval texts, on linguistic corpora, on manuscript transcriptions and on the scholarly apparatus around them, which means text that mixes Latin with Greek, with transliteration, with combining marks, with medieval abbreviations and with the occasional character from a manuscript tradition that no general purpose font covers.

The compliance claim is the headline. Junicode 2 features full compliance with the recommendation of the Medieval Unicode Font Initiative, version 4.0, plus later additions and revisions. For a field where a character means a specific editorial decision, agreeing on a single mapping recommendation is worth more than any amount of individual preference, and the font is built around it.

The second half of the design brief is less usual for a scholarly font. The OpenType programming has been rebuilt with a view to promoting accessibility and searchability in web pages and other electronic document formats. That is the part that makes Junicode 2 different from a character set with better coverage.

Five weights, five widths, one character set

The face architecture is described as a list, and each item is a design decision rather than a feature list.

The font has the same character set in all faces, unlike Junicode 1. That single change removes an entire category of surprise, where a bold weight quietly lacks a character and the renderer substitutes a fallback from another family. Five weights are provided, Light, Regular, Medium, Semibold and Bold, and five widths, Regular, SemiCondensed, Condensed, SemiExpanded and Expanded.

There is also a ttf-flavored variable font with three axes: width, weight and the custom Enlarge axis. The Enlarge axis is unusual enough that the project publishes a separate introduction to it explaining what it is for and how to use it, which is a good sign about how seriously the axis is meant to be taken.

Beyond the axes, the rebuild brought improved outlines, an expanded collection of small caps covering all case-paired characters, a more comprehensive set of anchors for mark positioning, and an expanded collection of OpenType features that the README says were carefully chosen and organized to promote the display of accessible text.

That last clause is the interesting one. Small caps covering all case-paired characters is a scholarly requirement, because a small cap for a character that has no uppercase form is a gap in a text, and anchors for mark positioning determine whether a combining diacritic sits on the base letter instead of floating beside it.

Upgrading from Junicode 1 will reflow your documents

The README contains a warning for users of the various Junicode 1 versions, and it is the most practically important paragraph in the file for anyone with an existing archive.

Documents originally set in Junicode 1 may reflow when set in Junicode 2. Further, documents that use the OpenType features of Junicode 1, aside from basics like kerning and standard ligatures, may not be displayed properly when changed over to Junicode 2.

Two distinct problems, and the second is the nastier one. Reflow is a layout change: improved outlines and different metrics mean line breaks move, and a book that was set to a page grid now falls out of it. That is annoying but it is visible and fixable in the typesetting pass.

An OpenType feature that no longer resolves is different, because the text still looks set while meaning something else. A specialised historical ligature or a custom substitution that the reader depended on simply stops being applied, and the failure is silent unless somebody compares the two versions line by line.

The practical consequence is that a Junicode 2 migration is a re-typesetting project, not a find and replace. For a corpus that has to be archived in a fixed layout, the Junicode 1 files that are still downloadable from the same site remain the safer choice.

Download from the source, not from a font reseller

The latest version of Junicode can be downloaded from the project's releases page, and then the README issues a warning that is worth repeating in full because it is unusual to see in a font project.

A great many commercial websites offer versions of Junicode. The fonts offered by these sites are always seriously out of date, and they are often accompanied by incorrect licenses or other faulty information, and the packages they offer are often incomplete. The README goes further: if the archives in which these fonts are packaged are corrupt or infected with malware, that is not the responsibility of Junicode's developer. It advises always using versions downloaded from this site or from reputable Open Source repositories like Homebrew, Linux distributions, or CTAN, and states that the site will not support versions of Junicode downloaded from commercial websites.

For a project whose output is embedded in books, articles and web pages, that is a supply chain statement, not a copyright aside. A font file is executable content in the sense that it is parsed by a rendering stack, and a font redistributed in a bundle that also carries a licence file is exactly the shape of thing that goes wrong.

The practical advice is short. Use the releases page on the project's own repository, or a distribution package manager, and treat a font that arrives with a licence file and a version number nobody can match as suspect.

The companion resources explain the unusual parts

The project publishes more than binaries, and the extras are where the design decisions are documented.

There is a specimen page, a discussion forum on the repository's own discussions area where queries about Junicode and how to use it can be posted, an essay on making searchable and accessible texts with Junicode, an introduction to the Enlarge axis covering what it is for and how to use it, and a test and demonstration of high-level CSS font properties in Junicode 2.

That last item is a clue about the direction of travel. High-level CSS font properties mean the browser is doing the work, not the typesetter. A font that ships with features the browser can switch on is a font that behaves in a document viewer the way the author intended, rather than one that depends on the application honouring a particular feature set.

The searchable text essay is the companion to that. In scholarly work the same document often has to be read as an image facsimile and as a searchable text, and the two have different demands: one wants a facsimile, the other wants encoding, small caps that can be distinguished from lowercase, and mark placement that survives copying into a database. The repository also holds an EnlargedAxis.html page, a Junicode-2-feature-test.html page, a Searchability.html essay, doc/, TeX/, sources/, current/, pua2ot/ and webfiles/ directories, and OFL.txt at the root.

The pua2ot/ directory is worth noticing for what it implies about scope: a private use area to OpenType conversion utility belongs in a font that wants to be usable with tooling rather than only in a desktop publishing application.

Building the font from source

The build documentation is unusually complete, which is unusual for a font project and useful if you need a custom cut.

You need a Python environment with version 3.10.4 or higher, and a list of open source applications: fontmake and glyphspkg and psautohint, each installed with pip, xgridfit for hinting ttf fonts, ttfautohint for hinting static ttf fonts, and various utilities that should already be installed on Mac OS and Linux systems, the Bash shell, xsltproc, sed, mktemp and basename.

The Bash script build_font must be run once for roman fonts and again for italic. It creates two directories, build, a temporary directory which will be replaced next time the script is run, and dist, where it places the finished fonts. The script has to be executable and run from the command line.

The three build flavours are selected by argument: no argument or ttf creates a collection of static ttf fonts, otf creates otf fonts, and variable creates TrueType-flavored variable fonts.

The options are documented individually. -r builds roman fonts, which is the default, and -i builds italic fonts. -n skips hinting. -s produces a minimal set of fonts or instances, Regular, Italic, Bold and Bold Italic. -u skips the step of replacing the build directory and uses previously generated UFOs in it. -d takes a source directory with a default of ./, -b a build directory defaulting to ./build, and -o an output directory defaulting to ./dist.

The Makefile in the repository root is a much smaller thing, and it is not the full build.

all:
	fontmake -g Junicode-width.glyphs -i -o otf
	fontmake -g Junicode-Italic.glyphs -i -o otf

install:
	mkdir -p /usr/share/fonts/opentype/juniusx
	cp */*.otf /usr/share/fonts/opentype/juniusx

clean:
	rm -rf *_ufo/

The all target runs fontmake twice over the roman and italic glyph sources, the install target copies the resulting otf files into /usr/share/fonts/opentype/juniusx, and clean removes the generated UFO directories. The font folder name, juniusx, is a leftover from an earlier name of the project, which is the sort of detail that only shows up in a Makefile.

Where a rebuilt scholarly font is the wrong answer

The first case is a project that simply needs a Unicode text face. Junicode 2 carries a large character set and a variable font with three axes, and none of that helps if your text is Latin, Greek and Cyrillic and the system font is fine. The cost of the wrong choice is file size, and the benefit of the right one is coverage you do not have.

The second case is an archive that must keep its exact layout. As the README warns, documents set in Junicode 1 may reflow in Junicode 2, and specialised OpenType features may stop applying. If you have thousands of typeset pages to re-issue unchanged, the migration cost is a re-typesetting project, and the Junicode 1 files, still downloadable from the same site, are the right call.

The third case is a project that does not need the axis system or the MUFIs. The Enlarge axis and the width axis exist for a scholarly typography need, and using a font with those axes means handling them, deciding on instances, and accepting the file size that comes with a family of 25 static faces plus a variable font.

The alternative worth naming is a general purpose Unicode family, which covers the common scripts and nothing beyond, with no MUFI mapping and no medievalist specific features. The difference in approach is the whole story of this project: Junicode 2 starts from an editorial mapping recommendation and rebuilds the OpenType programming around accessibility and searchability, rather than starting from a set of common characters and adding features later.

Editorial conclusion

Junicode 2 suits a scholar, editor or typesetter who needs the medievalist character coverage and the Medieval Unicode Font Initiative mappings, and who cares about how the text behaves in a browser or a screen reader. It does not suit a project that merely needs a working Unicode text face, nor a publisher with an archive of Junicode 1 documents that must keep their exact line breaks. Verify first whether the characters and the OpenType features your documents use survive the switch, and download the fonts from the project's own releases or from a reputable repository rather than from a commercial font reseller.

Frequently asked questions

Official sources

1. Issues
2. License: OFL-1.1
3. psb1558/Junicode-font on GitHub
4. README
5. Releases