Diecisiete mil palabras, cero espacios dobles y ningún programa de por medio: así armó rs1n, a fines de los años 90, una guía de Super Metroid donde cada línea de texto cierra exacta en el margen derecho. La redescubrió esta semana el blog unsung.aresluna.org, y el truco no tiene nada de mágico: el autor simplemente reescribía cada oración hasta que las palabras sumaran el ancho exacto de la línea.
El caso ilustra un problema que el software todavía resuelve mal: justificar texto monoespaciado sin dejar huecos irregulares ni recurrir a guiones de corte que rompen el copiado y pegado. Para cualquiera que edita documentación, comentarios de código o interfaces de terminal, vale la pena entender por qué.
TL;DR
- El blog unsung.aresluna.org publicó el 30 de agosto de 2026 un análisis sobre justificación de texto en fuentes monoespaciadas.- El artículo rescata la guía de Super Metroid de rs1n, escrita a fines de los años 90, con más de 17.000 palabras.- Cada línea derecha de la guía termina exacta en el margen, sin espacios dobles ni guiones de corte.- rs1n confirmó en su FAQ que no usó ningún programa: eligió las palabras a mano hasta que cada línea cuadraba.- La guía completa se escribió con un editor ASCII plano, sin herramientas de maquetación.- La justificación completa falla en monoespaciado porque los espacios solo se reparten en unidades enteras de carácter, no en fracciones.- La hifenación automática, la alternativa habitual en tipografía impresa, rompe el copiado y pegado del texto plano.
Qué pasó
El artículo "I just chose words carefully", publicado el 30 de agosto de 2026 en unsung.aresluna.org, arranca con una observación simple: tipear en monoespaciado nunca se siente cómodo. El texto alineado a la izquierda funciona razonablemente bien. Alinear a la derecha también, aunque obliga a contar espacios a mano. Centrar ya es más incómodo, porque en monoespaciado no existe el medio espacio que permitiría un centrado perfecto.
El problema real aparece con la justificación completa, la que estira cada línea para que ambos márgenes queden parejos. En una fuente proporcional, un procesador de texto reparte el espacio sobrante entre palabras en fracciones de píxel, algo casi invisible. En monoespaciado cada carácter, incluido el espacio, ocupa exactamente el mismo ancho: no hay fracciones posibles. El resultado son huecos dobles o triples que saltan a la vista, algo fácil de reproducir con cualquier justificador genérico sobre un archivo .txt.
La solución típica en tipografía impresa es la hifenación: cortar una palabra larga con un guion al final de línea para ajustar el margen. En pantalla, y sobre todo en texto plano, ese guion mezcla la puntuación real con la puntuación decorativa del corte de línea, y arruina el copiado y pegado: al pegar el párrafo en otro lugar, quedan guiones sueltos en medio de palabras que en realidad no los llevan.
La justificación completa deja huecos irregulares en monoespaciado, a diferencia del texto proporcional.
Contexto e historia
Ahí es donde entra la guía de rs1n para Super Metroid, escrita a fines de los años 90 para la escena de FAQs de texto plano que dominaba antes de que existieran wikis y videos en YouTube. En esa época, un walkthrough completo se distribuía como un archivo ASCII de varios cientos de kilobytes, pensado para leerse en un editor de texto o imprimirse.
La guía de rs1n tiene más de 17.000 palabras y, según documenta el blog que la redescubrió, cada línea del margen derecho termina exactamente en el mismo carácter, sin un solo espacio doble. En la sección de preguntas frecuentes del propio documento, el autor responde a la pregunta obvia (¿qué programa usó para justificar el texto?) con una frase que resume todo el truco: "None. I just chose words carefully so that everything lined up on the right hand side." Todo el trabajo se hizo con un editor ASCII simple, reescribiendo oraciones hasta que el largo cuadrara.
No es un caso aislado dentro de la tipografía tradicional. Ajustar el texto para evitar líneas huérfanas o viudas (una palabra sola al final de un párrafo, o una línea sola al inicio de una página) es una práctica habitual en la edición de libros físicos. Lo inusual es verlo aplicado línea por línea, a mano, en un archivo de texto plano pensado para pantalla, y sostenido durante miles de palabras sin cortar una sola vez.
Detalles técnicos: los límites del texto monoespaciado
El problema de fondo es matemático antes que estético. Justificar una línea a un ancho exacto W, usando palabras de longitud fija y espacios de un carácter, es una variante del problema de la mochila (subset sum): hay que encontrar una secuencia de palabras cuya suma de longitudes, más un espacio entre cada una, sea exactamente igual a W. Si la suma da menos, sobra hueco; si da más, la línea se desborda.
Un algoritmo de ajuste de texto convencional, como el que usa textwrap en Python o el comando fmt en Unix, resuelve el problema de otra manera: corta la línea en el mejor punto posible sin preocuparse por cuadrar el margen derecho. Sirve para wrap, no para justify. La diferencia se ve en un ejemplo mínimo:
import textwrap
texto = "El ajuste de texto monoespaciado no reparte espacios sobrantes de forma pareja"
for linea in textwrap.wrap(texto, width=40):
print(f"{linea: 0 else 0
largo += espacio + len(palabra)
return largo == ancho
linea = ["Cada", "linea", "termina", "justo", "en", "el", "margen"]
print(cabe_exacto(linea, ancho=32))
Esta función es el equivalente en código de lo que rs1n hacía a mano: prueba una combinación de palabras y confirma si la suma llega exacta al ancho de columna. Un editor automático tendría que iterar sobre sinónimos hasta encontrar una combinación que cumpla; rs1n lo hizo por prueba y error, a ojo, durante 17.000 palabras.
flowchart TD
A["Tomar la siguiente palabra candidata"] --> B{"Cabe en el ancho restante?"}
B -- "Si" --> C["Agregar palabra a la linea"]
C --> D{"Ancho exacto alcanzado?"}
D -- "Si" --> E["Cerrar linea sin espacios extra"]
D -- "No" --> A
B -- "No" --> F["Probar sinonimo o reordenar"]
F --> B
El diagrama resume el ciclo: agregar palabra, medir el ancho acumulado y, si no cierra exacto, buscar una alternativa antes de seguir. Es el mismo ciclo mental que describe rs1n en su FAQ, solo que sin automatizar.
17.000 palabras y ningún guion de corte: cada línea cierra sola en el margen derecho.
Cómo empezar a probarlo
No hace falta escribir un justificador completo para experimentar con el problema. Alcanza con un script corto que mida si un texto propio, línea por línea, cierra parejo a un ancho fijo, algo útil para READMEs, comentarios de bloque o documentación en texto plano que se lee en terminal.
import sys
def revisar(ruta, ancho):
with open(ruta, encoding="utf-8") as archivo:
for numero, linea in enumerate(archivo, start=1):
largo = len(linea.rstrip("\n"))
estado = "OK" if largo == ancho else f"desvio {largo - ancho}"
print(f"linea {numero}: {largo} caracteres ({estado})")
if __name__ == "__main__":
revisar(sys.argv[1], int(sys.argv[2]))
Para correrlo, guardá el archivo como verifica_justificado.py y ejecutá:
- Windows:
py verifica_justificado.py guia.txt 80- macOS:python3 verifica_justificado.py guia.txt 80- Linux:python3 verifica_justificado.py guia.txt 80
El script no corrige nada, solo señala qué líneas se desvían del ancho objetivo (80 columnas es el estándar heredado de la terminal VT100 y todavía el límite recomendado para archivos README.md y comentarios de código). A partir de ahí, reescribir cada línea hasta que cierre exacto sigue siendo trabajo manual, igual que en 1998.
💡 Tip: en Vim, el comando
gqreformatea un párrafo al ancho detextwidth, pero solo hace wrap, no justifica: para cuadrar el margen derecho todavía hay que reescribir a mano.
Impacto y análisis
El caso de rs1n no es una curiosidad aislada para nostálgicos de los 90. El texto monoespaciado sigue siendo el formato por defecto de terminales, editores de código, mensajes de commit y buena parte de la documentación técnica que se lee sin renderizar Markdown. Cualquiera que haya intentado alinear una tabla en un comentario de código, o dibujar un diagrama con caracteres ASCII, se topó con la misma limitación: no hay medio espacio ni fracciones de carácter.
Las interfaces de texto para terminal (TUI), construidas con librerías como ratatui en Rust o textual en Python, resuelven el problema recortando o rellenando con espacios completos, nunca fraccionando el ancho. Es la misma restricción que enfrentaba rs1n, solo que las TUI modernas no intentan justificar párrafos completos: se limitan a alinear columnas de tablas, donde el ancho de cada celda es fijo y conocido de antemano.
📌 Nota: la propiedad CSS
text-align: justifyaplicada a un bloque con fuente monoespaciada, por ejemplo dentro de una etiqueta<pre>, produce el mismo efecto de huecos irregulares que describe el artículo original, porque el navegador solo puede insertar espacios completos, no fracciones de carácter.
Qué sigue
El propio blog que rescató la guía la presenta como una curiosidad, no como una técnica a imitar: reescribir 17.000 palabras a mano para que cada línea cuadre es, según cuenta, un trabajo que pocos repetirían hoy. Pero el problema de fondo, ajustar la longitud de un texto a un ancho exacto eligiendo entre sinónimos, es el tipo de tarea combinatoria que un modelo de lenguaje o un solver de restricciones podría automatizar sin demasiada dificultad: generar variantes de una oración, medir su longitud exacta y quedarse con la que cierra el margen.
Por ahora no existe una herramienta estándar que resuelva la justificación monoespaciada real, sin espacios dobles ni guiones, de forma automática y prolija. Quien necesite ese efecto en un archivo de texto plano sigue teniendo dos caminos: aceptar el hueco irregular de la justificación tradicional, o hacer lo que hizo rs1n, elegir las palabras con cuidado.
📖 Resumen en Telegram: Ver resumen
Probalo vos: abrí un archivo de texto plano propio, corré el script de arriba con un ancho de 80 columnas y fijate cuántas líneas de tu propio README se desvían del margen.
Preguntas frecuentes
¿Qué significa justificar texto monoespaciado?
Es alinear ambos márgenes de un bloque de texto, izquierdo y derecho, cuando cada carácter, incluido el espacio, ocupa el mismo ancho fijo. A diferencia de una fuente proporcional, no se puede repartir el espacio sobrante en fracciones de carácter.
¿Por qué la justificación completa se ve mal en monoespaciado?
Porque el espacio sobrante de una línea solo puede repartirse en unidades enteras de carácter. Si sobran tres espacios entre siete palabras, alguno de los huecos entre palabras termina siendo el doble o el triple que los demás, y eso salta a la vista.
¿Qué herramienta usó rs1n para justificar su guía?
Ninguna. Según su propia respuesta en la sección de preguntas frecuentes del documento, escribió todo con un editor ASCII y reescribió cada oración hasta que el largo de las palabras sumara exacto el ancho de columna.
¿La hifenación no resuelve el problema?
Solo en parte. Un guion de corte de línea ajusta el margen, pero en texto plano mezcla puntuación real con puntuación decorativa: al copiar y pegar el párrafo en otro lugar, el guion queda pegado en medio de una palabra que en realidad no lo lleva.
¿Sirve esto para código o solo para prosa?
Aplica sobre todo a documentación, comentarios largos y archivos de texto plano. En código fuente no se justifica texto: se usa indentación fija y, como mucho, alineación de columnas en tablas o comentarios, un problema más simple porque el ancho de cada celda ya se conoce de antemano.
Referencias
- unsung.aresluna.org: artículo original que redescubre la guía de rs1n y compara las distintas alineaciones en monoespaciado.- Wikipedia: Typographic alignment: historia y técnicas de justificación de texto en tipografía.- Wikipedia: Monospaced font: definición y usos de las fuentes de ancho fijo.- MDN: text-align: documentación de la propiedad CSS que controla la justificación en la web.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)