googlefonts/Inconsolata: Building the Code Font Family

What Inconsolata Changes in Code-Facing Typography

Inconsolata addresses the need for a readable monospace face in code listings and text editors. It was originally created by Raph Levien, and this repository is the Google Fonts development home for the family rather than a general-purpose application or font-management service. The documented supported glyph set is GF Latin Pro, so the project is aimed primarily at Latin script text that appears in programming environments.

The family also addresses a narrower typography decision: whether programming operators should be drawn as joined ligatures. Inconsolata contains ligatures for a small set of JavaScript operators. Its regular family exposes them through the discretionary ligature feature, `dlig`. That makes the behavior opt-in. Ligconsolata exposes the operator ligatures through the ordinary `liga` feature, which the README says are enabled by default. For a text editor, the project documentation explicitly directs users toward Ligconsolata.

The v3.000 release expanded the main family to a two-axis variable font. Its width axis runs from 50 to 200, while its weight axis runs from 200 to 900. This gives downstream applications a compact font family with more dimensional coverage than a single fixed-width design. It does not mean every exported file has the same feature behavior. The Ligconsolata variant is separate, and the README says it had not yet been upgraded to version 3.000 because the non-ligature variants were the priority.

Glyphs Sources, Variable Axes, and Export Flow

The editable source is `sources/Inconsolata-vf.glyphs`, which uses the Glyphs source format. The repository also contains Python build helpers, generated font files under `fonts/`, and the pinned packages required by the build. Based on the repository layout, this is a font production project with several export routes rather than a runtime library despite the reported primary language being Rust.

The main build has a manual preparation stage. A contributor must load `sources/Inconsolata-vf.glyphs` in Glyphs, run `decompose-transformed-components.py`, run `gen_instances.py`, and run `inco_fix.py`. The edited source must then be saved as `prod.glyphs` in the sources directory. These are not incidental steps. The `inco_fix.py` script detects problematic varying components and decomposes them so the source can be exported through `fontmake`. It also decomposes corner components because the documented `fontmake` version does not support them.

The prepared file is fed into the build script from the `sources` directory. Based on the documented workflow, this path is intended to produce the complete family and its post-processed outputs. The README states that a full build takes approximately 25 minutes. Contributors should therefore expect a slow local process and should not treat the repository as a rapid command-line font compiler.

For variable output outside that complete family workflow, the documented `fontmake` command accepts the original variable source and writes variable fonts. For static OpenType output, another invocation targets OTF, while a separate invocation enables automatic hinting for TTF. These commands have specific format flags and should not be substituted for one another. The README also states that the variable font in `fonts/` is slightly smaller than one exported directly from Glyphs.

Setting Up the Build Environment and Producing Fonts

The documented setup creates a Python virtual environment and installs the exact dependency set from `requirements.txt`. This approach is preferable to installing newer packages one at a time because the repository pins versions for `fontmake`, `fonttools`, `gftools`, `glyphsLib`, and their supporting libraries.

Run these commands from the repository root. The reader should see the virtual environment created and its packages installed without dependency resolution errors.

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Before using the complete build, open `sources/Inconsolata-vf.glyphs` in Glyphs. Run the three documented scripts in the stated order: `decompose-transformed-components.py`, `gen_instances.py`, and `inco_fix.py`. Then save the result in the `sources` directory with the filename `prod.glyphs`. The README does not provide command-line invocations for those scripts, so a successful reproducible build still requires the manual Glyphs stage.

Once `prod.glyphs` exists, enter the `sources` directory and run the build script. The working directory matters because the README explicitly says the script must be run from there.

cd sources
sh build.sh

The documentation says the family takes approximately 25 minutes to build. A contributor changing the source should keep the unprocessed Glyphs file editable in version control. The repository intentionally does not check in the result of `inco_fix.py`, because decomposing components can reduce editability and a future `fontmake` or Glyphs release may handle the original constructs directly.

Using Operator Ligatures in a Web Font Stack

For web use, the first decision is which family to load. Inconsolata keeps operator ligatures behind `dlig`, so a stylesheet must request discretionary ligatures explicitly. This is useful when the same font file should preserve conventional operator rendering unless the page opts into joined forms.

The README gives the following CSS declaration:

font-variant-ligatures: discretionary-ligatures;

Applying that declaration to text using the Inconsolata family enables access to the discretionary operator ligatures, subject to browser and platform font-feature support. The README notes that they are disabled by default and may not appear in an editor.

Ligconsolata takes a different route. It exposes those glyphs through `liga`, and the documentation says they are enabled by default. That behavior makes it the README's recommended family for a text editor, assuming ligatures are wanted for JavaScript operators. Neither choice changes all typography globally. Users who dislike joined operators, require exact visual separation, or work with code in which those sequences are not intended as ligatures should retain the default Inconsolata behavior and avoid enabling `dlig`.

The version boundary matters before adoption. Version 3.000 describes the two-axis family, but the README explicitly says Ligconsolata had not yet been upgraded to that version. A project that requires both the v3.000 axes and default-on ligatures would need to inspect the committed files and confirm that no single artifact provides both promises.

Choosing fontmake Exports or Glyphs Exports

The repository documents two real approaches. `fontmake` is the scripted path and suits contributors who want reproducible command-line generation. Glyphs export is the preferred path for Ligconsolata because of a concrete tooling limitation: the documented `fontmake` invocation does not respect the "Rename Glyphs" custom parameter for the two Ligconsolata instances. As a result, those generated instances do not receive the intended `liga` behavior.

For a variable font, the repository gives a direct command:

fontmake -g sources/Inconsolata-vf.glyphs -o variable

For OTF instances, the target format is `otf`. The `-i` flag requests instance generation. For TTF instances, the same instance-oriented path adds `-a` for automatic hinting.

fontmake -g sources/Inconsolata-vf.glyphs -i -o otf

fontmake -g sources/Inconsolata-vf.glyphs -i -o ttf -a

The source contains 15 useful instances, including every weight at width 100 and the masters. Running `gen_instances.py` expands that set to 72 combinations: weights from 200 through 900 crossed with widths 50, 70, 80, 90, 110, 120, 150, and 200.

Glyphs remains the better route when Ligconsolata output matters. The documentation says TTF and OTF exports should be directed into `fonts/ttf` and `fonts/otf`. TTF exports should use Glyphs' Autohint option. OTF exports should enable Remove Overlap and Autohint, disable Save as TTF, and use `$REPO_PATH/fonts/otf` as the destination. This is not a generic preference for one GUI. It is required by a documented `fontmake` gap involving ligature renaming.

Build Constraints, Maintenance, and OFL Implications

The largest adoption constraint is the build pipeline's age and specificity. `requirements.txt` pins packages such as `fontmake==3.2.0`, `fonttools==4.31.2`, `gftools==0.9.4`, and `glyphsLib==6.0.4`. Installing these into a current shared Python environment may conflict with other work. The documented virtual environment isolates them, but it also means maintainers must assess compatibility of the pinned toolchain with their current operating environment.

The source workaround is another limitation. Inconsolata uses varying 2x2 components that trigger a known problem in both `fontmake` and Glyphs export, according to the README. `inco_fix.py` exists to decompose the affected components. Corner components must also be decomposed because the documented `fontmake` lacks support for them. This workaround may become unnecessary in a future release, but no removal is documented, so source contributors cannot safely skip it.

The repository is not archived, and its last push was on 2026-06-16. That is recent enough to avoid the prohibition on describing it as actively maintained, but recent repository activity does not erase the maintenance burden of the pinned tools or the Ligconsolata version gap. Upgrade work may involve Python dependencies, `fontmake`, Glyphs behavior, component handling, and generated font files rather than a small application release.

The font is licensed under the SIL Open Font License, Version 1.1. The repository includes `OFL.txt`, so redistribution and modification questions can be checked against the license text shipped with the project. This article does not interpret the license or provide legal advice. The documented future subset for Vietnamese coverage is directly tied to line-spacing behavior in older terminals and editors that do not understand the "use typo metrics" flag, so consumers should verify artifact selection rather than assume every future subset is interchangeable.

Editorial conclusion

Adopt the committed Inconsolata fonts when code-oriented monospace typography and operator ligatures are requirements. Do not adopt this repository as a turnkey build system if Glyphs, manual source preparation, or the pinned Python environment is unacceptable. Check the Ligconsolata version status first, because the README says it had not been upgraded to version 3.000, then confirm which ligatures and output formats your editor actually needs.

Frequently asked questions

Official sources

1. googlefonts/Inconsolata on GitHub
2. License: OFL-1.1
3. Project website
4. README
5. Releases