⏱️ Lectura: 11 min
Seventeen thousand words, zero double spaces, and no software involved: that’s how rs1n put together a Super Metroid guide in the late 1990s where every line of text closes exactly at the right margin. The blog unsung.aresluna.org rediscovered it this week, and the trick isn’t magic at all: the author simply rewrote each sentence until the words added up to the exact width of the line.
📑 En este artículo
The case illustrates a problem that software still handles poorly: justifying monospace text without leaving irregular gaps or resorting to hyphenation that breaks copy-pasting. For anyone editing documentation, code comments, or terminal interfaces, it’s worth understanding why.
TL;DR
- The blog unsung.aresluna.org published an analysis on August 30, 2026 about justifying text in monospace fonts.
- The article rescues rs1n’s Super Metroid guide, written in the late 1990s, with more than 17,000 words.
- Every right-hand line in the guide ends exactly at the margin, with no double spaces or hyphenation.
- rs1n confirmed in the FAQ that no software was used: the words were chosen by hand until each line fit exactly.
- The entire guide was written with a plain ASCII editor, with no layout tools.
- Full justification fails in monospace because spaces can only be distributed in whole character units, not fractions.
- Automatic hyphenation, the usual alternative in print typography, breaks copy-pasting of plain text.
What happened
The article “I just chose words carefully”, published on August 30, 2026 on unsung.aresluna.org, opens with a simple observation: typing in monospace never feels comfortable. Left-aligned text works reasonably well. Right-aligned text does too, though it forces you to count spaces by hand. Centering is already more awkward, because monospace has no half-space that would allow perfect centering.
The real problem shows up with full justification, which stretches each line so both margins line up evenly. In a proportional font, a word processor distributes leftover space between words in fractions of a pixel, something almost invisible. In monospace every character, including the space, takes up exactly the same width: no fractions are possible. The result is double or triple gaps that jump out at you, easy to reproduce with any generic justifier on a .txt file.
The typical solution in print typography is hyphenation: breaking a long word with a hyphen at the end of a line to adjust the margin. On screen, and especially in plain text, that hyphen mixes real punctuation with the decorative punctuation of the line break, and it ruins copy-pasting: when you paste the paragraph elsewhere, stray hyphens end up in the middle of words that don’t actually have them.
Context and history
That’s where rs1n’s Super Metroid guide comes in, written in the late 1990s for the plain-text FAQ scene that dominated before wikis and YouTube videos existed. Back then, a full walkthrough was distributed as an ASCII file several hundred kilobytes in size, meant to be read in a text editor or printed out.
rs1n’s guide has more than 17,000 words and, as documented by the blog that rediscovered it, every line on the right margin ends at exactly the same character, without a single double space. In the document’s own FAQ section, the author answers the obvious question (what software was used to justify the text?) with a line that sums up the whole trick: “None. I just chose words carefully so that everything lined up on the right hand side.” All the work was done with a simple ASCII editor, rewriting sentences until the length fit exactly.
It’s not an isolated case within traditional typography. Adjusting text to avoid orphan or widow lines (a single word left at the end of a paragraph, or a lone line at the start of a page) is standard practice in physical book editing. What’s unusual is seeing it applied line by line, by hand, in a plain text file meant for the screen, sustained across thousands of words without cutting a single corner.
Technical details: the limits of monospace text
The underlying problem is mathematical before it’s aesthetic. Justifying a line to an exact width W, using fixed-length words and single-character spaces, is a variant of the knapsack problem (subset sum): you need to find a sequence of words whose combined length, plus one space between each, equals exactly W. If the sum comes up short, there’s leftover space; if it comes up over, the line overflows.
A conventional text-wrapping algorithm, like the one textwrap uses in Python or the fmt command in Unix, solves the problem differently: it breaks the line at the best possible point without worrying about squaring off the right margin. It’s good for wrapping, not justifying. The difference shows up in a minimal example:
import textwrap
texto = "Monospace text wrapping does not distribute leftover spaces evenly"
for linea in textwrap.wrap(texto, width=40):
print(f"{linea:<40}|")Each line gets cut at the last word that fits within 40 characters, but the right margin doesn’t close evenly: the trailing | marks where the column should end and exposes the gap that textwrap doesn’t fill.
To truly justify text, without resorting to double spaces, you have to solve that subset sum before accepting a word onto the line: add up the length of the candidate word, the preceding space, and what’s already accumulated, then compare against the target width. If it doesn’t come out exact, the alternative rs1n used was swapping the word for a synonym of a different length, or reordering the sentence, until the sum landed just right.
def cabe_exacto(palabras, ancho):
largo = 0
for i, palabra in enumerate(palabras):
espacio = 1 if i > 0 else 0
largo += espacio + len(palabra)
return largo == ancho
linea = ["Every", "line", "ends", "right", "at", "the", "margin"]
print(cabe_exacto(linea, ancho=32))This function is the code equivalent of what rs1n did by hand: it tests a combination of words and confirms whether the sum reaches the exact column width. An automated editor would have to iterate over synonyms until finding a combination that works; rs1n did it by trial and error, by eye, across 17,000 words.
flowchart TD
A["Take the next candidate word"] --> B{"Does it fit in the remaining width?"}
B -- "Yes" --> C["Add word to the line"]
C --> D{"Exact width reached?"}
D -- "Yes" --> E["Close line with no extra spaces"]
D -- "No" --> A
B -- "No" --> F["Try synonym or reorder"]
F --> BThe diagram sums up the cycle: add a word, measure the accumulated width, and if it doesn’t come out exact, look for an alternative before moving on. It’s the same mental cycle rs1n describes in the FAQ, just without automating it.
How to start testing it
You don’t need to write a full justifier to experiment with the problem. A short script that measures whether your own text, line by line, closes evenly at a fixed width is enough, useful for READMEs, block comments, or plain text documentation read in a 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"deviation {largo - ancho}"
print(f"line {numero}: {largo} characters ({estado})")
if __name__ == "__main__":
revisar(sys.argv[1], int(sys.argv[2]))To run it, save the file as verifica_justificado.py and execute:
- Windows:
py verifica_justificado.py guia.txt 80 - macOS:
python3 verifica_justificado.py guia.txt 80 - Linux:
python3 verifica_justificado.py guia.txt 80
The script doesn’t fix anything, it just flags which lines deviate from the target width (80 columns is the standard inherited from the VT100 terminal and still the recommended limit for README.md files and code comments). From there, rewriting each line until it closes exactly is still manual work, just like in 1998.
💡 Tip: in Vim, thegqcommand reformats a paragraph to thetextwidth, but it only wraps, it doesn’t justify: to square off the right margin you still have to rewrite by hand.
Impact and analysis
rs1n’s case isn’t an isolated curiosity for 90s nostalgics. Monospace text remains the default format for terminals, code editors, commit messages, and much of the technical documentation read without Markdown rendering. Anyone who’s tried to align a table in a code comment, or draw a diagram with ASCII characters, has run into the same limitation: there’s no half-space or fraction of a character.
Terminal user interfaces (TUIs), built with libraries like ratatui in Rust or textual in Python, solve the problem by truncating or padding with whole spaces, never fractioning the width. It’s the same constraint rs1n faced, except modern TUIs don’t try to justify full paragraphs: they limit themselves to aligning table columns, where each cell’s width is fixed and known in advance.
📌 Note: the CSS propertytext-align: justifyapplied to a block with a monospace font, for example inside a<pre>tag, produces the same irregular-gap effect described in the original article, because the browser can only insert whole spaces, not fractions of a character.
What’s next
The blog that rescued the guide presents it as a curiosity, not a technique to imitate: rewriting 17,000 words by hand so every line fits is, as it tells it, work few people would repeat today. But the underlying problem, adjusting the length of a text to an exact width by choosing between synonyms, is the kind of combinatorial task a language model or a constraint solver could automate without much difficulty: generate variants of a sentence, measure their exact length, and keep the one that closes the margin.
For now, there’s no standard tool that solves true monospace justification, without double spaces or hyphens, automatically and cleanly. Anyone who needs that effect in a plain text file still has two options: accept the irregular gap of traditional justification, or do what rs1n did, choose the words carefully.
📖 Summary on Telegram: View summary
Try it yourself: open one of your own plain text files, run the script above with a width of 80 columns, and see how many lines in your own README deviate from the margin.
Frequently Asked Questions
What does it mean to justify monospace text?
It’s aligning both margins of a text block, left and right, when every character, including the space, takes up the same fixed width. Unlike a proportional font, you can’t distribute leftover space in fractions of a character.
Why does full justification look bad in monospace?
Because the leftover space in a line can only be distributed in whole character units. If three spaces are left over between seven words, one of the gaps between words ends up twice or three times as wide as the others, and that jumps right out at you.
What tool did rs1n use to justify the guide?
None. According to the FAQ section of the document itself, everything was written with an ASCII editor, and every sentence was rewritten until the length of the words added up exactly to the column width.
Doesn’t hyphenation solve the problem?
Only partly. A line-break hyphen adjusts the margin, but in plain text it mixes real punctuation with decorative punctuation: when you copy and paste the paragraph elsewhere, the hyphen ends up stuck in the middle of a word that doesn’t actually have one.
Does this apply to code or only to prose?
It applies mostly to documentation, long comments, and plain text files. In source code, text isn’t justified: fixed indentation is used, and at most, column alignment in tables or comments, a simpler problem because each cell’s width is already known in advance.
References
- unsung.aresluna.org: the original article that rediscovers rs1n’s guide and compares the different alignment methods in monospace.
- Wikipedia: Typographic alignment: history and techniques of text justification in typography.
- Wikipedia: Monospaced font: definition and uses of fixed-width fonts.
- MDN: text-align: documentation of the CSS property that controls justification on the web.
📱 Enjoy this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de ThisisEngineering en Unsplash
0 Comments