How Did Image Generation Suddenly Get Text Rendering Right?
Recently I've had a very direct feeling: Many of the current image generation models no longer just "draw something that looks like text," but are actually starting to get the text right.
This is actually worth pausing to think about.
Because if you look back at image generation from a couple of years ago, you'll notice a consistent complaint: The atmosphere, composition, and lighting in images were already quite strong, but as soon as there were signs, poster titles, packaging copy, or UI text in the image, it would fall apart. English would have scrambled letters, Chinese would be missing components, and small text was a mess. How bad was this problem? It was so bad that many papers on visual text generation open with something like: although current text-to-image models have high overall fidelity, once you shift your gaze to the text area, the flaws become very obvious. oai_citation:0‡arXiv
But recently, things have changed.
Some of the new results I've seen are not just "occasionally getting a few characters right," but I can clearly feel that models have become much more stable when handling titles, slogans, and sign text in scenes. So I got curious: How was this actually solved? Was it really that the models got bigger, the data got more, so they incidentally learned the text problem too? Or has the research community quietly switched to a whole new approach?
After digging through papers from the past two to three years, the conclusion I reached was quite clear:
The text problem wasn't gradually solved through prompt engineering, nor was it "incidentally learned" by the model. Fundamentally, it was taken out separately and re-modeled as a dedicated problem. oai_citation:1‡arXiv
This article wants to follow this curiosity and clarify three things:
- Why image generation specifically tends to fail when it encounters text;
- How recent methods have actually solved this;
- Why I increasingly feel this path will eventually lead to a glyph-first system, rather than continuing to rely on prompts developing layout capabilities on their own.
First, the most crucial point: text is not ordinary image content
I think the first step to understanding this problem isn't looking at attention mechanisms or OCR loss, but rather acknowledging one thing:
Text and "clouds, trees, clothing, wall textures" are not the same type of object.
Most ordinary image content is continuous. Clouds that are slightly blurry are still clouds; wood grain that's slightly warped is still wood grain. But text isn't like that. Text is a low-tolerance discrete symbol system—one missing stroke or wrong structure and it may become immediately unreadable.
This is also why early models gave people a very subtle feeling: Looks good from afar, but wrong up close. You feel like "there should be text here," but when you look carefully, it's actually just some kind of text-like texture, not readable text.
GlyphControl explained this very directly in 2023: visual text generation is not a natural extension of ordinary T2I tasks; additional glyph conditional information must be introduced to stably generate accurate text. AnyText made a similar judgment: even when overall image quality is high, once you focus on the text area, problems immediately become apparent. oai_citation:2‡arXiv
Why previous models always had "text-like" but never got it right?
Looking at this problem purely from a model architecture perspective, it's actually quite natural.
Traditional text-to-image conditional injection basically follows this path:
- Image latent / patch token as Query
- Text token as Key / Value
- Let the image continuously "read" the text condition during generation
This mechanism works very well for ordinary semantic alignment.
For example, if the prompt has red car on snow, the model easily learns:
- Which areas should look at
car - Which areas should look at
snow - Which局部 more affected by
red
But the problem is, text tokens provide semantics, not glyphs.
Token "A" is not the visual structure of letter A, token "春" is not the specific stroke arrangement of the character "春." So if the system only consumes semantic tokens, what it more easily learns is:
There should be a sense of "text" here
rather than:
This must be this specific character, with correct strokes, clear boundaries, and adjacent characters not interfering with each other
This is also why papers from the past two to three years have almost all been converging in one direction:
Stop relying only on semantic conditioning; upgrade text from "language prompt" to "explicit glyph condition." GlyphControl did this, AnyText did this, FLUX-Text did this, TextPixs did this too. oai_citation:3‡arXiv
How has the research community broken down this problem step by step?
If you connect the work from recent years, I think it's not "some paper suddenly invented a magic module," but rather a quite clear evolutionary process.
Phase 1: First acknowledge "text generation" as an independent problem
The most important thing in this phase isn't technical details, but that the problem was renamed.
A key point GlyphControl made was clearly stating that visual text generation needs glyph-conditional control, rather than continuing to expect character-aware text encoders or larger general-purpose models to learn it themselves. The paper also specifically constructed the LAION-Glyph dataset and used OCR-based metrics, CLIP score, and FID to evaluate results. This move was important because it essentially said: text rendering deserves its own set of benchmarks and metrics. oai_citation:4‡arXiv
AnyText took this further and systematized it. It didn't just do text generation; it also put multilingual text generation and editing into the same diffusion framework, and introduced the AnyWord-3M dataset and AnyText-benchmark. The paper was very clear: the text area problem can no longer be treated as a subsidiary phenomenon of ordinary image fidelity; it needs independent modeling. oai_citation:5‡arXiv
In other words, what really happened in Phase 1 was:
People stopped asking "why can't the model write yet," and started asking "if we treat writing as a dedicated task, how should we represent it, train it, and evaluate it?"
Phase 2: From semantic-first to glyph-first
This is the most critical turning point, in my view.
The previous approach was essentially semantic-first: Give the model a semantic representation of a string, then hope it "figures out" the character shapes in image space by itself.
But later people gradually discovered that this path has a limited ceiling. Because semantics and glyphs are fundamentally different things. Knowing the meaning of a word doesn't equal knowing how it should be written in an image.
So GlyphControl's solution was straightforward: Don't just tell the model "write SALE here," but also give it SALE's glyph instruction explicitly. This way users can not only control text content but also position and size. oai_citation:6‡arXiv
AnyText continued moving forward in this direction. Its design has two particularly important modules:
- Auxiliary latent module: Takes glyph, position, masked image, and generates latent features related to text;
- Text embedding module: Uses OCR models to encode stroke information, then fuses these embeddings with caption embeddings.
This already says a lot: Effective text generation isn't about feeding more prompts; it's about turning glyph, position, and region—things that weren't previously well-represented—into conditions the model can directly consume. oai_citation:7‡arXiv
My own feeling when I read this was quite strong: This is no longer "optimizing prompt understanding" but rather redefining the input space.
Phase 3: The problem isn't just "whether we have glyphs," but "how glyphs enter the system"
After glyph conditioning became consensus, research focus started diving deeper.
People stopped debating "whether we should give glyphs" and started researching:
- Is giving glyphs as an extra input enough?
- Or should we modify the backbone more deeply?
- Do training objectives need to change too?
FLUX-Text is a very typical paper in my view. It's not the kind of flashy "new worldview," but it's very practical. Its approach is: on FLUX-Fill's strong base model, use relatively lightweight glyph and text embedding modules to enhance text understanding and generation, while preserving the original generation ability as much as possible. More importantly, it explicitly proposes Regional Text Perceptual Loss—essentially saying: text areas must be optimized separately. oai_citation:8‡arXiv
This point is particularly important.
Because text areas are usually very small; if the training objective is still unified across the full image, most gradients come from the background. Of course the model will prioritize "making the image beautiful" over "getting the text right." FLUX-Text's point is essentially: You can't say text is important while continuing to treat it as a small piece of background noise in the loss function. oai_citation:9‡arXiv
Phase 4: From "word-level conditioning" to "character-level binding"
Going further, the problem becomes more granular.
Even if you give glyphs, that doesn't mean characters won't interfere with each other. Many times the model's problems are no longer "completely doesn't know what to write," but rather:
- Adjacent characters粘连
- One character's structure bleeds into another
- The whole string of text looks roughly right, but individual characters are unstable
This is where work like TextPixs becomes interesting.
It did several very targeted things:
- Dual-stream encoding: semantic text stream + glyph visual stream
- Character-aware attention
- OCR-in-the-loop feedback
- Attention segregation loss
The core intuition behind this is simple: Text alignment at the word level isn't enough—it needs character-level alignment.
In ordinary T2I, token-level control is usually sufficient. But text rendering is different; characters are the smallest unit of ultimate readability. If attention between characters isn't stably separated, the system easily gets the overall feeling of "this is a string of text" but fails to render specific characters correctly. TextPixs also made its goal very clear: solving the problem of readable, meaningful, correctly spelled text. oai_citation:10‡arXiv
Phase 5: Maybe the model shouldn't be responsible for "learning spelling from scratch," but rather for "fusing text into the scene"
When looking at more recent work, the line of thinking that interests me most isn't simply "accuracy improved by how much," but rather the problem definition is starting to change.
For example, TextFlux makes it quite obvious: It emphasizes OCR-free DiT model for high-fidelity multilingual scene text synthesis, while focusing on glyph accuracy and scene integration. oai_citation:11‡arXiv
There's a significant paradigm shift behind this:
- Old problem: How to make the model learn spelling from semantics
- New problem: How to naturally fuse reliable character representations into image scenes
I'm increasingly feeling that the latter might be the longer-term direction.
Because if you make a general image generation model handle two things simultaneously:
- Generate complex visual worlds
- Also precisely output characters like a typesetting engine
That's inherently a bit awkward. But if you make spelling as structured and explicit as possible, letting the model focus on fusion—meaning style, material, lighting, perspective, edge transitions—this path becomes more reasonable.
This is also why I'm now more willing to understand this research line as:
Not "the model finally learned to write," But "the system finally stopped treating text as ordinary texture."
Compressed into one sentence, it's actually three steps
If we don't get into details and condense the approach from these years, I think it's these three steps:
Step 1: Upgrade text from semantic prompt to glyph condition
That is, moving from prompt-only to glyph-first. This is what GlyphControl and AnyText-type methods clarified earliest. oai_citation:12‡arXiv
Step 2: Extract the text area separately from the full image for optimization
That is, don't let full-image loss continue to drown out the text area. FLUX-Text's regional text loss approach is very typical. ooi_citation:13‡arXiv
Step 3: Push the control granularity from word-level to character-level, then further to scene fusion-level
TextPixs represents the character-level binding step; some subsequent work emphasizes scene integration more. oai_citation:14‡arXiv
My take: This might be a turning point for image generation from "can draw" to "can use"
My biggest feeling from reading these papers wasn't "oh, that module is so clever," but rather:
The text problem is actually quite like a watershed.
Many previous visual generation models mainly solved "generating an image that looks good." But as soon as the scene becomes posters, packaging, UI, signs, ads, knowledge cards, the evaluation criteria immediately change:
- No matter how beautiful the image, wrong text makes it unusable;
- No matter how good the atmosphere, a blurry title can't enter the production flow;
- Unstable text editing makes it hard to truly integrate into design workflows.
So text rendering, while seeming like a detail, actually forces the entire system toward a more engineering-oriented, structured direction. It forces the model to answer a question it could previously avoid:
Are you generating "nice-looking visual textures," or are you generating "information that can be understood and used by humans"?
And the shared answer these recent papers give is:
If you want to generate the latter, then stop treating text as ordinary image content.
References
[1] Yukang Yang et al., GlyphControl: Glyph Conditional Control for Visual Text Generation, NeurIPS 2023. Proposed glyph-conditional control and constructed LAION-Glyph with OCR-based evaluation. oai_citation:15‡arXiv
[2] Yuxiang Tuo et al., AnyText: Multilingual Visual Text Generation and Editing, 2023/2024. Proposed auxiliary latent module, text embedding module, and AnyWord-3M / AnyText-benchmark. oai_citation:16‡arXiv
[3] Rui Lan et al., FLUX-Text: A Simple and Advanced Diffusion Transformer Baseline for Scene Text Editing, 2025. Emphasized lightweight glyph/text embedding and text fidelity, and introduced text region-aware optimization. oai_citation:17‡arXiv
[4] TextPixs: Glyph-Conditioned Diffusion with Character-Aware Attention and OCR-in-the-Loop Feedback for Accurate Text Rendering, 2025. Emphasized dual-stream, character-aware attention, OCR-in-the-loop, and character-level accuracy. oai_citation:18‡arXiv