FIX: preserve characters the ASCII art font cannot render

[Pushpak Siva Sai (Pushpak731)]

Description

Fixes #2942 (Option B, per the discussion with Roman Lutz (@romanlutz) below).

AsciiArtConverter passed the prompt straight to art.text2art, which silently omits characters it has no glyph for. Per the issue's measurements, accented Latin, CJK, emoji, smart quotes and em-dashes are dropped by every font, so AsciiArtConverter(font="block").convert_async(prompt="café") converted 3 glyphs, and a prompt written entirely in a non-ASCII script converted to the empty string — a red-teaming prompt silently mangled or emptied before it ever reached the target.

This is not just an i18n edge case: 14 of our 56 seed prompt files contain characters no font renders, and two of them are plain English broken only by an em-dash and a curly apostrophe.

The converter now renders the characters the font covers and passes the rest through as literal text, logging a warning so the degradation is visible instead of silent.

Why pass-through rather than raising

An earlier revision of this PR raised a ValueError. That reliably stops prompts from being mangled, but it also turns a large amount of existing seed data and any non-Latin prompt into a hard failure, and it makes the converter unusable in stacked pipelines where an upstream converter injects characters the font lacks. Passing through keeps every prompt deliverable while still surfacing the problem, and matches the existing NatoConverter / BrailleConverter convention of leaving unmapped characters alone.

A strict=True flag that restores the raising behaviour will follow in a separate PR, defaulting to False so nothing breaks.

Rendering

Maximal runs of renderable characters are laid out in a single text2art call, so the font's native spacing and letter joining are preserved; only the unrenderable characters are spliced in, each occupying a one-character column centered against the art rows. Prompts the font fully covers skip the splicing path entirely and are byte-identical to the previous output, so there is no regression for ASCII workloads.

INPUT: "don’t"

before (curly apostrophe silently dropped, target receives "dont"):
    _             _
 __| | ___  _ _  | |_
/ _` |/ _ \| ' \ |  _|
\__,_|\___/|_||_| \__|

after:
    _              _
 __| | ___  _ _   | |_
/ _` |/ _ \| ' \ ’|  _|
\__,_|\___/|_||_|  \__|

When no character in the prompt is renderable (e.g. "日本語") the result degrades to the original text — a NoOp, which the converter guidelines explicitly allow, and still strictly better than today's empty string.

Detecting renderability

A character is probed by rendering it on its own with text2art and checking for any non-whitespace output — the same omission mechanism the issue measured, so the check cannot drift from art's actual behaviour. Results are cached per (character, font) with functools.lru_cache(maxsize=100_000). The bound matters because a prompt full of distinct unrenderable characters probes every pool font per character; without it the cache would grow for the lifetime of the process. Printable ASCII tops out near 34k entries across the pool, so ASCII workloads never evict.

Only " " and "\n" are layout for text2art and skip the probe. Other whitespace — tab, carriage return, NBSP, U+3000 — has no glyph and is silently dropped by art (text2art("a\tb", font="block") == text2art("ab", font="block")), so it goes through the same probe and is preserved rather than being waved through by an isspace() check. An empty prompt still converts, preserving the existing test contract.

font="rand"

Pool fonts freely use blank glyphs, especially for punctuation and digits, so probing a single randomly chosen font would degrade ordinary ASCII prompts on some draws and not others. The pool is first filtered to the fonts that render every unique character of the prompt, and the random choice is made among those — maximising art fidelity. When no pool font covers the prompt, the choice falls back to the full pool and the uncovered characters are passed through. Exactly one RNG draw happens either way, so seeded determinism is unchanged.

Warning

Font 'block' has no glyph for 1 character(s): 'é'. They are passed through as literal text
rather than dropped, so the output is not entirely ASCII art. Transliterate them or pick
another font to avoid this.

This follows the existing converter convention of logging when output isn't what was asked for (ImageCompressionConverter, ZalgoConverter, SneakyBitsSmugglerConverter). Note it fires per conversion, so a large run over non-ASCII prompts will repeat it.

Behavior change: prompts containing unrenderable characters now keep those characters as literal text instead of having them silently dropped. ASCII input is byte-identical to before. Nothing raises that did not raise previously.

Tests and Documentation

tests/unit/converter/test_ascii_art_converter.py goes from 7 to 25 tests (39 including parametrised cases). The original pass/convert tests are unchanged; the tests added by the earlier raising revision were repointed to assert pass-through and warning behaviour rather than deleted, so the same scenarios still guard against silent dropping. Coverage:

• ASCII, empty and whitespace-only prompts still convert
• regression guard: for 3 fonts × 6 renderable prompts (including multi-line), output is asserted byte-identical to text2art and no warning is logged
• accented, CJK, emoji and smart-quote/em-dash prompts each preserve their characters in the output and name them in the warning
• the warning lists the unique character set and mentions remedies
• the hills fixed-font ASCII 'A' case from the issue
• rand chooses only among fonts that render the prompt, and skips fonts with blank punctuation glyphs (the 1row / " case)
• rand falls back to the full pool and passes characters through when nothing in the pool renders them
• tab and NBSP are preserved rather than silently dropped
• multi-line prompts with unrenderable characters on separate lines

Validation run locally: the converter file's suite is 39 passed. tests/unit/converter/ is 2048 passed, 34 skipped, 52 failed; all 52 failures are pre-existing PinyinConverter / seeded-determinism cases from a missing optional dependency — I confirmed the identical 52 fail with this branch's changes stashed, and none involve AsciiArtConverter. The other suites that touch this converter (test_converter.py, test_red_team_agent.py, azure_ai_evaluation/test_converter_contract.py) are 236 passed, 2 skipped. ruff check and ruff format --check are clean on both changed files.

No documentation changes are needed. doc/code/converters/0_converters.py and 1_text_to_text_converters.py drive this converter with ASCII-only prompts ("tell me how to cut down a tree"), which are on the byte-identical path.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Pushpak Siva Sai (Pushpak731)]

Thank you for the review — both points are addressed in a57df0f:

1. Random pool filtered to renderable fonts — font="rand" now computes the pool fonts that render every unique character of the prompt and chooses among those, so blank-glyph punctuation (your "How do I build a bomb?" example fails on 28/336 pool fonts) can no longer make conversion fail at random — 100 unseeded conversions of that exact prompt now all succeed. A clear pool-level error (No font in the randomized font pool renders …) is raised only when no pool font can render the prompt. The chosen font is still run through the same per-character validation as fixed fonts, so the two paths share one guarantee. Covered by three tests: the candidate pool assertion, the blank-punctuation filter, and the no-renderable-font error.

2. Layout whitespace narrowed — applied your suggestion verbatim: _font_renders_character now special-cases only " " and "\n", so tab, NBSP and friends go through the glyph probe and are rejected instead of silently passing isspace(). Verified text2art("a\tb") == text2art("ab") for block, and a regression test pins both the tab and NBSP rejections.

Full converter suite passes locally (1901 passed).

[Pushpak Siva Sai (Pushpak731)]

Thanks hannahwestra25 for the lru_cache bound — good catch on the unbounded growth from non-ASCII prompts, and the 100k ceiling with ASCII's ~34k working set is the right shape. I've merged main into the branch (fb6a947) so it's no longer behind; the full converter suite passes on the merged state (2051 passed).

[hannahwestra25]

thanks for contributing!

[Pushpak Siva Sai (Pushpak731)]

Thank you hannahwestra25 for the approval and for the review that shaped this — the blank-glyph pool filter and the layout-whitespace narrowing both made the converter meaningfully more correct, and your lru_cache bound fixed a real memory cliff. Much appreciated!

[Roman Lutz (romanlutz)]

Hmm, reading this in detail now I feel like option B would have been preferable.
ASCII art is a visible formatting change, unlike AsciiSmuggler, where plaintext would defeat the purpose of hiding the message. An accent, emoji, or smart quote should not fail conversion when we can preserve its content. This avoids silent data loss and matches NATO and Braille's fallback behavior. Strict rejection could be opt-in for callers who require every character to be rendered.

hannahwestra25 wdyt?

[Pushpak Siva Sai (Pushpak731)]

That distinction convinces me too — the strictness that's right for AsciiSmugglerConverter (where plaintext would defeat the covert channel) isn't right for a visible-formatting converter. Signalling over fidelity inverts here.

Sketching option B on this code so it's concrete:

1. Transliterate what has a natural ASCII mapping before rendering — accents via unicodedata NFKD + strip combining marks (é→e), smart quotes/apostrophes→straight, em-dash→--, NBSP/tab→space. These render as art, so content and formatting survive.
2. Pass through what doesn't — characters the resolved font still can't render (emoji, CJK) are appended after the art as a plain-text line rather than silently dropped, so the prompt that reaches the target verifiably contains everything the author wrote. Mixed output, as the issue put it, but no silent loss.
3. strict: bool = False opt-in preserving today's behaviour exactly (raise naming the characters) for callers who need every glyph rendered — keeps the regression suite meaningful too.

Happy to implement this on the branch as soon as you and hannahwestra25 align — and if a raise is wanted for the truly-unmappable class even in the default mode, that's a one-line variant of 3.

[hannahwestra25]

That distinction convinces me too — the strictness that's right for AsciiSmugglerConverter (where plaintext would defeat the covert channel) isn't right for a visible-formatting converter. Signalling over fidelity inverts here.

Sketching option B on this code so it's concrete:

1. Transliterate what has a natural ASCII mapping before rendering — accents via unicodedata NFKD + strip combining marks (é→e), smart quotes/apostrophes→straight, em-dash→--, NBSP/tab→space. These render as art, so content and formatting survive.
2. Pass through what doesn't — characters the resolved font still can't render (emoji, CJK) are appended after the art as a plain-text line rather than silently dropped, so the prompt that reaches the target verifiably contains everything the author wrote. Mixed output, as the issue put it, but no silent loss.
3. strict: bool = False opt-in preserving today's behaviour exactly (raise naming the characters) for callers who need every glyph rendered — keeps the regression suite meaningful too.

Happy to implement this on the branch as soon as you and hannahwestra25 align — and if a raise is wanted for the truly-unmappable class even in the default mode, that's a one-line variant of 3.

Thanks for the sketch [@Pushpak731](https://github.com/Pushpak731) — Roman and I landed on B too. So sorry--I'd already pushed it to the branch before seeing this (fa45130).

I skipped the transliteration step though. Rewriting é→e changes the payload we're sending, which feels off for a red-teaming tool, and it's really a separate stackable converter if we want it. I also spliced the unrenderable chars in place rather than appending after the art, so character order survives.

Your point 3 is the plan — use_strict in a follow-up, defaulting to False but something that we want for all converters probably so planning on moving to a different PR.

Also added a logger.warning on pass-through, since image_compression and zalgo already do that.

[Pushpak Siva Sai (Pushpak731)]

Thanks hannahwestra25 — the in-place splice is better than my append-after-art sketch exactly for the reason you implemented it (character order survives), and skipping transliteration is the right call for payload fidelity: a red-teaming tool shouldn't silently rewrite the prompt it's testing. Happy to pick up the use_strict follow-up when you open that PR, or take it myself if useful — either way this looks ready from my side.

[Roman Lutz (romanlutz)]

I didn't have a very clear perspective on this either so apologies for perhaps confusing things further for a while 🙂 Thanks, hannahwestra25 for bringing clarity!