Noroboto: Lying Fonts y mitigación en Rust — lectura técnica sin hype

Las fuentes no son confiables por defecto. Sí, leíste bien. El subsistema tipográfico puede devolver métricas de ancho, kerning y advance width que no coinciden con el render real — y eso cambia todo lo que pensábamos sobre "solo es texto".

Eso es lo que documenta el proyecto Noroboto: que el stack de fuentes sobre Linux puede mentirte con métricas inconsistentes entre el query y el render efectivo, y que Rust tiene algo concreto que decir al respecto. El problema no es nuevo, pero la documentación es rara y la decisión técnica de adoptarlo no es trivial. Mi tesis antes del primer H2: no alcanza con leer la noticia y copiar la dependencia; hay que convertir esto en una decisión con criterio propio.

El problema real que Noroboto señala

Cuando renderizás texto en una aplicación — sea un editor, una terminal, un linter visual o cualquier cosa que dibuje caracteres — dependés de métricas que el sistema de fuentes te promete. El ancho de un glifo, el espacio entre caracteres, el bounding box. El asunto es que esas métricas pueden no coincidir con lo que el motor de render termina pintando en pantalla.

Esto no es un bug exótico. Es una consecuencia de capas: el shaper (HarfBuzz habitualmente), el rasterizer (FreeType o similar), el compositor de ventanas, el DPI del display y las hints embebidas en la fuente misma. Cada capa puede introducir una discrepancia. Si un proyecto como Noroboto se molesta en documentarlo y construir mitigaciones en Rust, es porque el problema aparece con suficiente frecuencia como para que la solución ad-hoc (compensar a mano, ignorarlo, rezar) deje de ser sostenible.

Mi punto concreto: el valor de Noroboto no está en que descubre algo nuevo, sino en que formaliza el contrato roto y propone una superficie de mitigación con tipos. Eso es relevante si estás construyendo algo que depende de layout de texto preciso.

Qué propone la mitigación en Rust y por qué importa el lenguaje

Rust no aparece acá por moda. La elección tiene lógica de oficio: cuando el problema es que un conjunto de métricas retornadas no matchea el render real, querés dos cosas que Rust da bien — tipos que modelen la diferencia explícitamente y zero-cost abstractions para no pagar overhead en el hot path de layout.

El patrón que emerge en proyectos de este tipo es algo así:

// Las métricas "prometidas" por el sistema de fuentes
struct PromisedMetrics {
    advance_width: f32,
    bearing_x: f32,
    bearing_y: f32,
}

// Las métricas observadas después del render real
struct ObservedMetrics {
    actual_width: f32,
    pixel_offset: f32,
}

// El delta entre promesa y realidad — esto es lo que Noroboto mitiga
struct MetricsDelta {
    width_error: f32,
    cumulative_drift: f32, // el error se acumula en texto largo
}

fn compute_delta(promised: &PromisedMetrics, observed: &ObservedMetrics) -> MetricsDelta {
    MetricsDelta {
        width_error: observed.actual_width - promised.advance_width,
        cumulative_drift: 0.0, // calculado en contexto de línea completa
    }
}

La clave es que el tipo MetricsDelta fuerza al resto del código a reconocer que existe una discrepancia. No podés ignorarla implícitamente como harías con un float suelto. Eso es diseño con tipos al servicio de un invariante real.

Ahora bien — y acá empieza la parte que me importa comunicar — este patrón solo sirve si tenés un loop de feedback entre métricas prometidas y render observado. Sin ese loop, modelar la diferencia es burocracia de tipos, no mitigación real.

Dónde se equivoca la gente al leer este tipo de proyectos

El error clásico es agarrar la solución sin entender el contrato de uso. Con Noroboto o proyectos similares, veo tres confusiones frecuentes:

1. Creer que es un problema de todas las fuentes. No siempre lo es, y ahí está el matiz que importa: las fuentes bien hinted en entornos con configuración limpia de fontconfig y FreeType en Linux suelen tener discrepancias menores o despreciables para muchos casos de uso. El problema se vuelve real en fuentes con hinting deficiente, en pantallas con DPI no estándar, o cuando el subpixel rendering está deshabilitado. Primero medí, después mitigá — esto lo digo como criterio prudente, no como medición propia verificada en cada stack.

2. Confundir layout de texto con render de texto. Si estás construyendo algo que calcula posiciones de texto para UI (React, un canvas, un terminal multiplexer), el problema importa. Si solo renderizás texto en pantalla para que el usuario lo lea, las discrepancias suelen ser subperceptuales. El costo de la mitigación puede ser mayor que el beneficio.

3. Asumir que Rust resuelve el problema por ser Rust. El lenguaje da garantías de memoria y permite modelar el delta con tipos. No da garantías sobre las métricas del sistema operativo. Si FreeType o fontconfig te devuelven un número incorrecto, Rust lo recibe igualmente incorrecto. La mitigación requiere medición real, no solo tipos más precisos.

Esto conecta con algo que aprendí mirando planes de ejecución en PostgreSQL: un índice bien puesto no es magia, es entender el acceso real. Lo mismo acá — un tipo bien modelado no es magia, es entender qué estás midiendo.

Checklist de decisión: cuándo investigar Noroboto y cuándo no

Antes de agregar cualquier dependencia de este tipo, pasá esta lista. Si contestás "no sé" a más de dos, el experimento correcto es medir primero.

Si tres o más de los ⛔ aplican a tu caso, la mitigación tiene costo mayor que el problema. El overhead de mantenimiento de la abstracción es real.

Cómo medir antes de decidir — en Linux podés hacer un test rudimentario con fc-query para inspeccionar las métricas declaradas de una fuente y compararlas contra lo que un rasterizer como FreeType devuelve en práctica:

# Inspeccionar métricas declaradas de una fuente instalada
fc-query /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf | grep -E "spacing|size|pixelsize"

# Ver qué fuentes está usando tu sistema para un pattern específico
fc-match -v "DejaVu Sans:size=12" | grep -E "file|size|spacing"

Esto no te da el delta de render, pero sí te confirma si el sistema de fuentes está resolviendo lo que creés que resuelve. Si la fuente que matchea no es la que esperabas, cualquier métrica que asumas es incorrecta desde el origen.

Lo que no se puede concluir todavía

Acá está el límite honesto del análisis:

• Sin benchmark propio, no hay número confiable. El overhead de la mitigación en Rust depende del caso de uso, del tamaño del texto, del hardware y de cuánto trabajo hace el loop de feedback. No tengo un número público verificable y no voy a inventar uno.
• Sin logs de discrepancia en producción, no sabés si el problema existe en tu stack. La descripción del proyecto señala el problema en términos generales. Si corrés Ubuntu con fontconfig bien configurado y fuentes del sistema, puede que nunca veas el bug.
• Rust mitiga, no elimina. Si el shaper devuelve datos incorrectos por upstream, la mitigación en Rust opera sobre datos malos. El fix puede requerir ir más arriba en la cadena — configuración de fontconfig, elección de fuente, DPI explícito.

Este tipo de análisis de señal vs. ruido es el mismo ejercicio que hago cuando evalúo si un patrón nuevo en el ecosistema merece tiempo de equipo. Lo hice con agentes pequeños para tool calling, con retry y amplificación de carga y con el N+1 que aparece en Prisma cuando no lo esperás. La pregunta siempre es la misma: ¿tengo evidencia del problema en mi contexto o estoy optimizando contra un fantasma?

FAQ

¿Qué son exactamente las "lying fonts" que documenta Noroboto? Es el fenómeno donde las métricas que el subsistema de fuentes reporta (advance width, bearing, bounding box) no coinciden con los píxeles que el rasterizer termina pintando. La discrepancia puede ser subpixel en casos simples o acumularse en texto largo con kerning complejo, especialmente en fuentes con hinting deficiente o en entornos con DPI no estándar.

¿El problema es exclusivo de Linux? No, pero Linux es donde más variabilidad existe por la combinación de fontconfig, FreeType, HarfBuzz y múltiples compositores. macOS tiene CoreText con un pipeline más controlado. Windows tiene DirectWrite. En todos los casos existe alguna forma de discrepancia posible, pero la magnitud y frecuencia varían mucho.

¿Por qué Rust y no C o C++ para la mitigación? Rust permite modelar el delta con tipos que el compilador verifica, sin overhead en runtime. El argumento no es que C++ no pueda hacer lo mismo — puede — sino que Rust hace más difícil ignorar la discrepancia por accidente. Es un argumento de ergonomía de tipos, no de performance.

¿Necesito esto si solo uso fuentes en una app web o en React? Probablemente no. Los navegadores tienen su propio pipeline de texto (Skia, CoreText o DirectWrite según el OS) y el layout engine se encarga del ajuste. El problema es relevante principalmente cuando construís algo que calcula posiciones de texto fuera del DOM — canvas, editores custom, terminales, herramientas de visualización.

¿Cómo sé si tengo el problema antes de agregar la dependencia? Medí. Tomá una cadena de texto, calculá su ancho esperado con las métricas del sistema, renderizá y medí el ancho real en píxeles. Si la diferencia es consistentemente mayor a 1px en texto de longitud normal en 96dpi, el problema existe en tu entorno. Si la diferencia es ruido subpixel, probablemente no necesitás la mitigación.

¿Esto afecta a editores de código como VS Code? VS Code usa Electron con el motor de render de Chromium, que tiene su propio pipeline de texto. Para la mayoría de los casos prácticos, el problema está mitigado por el motor del navegador. Si construís una extensión que hace layout custom de texto sobre canvas, sí podría ser relevante.

Mi postura y el próximo paso concreto

Lo que me parece valioso de Noroboto no es la solución en sí, sino que formaliza un contrato que la mayoría de las apps ignoran: el sistema de fuentes es una dependencia con promesas que pueden no cumplirse, y eso merece ser modelado explícitamente si el layout de texto importa.

Lo que no compro es la lectura de "agreguemos esto por las dudas". El costo de mantener un loop de feedback entre métricas prometidas y observadas es real. Si no tenés evidencia del problema en tu entorno, estás pagando ese costo sin beneficio medible. Esa es la parte incómoda que casi nadie dice cuando lee un proyecto nuevo con entusiasmo: la abstracción más elegante no vale nada si no tenés el log que la justifique.

La decisión honesta es: medí primero con fc-query y un test de render manual, verificá si la discrepancia existe en tu stack específico, y solo después evaluá si la abstracción tiene sentido. Si estás en VS Code sobre Ubuntu 24.04 con fuentes del sistema y DPI estándar, hay buenas chances de que el problema sea teórico para tu caso.

Esto aplica igual cuando evaluás startup time en Spring Boot o cuando decidís qué sincronizar con useEffect y qué no: la señal importa, el contexto la calibra.

El próximo paso concreto: si tenés una aplicación que hace layout de texto en Linux, corré el checklist de arriba antes de la próxima decisión de dependencia. Si tres o más de los ⛔ aplican, guardá el tiempo para otra cosa — y si alguien te pide sumar la mitigación "por las dudas" sin haber medido nada, esa es la pregunta incómoda que hay que hacer antes de escribir una línea de código.