Font with Built-In Syntax Highlighting

Original Article ↗ Hacker News Discussion ↗

A novel programming font uses OpenType contextual alternates and color glyphs to perform syntax highlighting entirely inside the font itself, so plain text in a browser or terminal appears highlighted without JavaScript, extra HTML tags, or external libraries. Commenters explore how far this technique can be pushed—suggesting generators that take grammars and color themes to output custom fonts, ways to carry parser-like state through substitution rules, and CSS tools like `override-colors` for theming. Others point out limitations around performance, imperfect parsing (e.g., strings and comments), configurability, and security risks inherent in complex font rendering, concluding that it’s an ingenious but niche alternative to traditional highlighters.

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 colr is not an OpenType layout feature, and calt is usually on by default; the CSS font-feature-settings line 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 calt made a font-size change reflow take ~1.6s vs ~100ms with calt off.
  • 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 calt support).

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-values and font-palette (with override-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).