franktisellano/datatype: Inline charts through OpenType ligatures

What Datatype replaces

Datatype addresses a specific publishing problem: a small piece of data needs to appear beside prose, but adding a chart library or a JavaScript drawing layer would make the document heavier and less portable. The project turns text such as `{b:30,70,50,90}` into a visual chart through OpenType ligature substitution. That means the data remains expressible as ordinary text in the source, while a font-aware renderer displays a glyph sequence instead of the literal characters.

The intended users are designers, documentation teams, dashboard authors, and developers building interfaces where a small trend or distribution fits inside a sentence. A sentence can contain a trend graphic without a separate chart container, SVG element, or runtime chart dependency. The repository presents bar charts, sparklines, and single-value pie graphics, so its scope is decorative and editorial data visualization rather than a general chart library.

The approach is especially relevant to content that must be copied between applications. The font can be installed on macOS, Windows, or Linux, and applications that support OpenType ligatures can display the expressions. The tradeoff is equally important. A chart is only available when the Datatype font is active, the application preserves the font features, and the user has not disabled ligatures or contextual alternates.

The syntax-to-font substitution path

Datatype uses OpenType features named `liga` and `calt`. The README identifies standard ligatures and contextual alternates as the relevant mechanisms. In practical terms, the source text remains a compact expression, while the font maps the matching character sequence to a designed chart glyph or glyph sequence. No JavaScript is required for that substitution.

Bar expressions begin with `{b:` and accept comma-separated values from 0 to 100, with as many as 20 bars. Sparklines use `{l:` and accept the same value range and count limit. Pie expressions use `{p:` followed by one percentage, such as `{p:62}`. The values are not passed to an application API. Their meaning is defined by the glyph design and substitution rules in the font.

The font has two variable axes. `wdth` ranges from 50 to 150 and changes spacing, with a default of 100. `wght` ranges from 100 to 900 and changes line thickness, with a default of 400. This gives the same chart syntax different density and emphasis without requiring separate chart artwork. The project also supplies 15 static instances, including condensed and expanded width combinations.

The repository layout shows that the font is assembled by Python scripts in `sources/`, using fontTools. The listed glyph count is 10,850 per master across nine masters. These figures describe the generated font design, not the behavior of a runtime chart engine.

Browser embedding and first inline chart

For web use, the README recommends loading the variable WOFF2 file and applying the font to a chart container. The `font-face` declaration exposes the full weight and stretch ranges, while `font-variation-settings` selects the default axes for the example. The browser then performs the same font substitution used by the desktop font.

The following HTML is the README's web example. It places a sparkline between words, so the expected visible result is the sentence with a small line chart replacing the expression `{l:20,45,60,55,80,95}`.

<!DOCTYPE html>
<html>
<head>
  <style>
    @font-face {
      font-family: 'Datatype';
      src: url('Datatype.woff2') format('woff2');
      font-weight: 100 900;
      font-stretch: 50% 150%;
    }

    .chart {
      font-family: 'Datatype', sans-serif;
      font-variation-settings: 'wdth' 100, 'wght' 400;
    }
  </style>
</head>
<body>
  <p class="chart">
    Sales this quarter {l:20,45,60,55,80,95} are up significantly.
  </p>
</body>
</html>

Serve the page with the font file at the path used by `url('Datatype.woff2')`. If the font file cannot load, or if the browser or surrounding application disables OpenType features, the literal expression remains visible. The README lists support for variable fonts in Chrome 62+, Firefox 62+, Safari 11+, and Edge 17+, and says modern browsers support the needed OpenType features.

Installing Datatype on desktop systems

Desktop users do not need the Python build process to use the released font. The README directs users to download font files from the Releases page and copy TTF files into the platform font directory. Ligatures and contextual alternates must then be enabled in the target application.

The documented destinations are `~/Library/Fonts/` on macOS, `C:\Windows\Fonts\` on Windows, and `~/.local/share/fonts/` on Linux. The desktop workflow is therefore a file installation followed by use in an application that supports OpenType ligatures. Adobe applications require enabling ligatures through the Character panel's OpenType controls.

The source build is aimed at contributors and maintainers. Python 3.9 or later and pip are required. Installing the pinned build dependencies can be done with the following command, taken from the repository instructions.

pip install -r requirements.txt

The standard build creates a variable font and 15 static instances. For faster development output, the README also documents a default-only variant.

python sources/build.py

python sources/build.py --dev

The build produces `fonts/variable/Datatype[wdth,wght].ttf`, `fonts/variable/Datatype[wdth,wght].woff2`, static TTF files under `fonts/ttf/`, and static WOFF2 files under `fonts/webfonts/`. The documented WOFF2 variable file is about 73 KB, while the TTF is about 4.0 MB. These are generated outputs, so users normally download released files instead of running the build.

Limitations of a font-based chart

Datatype is the wrong tool when a reader needs axes, labels, tooltips, filtering, zoom, or interactive selection. Its syntax supports a short sequence or one percentage, and the README caps bars and sparklines at 20 values. There is no documented API for hover states, click events, legends, gridlines, or multiple series. Those capabilities belong in a conventional charting component or a server-rendered visualization.

Font substitution also depends on the entire rendering chain. A browser may support the font format while an editor, CMS, email client, export pipeline, or mobile application strips or disables `liga` and `calt`. A copied expression can therefore appear as text in one environment and as a chart in another. Applications that substitute fonts or normalize content can also prevent the intended glyph mapping.

The visual range is deliberately narrow. Changing `wdth` adjusts spacing, and changing `wght` adjusts line thickness, but the project does not document axes for color, scale, baseline, or chart semantics. This makes Datatype useful for compact inline communication, not a replacement for a full visualization system. It is also not a data transformation layer. Values must be formatted within the supported 0 to 100 range before they are written into the text.

A second constraint is the size difference between formats. The README describes a 4.0 MB TTF and a roughly 73 KB WOFF2 variable file. That makes WOFF2 the sensible web delivery format, but desktop workflows may need the larger TTF. The project does not document a browser strategy for automatically falling back to static files when variable fonts are unavailable.

Datatype versus a conventional chart component

The practical alternative is a JavaScript chart component such as a dashboard library, or a server-generated SVG chart embedded in the page. That approach can provide labeled axes, tooltips, responsive resizing, legends, multiple series, and interaction. It also introduces a runtime dependency and requires code to manage the data and rendering lifecycle.

Datatype takes the opposite approach. The data is written directly into text, and the font performs substitution during text layout. That keeps the document self-contained from a chart-code perspective and allows a chart to sit inside a sentence. The cost is reduced expressiveness and dependence on font support. A conventional chart is easier to choose when the data model changes frequently or when readers need to inspect exact values.

For static publishing, an SVG image is another alternative. SVG can be styled with CSS and scaled precisely, but it does not turn ordinary text into a chart and generally requires separate generation or authoring. Datatype is more convenient when the author wants to keep chart expressions in editable copy. It is less convenient when the chart needs independent layout or interaction.

The comparison also affects accessibility. The README does not document accessible names, data tables, screen-reader labels, or high-contrast behavior for the generated charts. The source expressions may remain in the document text, but the repository does not specify how assistive technology should announce the substituted visual. Teams with strict accessibility requirements should verify this before using the font for essential information.

Maintenance, upgrades, and the font licence

The repository is not archived. Its last push was on 2026-05-02. Recent release records include v1.2.2 on 2026-02-23, v1.2.1 on 2026-02-19, and v1.2.0 on 2026-02-18. The release history shows recent version activity, but it does not provide a promise about future releases or compatibility.

Upgrading a font can affect text layout because a new build may change glyph substitutions, metrics, or the generated file set. Contributors are told to test changes with `python sources/build.py`, while users can download TTF or WOFF2 files from Releases. The build uses pinned dependencies, including `fonttools[woff2]==4.60.2`, `brotli==1.2.0`, `watchdog==6.0.0`, and `websockets==15.0.1`. Rebuilding with a different dependency set is not documented as a supported upgrade path.

The repository metadata classifies the license as other, while the README and repository structure identify `OFL.txt` as the SIL Open Font License 1.1. This is a source-level licensing point, not legal advice. Anyone distributing the font should inspect `OFL.txt` and the accompanying attribution files directly. The custom classification and the stated OFL terms should be resolved for the intended distribution context before the font is embedded in a product.

Editorial conclusion

Adopt Datatype when the chart is a compact inline accent and the target applications support OpenType ligatures. Do not choose it for a conventional dashboard, complex chart interactions, or environments that strip font features. Verify the relevant font format, ligature support, axes, and the licensing text in OFL.txt before shipping the font.

Frequently asked questions

Official sources

1. franktisellano/datatype on GitHub
2. Issues
3. README
4. Releases