A Deep Dive into Font Rendering, Unicode Fallbacks, and the Text That Proves Your Fonts Are Broken
If you've ever noticed that certain strings of text look wrong in your application regardless of what font you pick, you've likely stumbled into the same pile of problems I've been wrestling with for years. The short version is that systems fall back from one font to another when the primary font lacks a given character, and most of the time this happens quietly. You only notice when it happens in an embarrassing way, like a headline where half the letters turn into someone else's glyphs. Michael Kaplan used a specific test phrase — Betty Bunny Didnt Do It — to expose how different systems handle text shaping and font fallback. The reason this particular string matters is not magic. It contains a mix of characters and punctuation that trip up basic text layouts. The apostrophe in "Didnt" is one of the more useful trouble spots. The double "t" in "Betty" and "Didnt" tests glyph repetition. The spacing between words tests kerning pairs. Put them together and you can quickly see whether your text engine is doing real shaping or just stuffing glyphs into boxes. I started using this phrase as a diagnostic after a client reported that quotes in their CMS were turning into rectangular placeholders on a new font stack. Running that phrase through their rendering pipeline showed exactly which characters failed, which font was being swapped in, and where the break occurred. It is a practical shorthand. You do not need a lot of setup to run it.
The broader topic here is how operating systems and browsers decide which font to use for each character, what OpenType features do during shaping, and why some strings look wrong even when the font file exists on disk.
How Text Shaping and Font Fallback Work in Practice
When you give a text engine a string, it does several things in sequence. It first identifies each code point. Then it maps those code points to glyph IDs using the font's cmap table. Then shaping engines like HarfBuzz or DirectWrite apply substitutions and positional adjustments. If a glyph is missing, the system falls back to another font, usually from a configured fallback list. This fallback chain is where most visible bugs come from. Fallback is not random. Windows uses a per-script and per-language fallback list. macOS uses a ordered font fallback set defined in system settings and font metadata. Linux relies on fontconfig, which merges your configuration with system defaults. The behavior is consistent within a platform, but it varies between platforms, which is why a string can look fine on one machine and broken on another. One thing beginners miss is that missing glyphs do not always cause a replacement. Sometimes the system leaves a blank space. Sometimes it shows a tofu box. Sometimes it substitutes a glyph from a completely different script because the fallback list is misconfigured. Recognizing the symptom tells you which part of the pipeline is failing.
Get the Full Details
Running the Test and Reading the Results
To test this yourself, you need a plain text string and access to the rendering path your software uses. Run the phrase through your editor, browser, or application with the font you suspect. Look at how the apostrophe renders. Check whether the tailed y glyphs in Betty are shaped the same way in both occurrences. Verify that the final t in Didnt aligns correctly with the following space. If the apostrophe appears as a straight prime mark instead of a typographic apostrophe, your font may lack the proper glyph or the application may not support smart quote substitution. If one y looks different from the other, your shaping engine might be applying different contextual alternates, or one instance is falling back to another font. If spaces are inconsistent, kerning is either disabled or the font's kern table is malformed. I once spent half a day debugging a report where certain usernames displayed broken characters. The root cause was a custom font embedded in a PDF export that had a broken cmap mapping for the curly quote character. The fallback went to a system font with a very different style, so the name looked half handwritten. The workaround was to preprocess the text and replace problematic characters with compatible alternatives before export, while also fixing the embedded font subset.
Common Pitfalls That Make This Worse
The first trap is assuming that installing a font fixes everything. A font can be installed and still not contain the glyphs your string needs. Check the font's coverage with a tool like fonttools or an online cmap inspector before relying on it. The second trap is enabling too many OpenType features at once. Features like ligatures, contextual alternates, and ordinal substitution interact in unpredictable ways when fallback occurs mid-string. If your text spans two fonts, the second font may not have the same feature set, so the rendered output looks inconsistent. A third trap is trusting what you see in a rich text editor. Word processors often substitute characters silently. A WYSIWYG preview may show correct glyphs because the editor uses its own shaping logic, while the exported or published version uses a different engine. Always verify the final output in the exact rendering environment where users will see it.
When This Method Breaks Down
The Betty Bunny Didnt Do It Michael Kaplan test is useful for exposing basic shaping and fallback problems, but it will not catch every issue. It does not test right-to-left scripts, complex Indic shaping, or Mongolian script rendering. It also will not reveal problems that only appear at specific point sizes, since some font bugs are size-dependent. If you need to validate those cases, you need different test strings and targeted tests for each script and layout direction. Another limitation is that modern browsers and operating systems have improved fallback behavior significantly over the past few years. A string that exposed a bug three years ago may render fine now, masking the underlying configuration problem until you upgrade something else and the bug returns. For projects that require rigorous typographic validation, I recommend pairing this quick check with automated font coverage testing and continuous integration tests that render sample text to images and compare them against expected output. Tools like pytest with headless rendering, or dedicated font validation suites, will catch regressions faster than manual inspection.
Practical Steps to Fix the Most Common Issues
If your test string reveals broken rendering, start by identifying the failing character. Check the font's Unicode coverage. If the character is missing, add a fallback font that includes it, or replace the character with a compatible variant. If the character is present but rendered incorrectly, inspect the OpenType feature settings in your application or CSS. In CSS, use font-feature-settings or the shorthand font-variant properties to control which features are enabled. Be careful with overriding features globally, since disabling a feature for one script can break another. Set feature flags at the component level when possible. If you are working with web fonts, ensure that the font file includes the necessary subsets. Subsetting can remove rarely used glyphs, including punctuation. Test your subset configuration with representative strings before deploying to production.
For desktop applications, verify that the text shaping library you use is up to date. Older versions of HarfBuzz and DirectWrite had bugs in fallback handling that have since been patched. Updating the library often resolves issues without changing any font files.
Why This Matters Beyond One Test Phrase
Using a simple phrase like Betty Bunny Didnt Do It forces you to confront the reality that text rendering is a chain, and any weak link shows up in the final output. It is easier to ignore that chain when you only test with basic Latin alphabet strings. The moment you include mixed punctuation, repeated letters, or characters near the edge of a font's coverage, the chain reveals its weaknesses. The takeaway is practical. Test with strings that stress your rendering pipeline. Document which fonts you rely on and what coverage they provide. Automate the validation where possible. And when something looks wrong, assume the problem is in the pipeline, not in the user's display, until you prove otherwise.
