Llama.ttf: A font which is also an LLM
A proof-of-concept project embeds a tiny LLM and its inference engine directly into a TrueType font, using HarfBuzz’s experimental WebAssembly shaper so that sequences of characters (like “!!!!!”) are visually replaced by model-generated text. Commenters are fascinated by the creativity and potential UX experiments this enables, but focus heavily on security and complexity concerns around Turing-complete fonts, sandbox robustness, and the risk of deceptive or non-copyable text rendering. Many note that the feature is disabled in mainstream browsers, that similar font and PDF capabilities have long been an attack surface, and that while the hack is impressive, it exemplifies how deeply computation is creeping into ostensibly simple file formats.
Core idea and implementation
- A TrueType font embeds a tiny LLM plus inference engine, using Harfbuzz’s experimental WebAssembly (WASM) shaper.
- Specific character sequences (e.g., runs of
!) are “shaped” into model output at render time; the underlying text data stays unchanged. - This does not use classic TrueType hinting bytecode but a separate WASM shaper path in Harfbuzz.
- The demo model is ~15M parameters (≈60–90 MB font file); a 70B-parameter variant would be ~280–290 GB and is shown only conceptually.
Determinism, UX, and copying text
- Identical generations across apps come from fixed seeding and temperature 0, making inference deterministic given the same input.
- Some suggest input-controlled seeds, regeneration symbols, and letting typed letters override suggestions to act like a custom autocomplete.
- Because only the visual shaping changes, copy/paste returns the original punctuation, not the rendered prose.
- Users note this feels like a built‑in “DRM”: readable but not trivially copiable; OCR (including OS‑level OCR APIs and tools) is proposed as the workaround.
Security, sandboxing, and complexity
- Several posters are alarmed that fonts can execute code at all, citing:
- Long history of font-based exploits and that Windows once parsed TTF in the kernel.
- Increased attack surface: now a WASM runtime is needed just to render text.
- Risks of misleading displays (text says one thing, glyphs show another) for phishing and content scanning.
- Others argue:
- WASM is strongly sandboxed, with limited APIs, and comparable in risk to web JS/WASM.
- Harfbuzz’s WASM shaper is experimental and not enabled in mainstream browsers.
- WASM is preferable to ad‑hoc VMs (TrueType, Graphite2) that already exist in font stacks.
- Concerns remain about DoS, side channels, quotas, and the general “compute-mad” trend of putting Turing-complete layers everywhere.
Typographic and broader implications
- Complex scripts (e.g., Urdu with tens of thousands of ligatures) are cited as justification for powerful shaping logic.
- Some find the project “terrifying” yet “awesome”; others see it as a proof‑of‑concept hack rather than something that should become common.
- Ideas raised include animated or game fonts, Doom-in-a-font, text-adventure interpreters, and model‑per‑font “personalities” for richer UIs.