Justif: justificación Knuth-Plass y microtipografía para la web

• Justif es una demo web que compara directamente el renderizado predeterminado del navegador con la justificación de texto a nivel de publicación
• Permite configurar por separado división de palabras con guiones y protrusión de caracteres, expansión de ancho, ajuste de espaciado entre letras y ajuste del espaciado de la última línea
• También permite ajustar el ancho mínimo de la última línea y el rango de puntuación colgante, y comparar los resultados con text-wrap: pretty
• Se pueden probar no solo textos literarios y técnicos en inglés, sino también textos RTL en hebreo y árabe, y japonés, con tipografías serif, sans y monospace
• Mide en paralelo con el renderizado del navegador la cantidad de líneas, cortes con guion, líneas desbordadas, últimas líneas cortas, desviación de espacios y ríos (rivers), entre otros

---

Justificación y configuración detallada

• Justif está configurado para probar en la web la justificación Knuth-Plass y varias funciones de microtipografía
  • División de palabras con guiones
  • Protrusión de caracteres
  • Expansión de ancho
  • Ajuste de espaciado entre letras
  • Ajuste del espaciado de la última línea
• La puntuación colgante se puede usar al activar la protrusión de caracteres, y se puede aplicar al final de las líneas y al inicio de la primera línea, o a todo el rango
• El ancho mínimo de la última línea se puede ajustar a 0.33, y el ancho del cuerpo a 13em

Comparación y medición de textos y tipografías

• Se puede elegir el texto a comparar entre Alice in Wonderland, Frog Prince, Frankenstein, Ulysses, publicaciones técnicas, RFC 2324 y muestras tipográficas
• También ofrece textos RTL en hebreo y árabe, además de texto japonés
• Las tipografías compatibles incluyen Junicode, EB Garamond, Alegreya, IM Fell English, Vollkorn, Amstelvar, Latin Modern, Georgia, Roboto Flex, Courier Prime, IBM Plex Mono y fuentes del sistema
• Al hacer clic o mantener presionado el resultado, se revela el renderizado predeterminado del navegador para compararlo con el renderizado de Justif
• La herramienta de comparación admite text-wrap: pretty, desenfoque, regla de márgenes y visualización de espacios irregulares
• Las métricas incluyen cantidad de líneas, cortes con guion, líneas desbordadas, últimas líneas cortas y ríos, junto con espacio promedio, desviación promedio frente al espacio natural, desviación estándar y el espacio más ancho

[GN⁺]

Comentarios en Lobste.rs

• Este proyecto fue vibe coded con Fable https://news.ycombinator.com/item?id=48946738#49002419

  • Tengo mis dudas de si de verdad hace falta esa etiqueta cuando el tema del artículo no es el vibe coding
    No me interesa leer relatos sobre uso de LLM y me gustaría poder filtrarlos, pero parece que en la práctica la etiqueta se pone aunque el texto no tenga relación, con solo la sospecha de que se usó un asistente de código
    Esta vez está claro que sí se usó, pero también he visto casos donde una publicación sobre un proyecto recibe la etiqueta solo porque aceptan contribuciones de gente que usa asistentes de código
  • El autor admite sin problema que usó un LLM para hacer este proyecto
    Pero el término vibe coding y la etiqueta que usan aquí ya perdieron utilidad, y hace falta una expresión más precisa y productiva para distinguir entre textos sobre uso de LLM y resultados hechos en cuyo proceso de creación se usó un LLM de manera incidental
  • Langosta 1: “¡Dicen que desarrollaron un medicamento para curar el cáncer!”
    Langosta 2: “Sí... pero usaron AlphaFold y CRISPR, y además... redoble de tambores... Fable”
    Langosta 1: “¡Dios mío, es inaceptable! ¡Tiremos todo por el bien de la humanidad y volvamos a dibujar proteínas con lápices de colores en el pizarrón durante 40 años!”

• El resultado es excelente, incluso mejor que TeX sin el paquete microtype
  Este tipo de funciones de composición tipográfica debería manejarlo directamente el navegador
  Algunos navegadores implementaron text-wrap: pretty, pero parece estar limitado a unas cuantas líneas

  • En Safari actual pretty ya está bien implementado, pero tiene un bug cuando se usa junto con justify
    https://matklad.github.io/2026/02/14/justifying-text-wrap-pretty.html
  • La especificación de text-wrap: pretty lo define como una simple sugerencia cuyo comportamiento no está definido
    Básicamente dice que el agente de usuario debe priorizar una mejor distribución por encima de la velocidad y considerar varias líneas al decidir los saltos, y fuera de eso es igual que auto
    Puede evitar una última línea demasiado corta, espacios que parecen ríos entre líneas de texto y guiones consecutivos, pero la mejora exacta depende de cada navegador
    Recuerdo que quedó así en la especificación para evitar demasiadas restricciones cuando varios navegadores dijeron que lo implementarían de formas distintas
    Es una situación parecida a cuando se descartó Web SQL porque quedó expuesto que las implementaciones terminarían usando SQLite
    Ojalá algún día estas funciones se apliquen por defecto en text-wrap: auto y text-wrap: pretty deje de tener efecto, y también espero que implementen https://bugzilla.mozilla.org/show_bug.cgi?id=630181
    Este tipo de sugerencias no es nuevo; will-change también era una pista de optimización para navegadores de una generación anterior
    Para cuando se estandarizó, en Firefox casi ya no hacía falta y en algunos motores de nueva generación ni siquiera ayudaba, pero aun así se abusó muchísimo, así que quizá habría sido mejor mantener el truco obvio de transformZ(0)
  • En un mundo ideal, esta biblioteca no tendría que existir
    En la demo se puede alternar text-wrap: pretty para probar el comportamiento por navegador, y vale la pena verlo en varios porque la forma en que lo manejan Blink, WebKit y Gecko difiere de manera sorprendente

• Desde hace tiempo pienso que la puntuación colgante por lo general se aplica en exceso
  Si se nota, ya es demasiado, y “ en particular casi siempre resalta demasiado, así que debería sobresalir menos de la mitad de lo que sobresale ahora
  Más bien me gusta cómo “ al inicio de un párrafo funciona como una pequeña sangría
  El resultado con la puntuación colgante desactivada y solo una protrusión más sutil activada es tolerable, pero en general prefiero desactivar ambas
  Este tipo de tratamiento depende mucho de la fuente
  En Equity, la fuente serif que uso, si se aplica esto a “f,” al final de una línea, por el kerning la coma ya queda metida debajo de la f, así que sobresale hasta la parte superior de la f fuera de la línea y se ve raro
  Si una fuente serif ya coloca colas o remates fuera del ancho de la letra para que sobresalgan de forma natural, quizá eso sea un mejor candidato que la mayoría de los signos de puntuación
  En ajuste de espaciado entre letras, letter-spacing es riesgoso porque no se lleva bien con las ligaduras
  Si primero se aplican las ligaduras, queda algo como “T h i s i s fi n e!”, y si un letter-spacing distinto de 0 las desactiva, la f choca con el punto de la i
  Normalmente pasa lo segundo, pero depende del sistema de escritura, la fuente y las funciones OpenType activadas explícitamente, y además es fácil que ocurra sin querer

  • Personalmente me gusta el aspecto de la puntuación colgante, aunque por supuesto se puede cambiar en la configuración
    Coincido en que el ajuste de espaciado entre letras es complicado por las ligaduras, pero con el límite predeterminado de ±3% me parece que se ve bien
    En el ejemplo “Type Specimen” se puede ver al final del primer párrafo una secuencia de ligaduras fl, fi y ffi, y ese límite de 3% también se puede configurar
  • Tal vez la puntuación colgante explique algo que me molestaba en algunos sitios suecos, donde una comilla doble de cierre orientada a la derecha quedaba sola al final de la línea anterior
    En sueco se usan solo comillas dobles derechas tanto al inicio como al final de una cita
    Desde hace tiempo me pregunto si hay alguna forma de indicarle al navegador el idioma o la configuración regional de un texto específico para que maneje automáticamente cosas como las comillas dobles y los separadores decimales

• Quiero señalar que el ejemplo usa un ancho de línea artificialmente estrecho para enfatizar la mejora
  En general se recomienda que una línea tenga el ancho de unos dos alfabetos minúsculos, o sea, alrededor de 60 caracteres

  • Las columnas de los periódicos antiguos quizá no tenían un ancho parecido al del ejemplo, aunque eso no significa que hoy debamos seguir ese criterio
  • Puedes ensanchar la columna para comparar con un ancho de cuerpo de texto más realista
    La diferencia es mucho menos dramática, pero sigue siendo clara, y aun con un ancho de línea de 36em las métricas salen mucho mejor que con los valores predeterminados

• Me pregunto si la etiqueta de vibe coding se puso porque el autor dijo en otro sitio que usó un LLM
  El contenido del enlace no tiene nada que ver con LLM ni con vibe coding, así que a estas alturas esa etiqueta se siente como una cacería de brujas

  • Viéndolo con más buena fe, es porque esta etiqueta cumple dos funciones, y además de marcar que una publicación trata sobre vibe coding, también suele ponerse como advertencia de contenido irritante
    Eso choca con su uso más evidente, puede generar confusión y dar una impresión demasiado agresiva
    No es ideal que una sola etiqueta tenga dos propósitos, pero en general sí estoy a favor de las advertencias de contenido irritante y de poder filtrar libremente lo que no quieres ver
    Aunque sea una etiqueta confusa, al menos no perjudica al autor