Font with Built-In Syntax Highlighting
Overall reaction
- Many commenters are delighted by the creativity; repeatedly described as “wild”, “ridiculously smart”, and a “wonderful abuse” of OpenType.
- Others see it as a “horrible hack” or “atrocious” in principle, but still impressive as an experiment.
- Several predict niche but real adoption (e.g., blogs, CMS textareas, presentations), and joke about big tools rushing to add it.
How it works and expressiveness
- Uses OpenType contextual alternates (
calt) plus color glyph tables (COLR/CPAL) to recolor glyphs based on surrounding characters. - Clarification that
colris not an OpenType layout feature, andcaltis usually on by default; the CSSfont-feature-settingsline is mostly unnecessary. - Base rule system is simple: match single characters or character classes in context.
- Multiple commenters argue it’s more powerful than the article suggests: you can effectively drag a finite-state machine along via chained substitutions (including reverse chains), allowing regular-language–level logic.
- Concrete examples show how to implement quoted-string highlighting and escaping purely with substitution rules.
Performance and behavior
- One informal benchmark on ~20k lines of CSS: enabling
caltmade a font-size change reflow take ~1.6s vs ~100ms withcaltoff. - Large documents feel laggy when layout depends on heavy shaping, since it affects scrolling, resizing, and selection.
- Some browser bugs/quirks noted (partial highlighting in Chromium when typing, Safari regressions for COLR support in certain versions).
Tooling and automation
- Font editors mentioned: Glyphs (with Python scripting), FontForge (harder UI), emerging browser-based tools; any editor that allows manual OpenType feature code can, in principle, support this.
- Ideas to:
- Generate fonts automatically from grammars (e.g., TextMate, tree-sitter) and color themes.
- Embed fonts via base64
@font-face. - Build an online generator for “syntax-highlighted fonts”; blocked somewhat by tooling (e.g., opentype.js missing
caltsupport).
Use cases, strengths, and limitations
- Big advantages: no JS, no DOM span explosion, works in plain
<textarea>, can be used wherever only a font is configurable (e.g., Notepad, terminals in future, some PDFs/editors with OpenType support). - CSS
@font-palette-valuesandfont-palette(withoverride-colors) allow recoloring without regenerating the font, at least in supporting browsers. - Major limitations:
- Not language-aware enough for full IDE-grade highlighting: keywords inside plain prose, strings, or embedded languages can be miscolored.
- No bracket-depth coloring; hard to robustly handle multi-line comments/strings given limited context and partial repaints.
- Needs different fonts (or variants) per language and, in some environments, per background/theme.
- Some see it as neat but impractical compared to traditional highlighters or CSS Highlight API; others argue it’s perfect for static publishing where any JS is undesirable.
Security and broader implications
- Several note this illustrates why fonts are a real attack surface: they can embed complex behavior; past font-related exploits are cited.
- One commenter refuses to load the demo out of concern about malicious ligature logic.
- The project prompts broader appreciation of how overpowered font technology is (e.g., prior work like games or even LLMs embedded in fonts).