Text to ASCII Art Generator

A banner made of characters is a picture pretending to be text. Every mark in it is an ordinary letter or symbol, and none of them means what it says. The meaning is in the arrangement.

That trick is older than the computer. Wikipedia’s history of the form dates typewriter art to 1867, with a note that the claim wants a better source, and it reproduces a newspaper advertisement from 6 January 1875 composed that way. Typists could find guides in books and magazines that explained how to type a portrait. The same account reports, from a handbook on radio teletype, that text pictures were sent by teleprinter as early as 1923, though none of that early work has been found.

Machines that could only type

The computer inherited the constraint and the habit together. Early printers often lacked any graphics ability, so characters stood in for graphic marks. Around 1966 the computer artist Kenneth Knowlton was producing pictures this way, and “Studies in Perception I”, made with Leon Harmon, is the usual early example. Realistic images came from printing several characters on top of one another in the same position.

Banners had a duller job. Shared printers served many people, and something had to mark where one person’s output ended and the next began. Bulk printers printed a large banner page between jobs so that an operator could spot the division and separate the stack. The big letters were not decoration. They were a filing system for paper.

Unix made a small program of it. The FreeBSD manual page for banner describes a utility that prints a large, high quality banner on the standard output, meant for paper of the appropriate width with no breaks between the pages. Its default width is 132 columns, and one option narrows that for a terminal. The page says the utility first appeared in Version 6 Unix.

The palette was fixed early too. RFC 20, written by Vint Cerf in October 1969, proposed the standard 7-bit ASCII code for network interchange. Its table leaves 95 characters that print, counting the space, from code 32 to code 126. Everything a plain banner can use is on that short list.

The best-known program of the kind is FIGlet, a name its own readme expands as Frank, Ian and Glenn’s Letters. The readme says it creates large characters out of ordinary screen characters, and compares the output to the signatures people put at the end of e-mail and Usenet messages. Its licence file carries copyright dates from 1991. Its fonts are plain text files, and the format has a written standard, with copyright dates of 1996 and 1997, by John Cowan and Paul Burton.

That standard is worth reading for its vocabulary alone. It names three ways to set letters side by side. Full size leaves each letter the full width it was designed with. Fitting moves letters closer together until they touch, which the document likens to what typographers call kerning. Smushing moves them one step closer still, so that they partly share the same space, and a set of rules decides which character to show at the join. It also defines the hardblank, a character shown as a space that refuses to be squeezed.

Why the columns must agree

All of this rests on one assumption: every character is exactly as wide as every other. Most such art is made for a monospaced font. The early computers on which it came into vogue had nothing else, on screen or on the printer. Today the commonly used fonts are proportional, with different widths for different characters, and a banner pasted into one collapses into noise.

So the first rule of use is short. A banner belongs only where the font is fixed.

Even there, width is slippery once text leaves ASCII. Unicode Standard Annex 11 gives every character an East Asian Width property with six values, which resolve in use to two, narrow and wide. Ideographs are always wide, and all of ASCII is narrow. The annex adds, carefully, that the actual display width of a glyph is given by the font, and it describes an important class of fixed-width fonts whose wide glyphs are twice as wide as the narrow ones. A banner that mixes the two kinds has to count columns, not characters.

Counting characters is its own trap. What a reader sees as one character may be several code points: a letter and a combining accent, or an emoji built from parts. Annex 29 calls these user-perceived characters grapheme clusters and defines where their boundaries fall. A program that wraps lettering has to break between clusters and never inside one, or an accent lands on the wrong line. Browsers now offer that segmentation directly, by grapheme, word or sentence.

The safest output is therefore the dullest. Pure ASCII survives almost any destination. The Unicode character database lists two blocks made for this kind of drawing, Box Drawing at U+2500 to U+257F and Block Elements at U+2580 to U+259F, and their solid and half-height cells look far better than a hash sign does. They also ask more of the destination, which must have a fixed-width font that includes them.

A worked example

Take the five-row block alphabet in the tool on this page, where every letter is five rows tall and most are four columns wide. Type Hi. The H takes four columns, one column of spacing follows, and the I takes three: eight columns in all. Wrap it as a comment of the // kind and each line gains three columns, so the widest line is eleven.

Now type HELLO WORLD on one line with the width set to 80. The lettering is 54 columns wide and five rows tall, so it fits. Set the width to 40 and it cannot fit, so the line breaks at the space. The result is two lines of lettering, the wider one 25 columns, and eleven rows counting the blank row between them. Choosing Shrink over Wrap changes nothing here, because this alphabet is already at its smallest size.

Kerning shows in a pair like LT. Set side by side with one column of spacing, the two letters take ten columns, and the hollow under the arm of the T reads like a missing letter. With kerning on, the T slides two columns left into the empty space above the foot of the L, and the pair takes eight. The rule is deliberately modest. It never lets ink come closer than the chosen spacing, in the same row or diagonally, and it never moves a letter more than two columns.

The device-font styles work differently, and the difference matters. There the text is drawn out of sight with a font already on the device, and the ink in each cell is measured. A renderer then picks a character: a solid fill when at least half the cell is inked, a half block when only the upper or lower half is, a shade from a short ramp, an outline where a filled cell meets an empty one. The same device gives the same result every time. A different device may hold a different font and so give different lettering, which is why the two hand-drawn alphabets exist.

Where it still earns its place

Source files are the natural home. A banner at the top of a long configuration file, or between the sections of a script, stays visible in a scrolling editor in a way no ordinary comment does. But a comment has grammar, and a banner can break it. In C a block comment runs to the next closing mark and does not nest, so lettering that happens to contain an asterisk followed by a slash ends the comment early and spills the rest into the program.

Line comments have a quieter hazard. The C preprocessor joins any line that ends in a backslash to the line after it, and the compiler manual notes that white space after the backslash does not prevent the join. A banner row ending in a backslash therefore pulls the next line into the comment, even when that line is code. HTML has its own short list: the text of a comment may not contain <!-- or -->.

A README wants a fenced block, so that the renderer keeps a fixed-width font. CommonMark requires the closing fence to use the same character as the opening one and to be at least as long. That gives a clean rule for lettering that itself contains backticks: make the fence one longer than the longest run inside. Logs and terminal start-up messages are the other survivors, for the oldest reason of all. A big word is easy to find in a wall of small ones.

Who cannot read it

None of that helps a person using a screen reader. The W3C failure note on the subject is blunt. Such art is implemented as a character string, it says, but its meaning comes from the pattern of glyphs and not from the text itself, so it is non-text content and needs a text alternative. Without one, a page fails Success Criterion 1.1.1. The companion technique adds that this content can be very confusing to people who use screen readers.

The remedies are simple and cheap. On a web page, give the block the image role and a label that says what it spells, the pattern shown both in the W3C technique and in the MDN reference for the pre element, which also wraps it in a figure with a caption. Or put the words in plain text just before the art, with a link to skip past it. In a source file, write the title as an ordinary comment line as well.

The same care applies to a picture of a banner. Text in an image still has to be legible, and the guidelines ask for a contrast ratio of at least 4.5 to 1 between text and its background. Bright green on near black passes easily. The gray #777777 on white works out at about 4.48 to 1 by the same formula, and just misses.

What the method cannot do is make text. A banner cannot be searched for the word it spells, translated, enlarged by the reader, or read aloud. A hand-drawn alphabet made for ASCII has no accented letters to offer, and three rows are too few to keep every letter distinct. It is ornament with a filing job, as it was beside the line printer. Use it as a signpost, and keep the real name of the thing in real text beside it.