Why AI book cover generators get the title text wrong

Zoom a generated cover to 400 percent and look at one word in the title. The two lowercase e's have different crossbars. One sits a hair steeper than the other, and its aperture is slightly more closed. Two letters along there is a gap wide enough to park a comma in, and nobody would have left it there on purpose. This is what it looks like when an AI book cover generator gets the text wrong while the spelling is perfectly correct. The model was never setting type. It was painting a picture of letters, and it painted every one of them fresh.

A generated title is a picture of type, not type

A font is a file, and most of what is in that file is not letter shapes. It is relationships. Which pairs need closing up. Which sequences get swapped for one drawn glyph. Where each letter's origin sits, and how far its advance width carries the next one along the line. Setting a title in that font is not drawing. It is calling a lookup.

A generated title is the other thing. It is a region of pixels shaped like letters, made by the same process that made the fog behind them. Nothing in the file knows. There is no glyph, no pair, no baseline, no origin. Just paint that resolves into an alphabet if you stand far enough back.

Typography is one line item in the wider survey of which parts of a generated cover hold up. This post lives underneath that line item.

So spelling is the wrong test, and it is the only one most people run. A generated title that comes back correctly spelled has not passed anything; it has failed to fail in the one way that is easy to check. There is no font file behind those pixels, so there is no kern table, no liga table, no lfbd or opbd table. Nothing was looked up, because there was nothing to look up. Legibility and typesetting are two different properties of a cover. A generator can score full marks on the first while remaining structurally incapable of the second, and no version number is going to change that.

Where in the pipeline the letters actually break

Two things go wrong. Both sit below the prompt, which is why no amount of prompt wording reaches either one.

The first is the text encoder. Liu and colleagues, in "Character-Aware Models Improve Visual Text Rendering" (arXiv:2212.10562), state it directly: "popular text-to-image models lack character-level input features, making it much harder to predict a word's visual makeup as a series of glyphs." The model gets your title as tokens, not as shapes. That same paper measured what changes when you fix it: "30+ point accuracy gains over competitors on rare words" for character-aware models. The paper scored those gains against the competitors and benchmarks it used in 2022 and 2023, not against whatever you generated this morning.

The second failure sits further down, in the autoencoder that compresses the image and decompresses it again. The DiffUTE authors put it in one sentence: "Since the VAE in SD is trained on natural images, its ability to restore text regions is limited." They add that compressing an image this way "causes the loss of dense text texture information, leading to blurry decoded images by the VAE decoder." Photographs of trees survive that round trip. Hairlines and stroke terminals do not.

The tell that both problems are real is what the researchers do about them. The DiffUTE team modified their network "to enable the model for drawing multilingual characters with the help of glyph and position information." Glyph and position information. That is a font and a layout, handed to the model as conditioning, because a description typed into a prompt box cannot supply either.

I cannot tell you what happens inside the weights. I can tell you what the people who measured it wrote down, and that it matches what comes back on my screen.

What a font file carries that a generated image cannot

Kerning is the part of this job most people think is taste. It is not taste. It is a table.

The OpenType specification registers kerning as a feature whose purpose is to "adjust the amount of space between specific glyph combinations to provide optically consistent spacing." Its worked example is the pair every designer names first: "The o is shifted closer to the T in the combination 'To.'" Somebody decided that value once, in units, and shipped it inside the file. Every time you set those two letters, you get that decision back identically.

A painted title cannot have that property, and it is not a maturity problem a bigger model will solve. There is no file. There is not even a place to attach one: Google's Gemini image documentation tells you to "Be clear about the text, the font style (descriptively), and the overall design." Read the parenthesis again. The interface for choosing a typeface is an adjective, and an adjective carries no table. Here is what the spec registers, and what a generated title holds instead.

Five years of setting covers by hand taught me that the right-hand column is where a cover looks wrong to a stranger who cannot say why.

How do you tell a painted title from a set one?

Zoom to 400 percent and find the same letter twice in one line. A font repeats a glyph exactly; a generation redraws it, and the second copy will be slightly off. The other tell is stroke weight drifting inside a single word, thinner at the start than at the end. Both take ten seconds. Do them before you fall in love with the image.

The models did get better, and there is a number for it

Everything above would be dishonest without this section. The models improved sharply, and the people who built them wrote the numbers down, not a marketing department.

The Stable Diffusion 3 authors describe an architecture that "enables a bidirectional flow of information between image and text tokens, improving text comprehension, typography, and human preference ratings." They then measured how much of that depends on the largest text encoder in the stack. Strip the T5 text encoder out of Stable Diffusion 3 and the win rate on written text drops to 38% while aesthetics stays around half — Figure 9 of arXiv:2403.03206. The paper's own reading of it: "We observe T5 to be important for complex prompts e.g. such involving a high degree of detail or longer spelled text," and "Its contribution to the capabilities of generating written text are more significant (38% win rate)." The picture survives. The words fall over.

That gap has not closed by scaling. In January 2026 the authors of arXiv:2601.16208 reported that "while scale improves general fidelity, targeted data composition is essential for specific domains like text." Bigger did not fix it. Training deliberately on rendered text did.

The vendors say it too, in their own release material. OpenAI's launch post for 4o image generation lists "Multilingual text rendering" and "Dense information with small text" among the model's stated limitations. That is a company with every reason to list neither.

Here is the strongest objection to my position, and it is fair. Nobody browsing a bookstore has ever inspected a kern table. Ideogram's features page, as it read on August 12, 2026, puts the pitch in one line: "Clearer type inside the composition, not a fragile overlay." Clear is what a buyer experiences, and if the title reads at thumbnail width, the tables are designer trivia.

Readers never see the table. They see what it produced: the same pair closed by the same amount everywhere it occurs, the same letter identical to itself twice in a line, spacing that came from a decision rather than a seed. A generation can land on all of that by luck, and sometimes does. Luck is not a specification.

What I do when the art is right and the title is not

Five steps, in this order, every time.

1. Prompt the art with the title area deliberately empty: a sky, a wall, a flat field of color where the words will go. Ask for the space, not the words.
2. Generate at the final trim ratio rather than square, so nothing you love gets cropped out when the image becomes a cover.
3. Set the title in a real font, on its own layer, at the size the hierarchy needs rather than the size that happens to fit.
4. Close the pairs the font's kern table left open. Most fonts handle "To" for you and leave "Ay" sitting there.
5. Shrink the whole thing to store-thumbnail width and read the title back at that size.

We build the same order into our own tool, and the step where the title becomes type is the one that runs second on purpose. The order is the argument: the picture is a generation problem, the words are a typesetting problem, and mixing them costs you the ability to fix either one.

What AthenaCover will not do about your kerning

AthenaCover sets your title as real type on top of the art, and then it will not let you touch it. No layers, no sliders, no font picker. You refine by typing "bigger title" in plain English and it renders again.

So if what you need is the "To" in your title closed up by a few units, or a subtitle and a series line and a tagline balanced against each other, or a specific typeface you already committed to across a series, we cannot do that. Go and hire the person who owns the font file.

The free round is three covers. If none of the three is close, you have learned something about your brief and spent nothing.