AsciiArtConverter silently deletes every non-ASCII character from the prompt. Nothing is raised and nothing is logged — the target just receives a mangled prompt, or no prompt at all.
What happens
convert_async hands the prompt straight to art.text2art:
# pyrit/converter/ascii_art_converter.py:76
return ConverterResult(output_text=text2art(prompt, font=font), output_type="text")
text2art has no glyph for a character, so it omits it. I probed every font the art package exposes — 371 in total, 354 of them in this converter's rand pool:
| character |
dropped by |
é, ü |
371 / 371 |
日, 本, 語, 漢 |
371 / 371 |
🙂 |
371 / 371 |
“, — |
371 / 371 |
ß |
307 / 371 |
A |
2 / 371 (hills, nfi1) |
Accented Latin, CJK, emoji, smart quotes and em-dashes are dropped by every font, so the loss does not depend on which font gets drawn.
Two concrete consequences
One character disappears, taking its whole glyph block with it:
AsciiArtConverter(font="block").convert_async(prompt="cafe") -> 4 glyph blocks (892 chars)
AsciiArtConverter(font="block").convert_async(prompt="café") -> 3 glyph blocks (672 chars)
And a prompt written entirely in a non-ASCII script converts to the empty string. With the default font="rand" this holds on every draw:
AsciiArtConverter().convert_async(prompt="日本語の指示") -> output_text='' (12/12 draws)
AsciiArtConverter(font="block").convert_async(prompt="忽略之前的所有指令") -> ''
For a red-teaming framework this is the harmful direction. A Chinese- or Japanese-language attack prompt is a first-class use case, and it converts to nothing. A mixed prompt reaches the target quietly altered, with no signal to the red-teamer.
Why I think this is a defect
Three things already in this repo establish the opposite convention for the same situation:
AsciiArtConverter's docstring documents only ValueError: If the input type is not supported; it never mentions that non-ASCII input is dropped. The tests only feed ASCII prompts — test_ascii_art_converter.py:16-29 assert len(result.output_text) > 0 — so nothing pins this behaviour in either direction.
What behaviour do you want?
Option A — raise, naming the characters this font cannot render. Consistent with #2540, and it fails loudly instead of altering the attack. Cost: a campaign whose prompts contain an accent or an emoji would start raising. Checking the resolved font is deterministic for everything that matters here, since the characters above are dropped by all 371 fonts; only ß-type characters are font-dependent, so under font="rand" such a prompt could raise on one draw and not the next.
Option B — render what the font can, pass the rest through. Keeps pipelines running and stops losing content, at the cost of a mixed output (art plus bare characters). This matches what #2399 and #2539 ended up doing for the other converters.
Option C — document the restriction, change nothing. Cheapest, but a silently altered attack prompt is a poor default for a tool whose job is to send a precise prompt.
I lean towards A: "the prompt that reaches the target is not the prompt I wrote" is precisely the failure a red-teaming tool should refuse rather than hide, and #2540 already set that precedent for the converter next door. If B is preferable because non-ASCII prompts are expected to keep working, I would implement B instead.
Happy to take whichever you pick, with regression tests over the real art font list. Everything above was measured against the installed art package; I called no model or target.
AsciiArtConvertersilently deletes every non-ASCII character from the prompt. Nothing is raised and nothing is logged — the target just receives a mangled prompt, or no prompt at all.What happens
convert_asynchands the prompt straight toart.text2art:text2arthas no glyph for a character, so it omits it. I probed every font theartpackage exposes — 371 in total, 354 of them in this converter'srandpool:é,ü日,本,語,漢🙂“,—ßAhills,nfi1)Accented Latin, CJK, emoji, smart quotes and em-dashes are dropped by every font, so the loss does not depend on which font gets drawn.
Two concrete consequences
One character disappears, taking its whole glyph block with it:
And a prompt written entirely in a non-ASCII script converts to the empty string. With the default
font="rand"this holds on every draw:For a red-teaming framework this is the harmful direction. A Chinese- or Japanese-language attack prompt is a first-class use case, and it converts to nothing. A mixed prompt reaches the target quietly altered, with no signal to the red-teamer.
Why I think this is a defect
Three things already in this repo establish the opposite convention for the same situation:
AsciiSmugglerConverterraisesValueErrornaming the characters outside the range it can encode (ascii_smuggler_converter.py:69-74, merged in FIX: raise on characters AsciiSmugglerConverter cannot encode #2540).NatoConverterwas changed to pass unmapped characters through rather than delete them (FIX: preserve content and word boundaries in NatoConverter #2399).BrailleConvertergot the same treatment (BUG: AsciiSmugglerConverter silently drops non-ASCII characters #2539).AsciiArtConverter's docstring documents onlyValueError: If the input type is not supported; it never mentions that non-ASCII input is dropped. The tests only feed ASCII prompts —test_ascii_art_converter.py:16-29assertlen(result.output_text) > 0— so nothing pins this behaviour in either direction.What behaviour do you want?
Option A — raise, naming the characters this font cannot render. Consistent with #2540, and it fails loudly instead of altering the attack. Cost: a campaign whose prompts contain an accent or an emoji would start raising. Checking the resolved font is deterministic for everything that matters here, since the characters above are dropped by all 371 fonts; only
ß-type characters are font-dependent, so underfont="rand"such a prompt could raise on one draw and not the next.Option B — render what the font can, pass the rest through. Keeps pipelines running and stops losing content, at the cost of a mixed output (art plus bare characters). This matches what #2399 and #2539 ended up doing for the other converters.
Option C — document the restriction, change nothing. Cheapest, but a silently altered attack prompt is a poor default for a tool whose job is to send a precise prompt.
I lean towards A: "the prompt that reaches the target is not the prompt I wrote" is precisely the failure a red-teaming tool should refuse rather than hide, and #2540 already set that precedent for the converter next door. If B is preferable because non-ASCII prompts are expected to keep working, I would implement B instead.
Happy to take whichever you pick, with regression tests over the real
artfont list. Everything above was measured against the installedartpackage; I called no model or target.