I’m running my own PDF generator as a Pickaxe action to generate brand-styled PDFs. The problem is that in about 10% of all cases, the content sent by Pickaxe has broken letters. Usually, the German umlauts or sometimes exclamation marks and question marks are broken.
For example, this is content that was sent, like I can see in the log of the action:
Dossier: Iran Krieg 2026 6 Umfassende Analyse ffcr C1 DaF-Lernende ## Historische Hintergrfcnde Der Iran-Krieg, insbesondere der achtje4hrige Konflikt zwischen Iran und Irak von 1980 bis 1988, hat tiefgreifende historische Hintergrfcnde, die bis in die koloniale und geopolitische Konstellation des Nahen Ostens reichen.
Highlighted bold words are the ones where there is a broken umlaut. Should be : für, Hintergründe. achtjährige, Hintergründe.
This is from the following session ID: 6bc8ccc8-b795-4a85-b457-fce8843e9aa3
How can I prevent this from happening? Gemini tells me there’s some kind of formatting issue with the way Pickaxe sends the content towards my script, my Python script. Maybe you can give me advice on how to prevent this from happening, because I tried it with the Pickaxe coded PDF generator and it’s not happening there. The styling is very basic, so I would prefer to make it work with my own action PDF generator.
1 Like
Anyone has an idea on this one? @lindsay_support
Hi @easydeutsch ,
Thank you for reaching out. We were able to take a closer look at the custom PDF action from the session you shared.
The issue does appear to be related to character encoding in the custom action/PDF generation flow. The German umlauts seem to be converted into escaped/encoded values before they reach your PDF service, and then the PDF service appears to handle those values incorrectly.
Our native PDF generator avoids this by preserving the content as UTF-8 before passing it into the PDF generator. To make your custom action behave more like the native PDF generator, the important part is to make sure the markdown/HTML content stays UTF-8 all the way through the flow.
In your custom action and external PDF service, please make sure that:
- The text is not converted into ASCII-only JSON.
- Unicode characters are preserved instead of escaped or stripped.
- The request body is encoded and parsed as UTF-8.
- The PDF generator receives the original text with the umlauts still intact.
- The PDF font you use supports German characters like ä, ö, ü, and ß.
So the main thing to check is the part of your custom action where the content is serialized and sent to your PDF service, as well as the part of your PDF service that parses the request body. The content should remain UTF-8 from Pickaxe to your PDF generator.
1 Like
Well, @danny_support that should all be implemented like this, but if I actually look into the action runs, I can see that it already gets sent sometimes with corrupted letters. Shown here in that screenshot, for example. ID: 3ca7b736-3cf3-4ce9-b070-7d6289156194
And according to Claude, there is nothing I can personally do about it because this is already sent, corrupted by Pickaxe, to my Python function.
Is there a way to solve this so I can reliably create PDFs? If every 8, 9, or 10 comes out with corrupted letters, I can just recreate it, but it just looks very unprofessional towards my customer.
If me and Claude are wrong, please let me know, but to me it looks like that’s already Pickaxe server-side corruption and has nothing really to do with my custom action.
Hi @easydeutsch,
Apologies for any confusion caused by my earlier message. After taking a closer look, you were right to flag this as an issue on our side.
Our engineering team is actively working on a fix under PRD-896, and I will update you here as soon as I have confirmation that it has been resolved.
We appreciate you bringing this to our attention. The information you shared was very helpful in our investigation.
2 Likes
Hey @danny_support ! Do you have any timeline for me because the problem seems to increase in frequency .. I did some testing yesterday and it happend like every 3rd or 4th time I had the custom actions running…
hi @easydeutsch !
should have a fix out by EOD tomorrow PST. i may have some minor alterations for your custom action code but i will check back in once a fix has been pushed.
thanks for followin up & talk soon
1 Like
Hey Carson any update here? I kinda managed to bypass the problem with teh help of Wingman my simply bypassing the chat trigger and triggering the action via Button that also speeds up the entire process from 30-60sec to like 5sec 
But I am sure that this could still cause problems down the line so would be great if it gets resolved 
hi Jan ! 
following up here: should be all set ! nice work on the custom code as a workaround. it shouldn’t be needed anymore !
i was testing using B1 - Goethe - Sprechen and did not see any instances of something like “für” turning into “f\u0000fcr” or something like that in model conversations or outputted PDF; but please let us know if it still persists !!
1 Like
