Stirling PDF: cannot save Thai, Cyrillic or Chinese text in a form

A simple test name works. With the actual name, saving fails or characters disappear when you reopen the file. First check whether a completed PDF was created at all. A server error during saving and an incorrectly displayed saved file are different starting points.

A specific Stirling PDF report describes a problem filling Helvetica form fields in Docker versions 3.1.0 and 3.2.0. According to the reporter, Thai, Cyrillic and Chinese test values cause HTTP 500, while a Latin-script control value works. The log mentions Helvetica and WinAnsiEncoding. This is a documented report, not a claim about every PDF or every software version. Q1

Which symptoms are you seeing?

Try to match your situation to one of these observations:

An older Stirling report illustrates the second and third situations: Chinese and Japanese text is not consistently visible after saving, and the author describes differences between Chrome and Safari. This does not establish that every such display difference has the same cause. Q2

Why adding another font may not be enough

Check character coverage, the encoding used and correct rendering separately. The PDFBox documentation distinguishes encoding errors from support for complex writing systems. Finding a font file does not answer all these questions. Q3

The affected form field also needs to use the appropriate font. In the reviewed Stirling source code at v3.1.0, the error-handling path being examined tries a Helvetica font again. It follows that having another font file available does not establish that the field is configured to use it. Q5

Your specific file therefore matters: a particular field, the actual text entered and the output generated from it.

First checks: a small test to narrow down the problem

1. Keep the original. Create a working copy. Record where the template came from and whether the completed form needs to remain editable. Where possible, start with a test template that contains no sensitive information but exhibits the same problem.

2. Identify the form type. PDF forms can store field values and their visible appearance in separate structures. They may also contain an XFA structure. The pypdf documentation explicitly describes these differences. A finding about AcroForm fields should therefore not be applied to XFA without checking. Q4

If your tool cannot find the expected fields, stop at this point. Installing another font package does not explain why the field structure was not recognised. If necessary, ask the document’s creator for a suitable editable template.

3. Test one field twice. In separate fresh copies, first enter a simple control value, then a short value containing the affected characters. Use the same field and the same process. Record whether the error appears during entry, during saving or only when the file is reopened.

4. Keep the exact error message. For a server error, useful details include the time, Stirling version, field name and a short log excerpt. A reference such as U+0E19 identifies a particular character. In the report examined here, Helvetica and WinAnsiEncoding provide a more specific line of investigation than a general statement that “Unicode does not work”. Q1

5. Recheck the saved file. If a file was created, close the initial view and reopen that exact output. Then compare it in the program the recipient actually uses. Record what is visible in each viewer. This avoids confusing a successful preview with a file that works when shared.

6. Check the actual text. Compare the full written form, including marks, spacing and character order. If you are unfamiliar with the writing system, ask someone who can read it to assess the result. Text can look plausible while still representing the name incorrectly. If copying or automated processing is part of the workflow, check that result separately too.

Which correction fits the finding?

For a confirmed font or encoding error, the correction should address the field in use and how its output is generated. For an existing output file that displays differently, compare the field values with their visible appearance. If a different form type or an editing restriction is involved, clarify that finding first.

Then choose a small, verifiable change: for example, a corrected template, a font assignment shown to be suitable, or a vendor-documented change to the processing path in use. Repeat the same test values afterwards. An installed font, a successful restart or a green save dialog is only an intermediate result.

Do not silently change someone’s name to another spelling to conceal a technical error. If a process requires transliteration, that is a separate decision about the required content.

Already signed? Clarify the intended workflow first

Adobe explains that digital signatures can restrict further editing. Changes may require an original, unsigned version. A font correction should therefore not take the place of a signature check. Preserve the signed file unchanged and establish which changes are permitted in the intended workflow. Q6

Whether the document is already signed, whether a signature is valid and whether further form changes are permitted are separate questions. A basic file inspection should not answer all of them with a single “all clear”.

When is the result usable?

Define acceptance against your actual workflow. The problematic name can be saved. The output file can be reopened. The text renders correctly in the destination program. The full written form is preserved.

If the form must remain editable, include a further permitted editing step in the check. If the file will be printed, copied or read by software, test that specific additional use. Keep the template, software version, test value and result together. This verifies the combinations tested, not support for every language.

Frequently asked questions

The right font is already in the container. Why does the field still fail?

Availability and actual use are different questions. The reviewed Stirling source shows another Helvetica attempt in the error-handling path. Check which font the affected field actually uses. Q5

Will simply saving the input file as UTF-8 help?

That does not establish that the PDF uses a suitable font encoding. Use the WinAnsi error to check the specific character and font path in use. Q3

The name looks right in another browser. Does that mean the file is fixed?

That is a useful comparison. Still check the saved file in the destination program. The older Stirling report specifically describes different display results. Q2

Should I flatten the form so its fields are no longer editable?

Only if that fits the intended workflow. Flattening converts form-field contents into ordinary page content and removes the form fields themselves. It therefore changes whether the form can be edited later. Check the required output before choosing this approach. Q4

Will any large Unicode font cover every language?

There is no basis for such a blanket promise. Check the actual test values, including whether they render correctly. Q3

Will an update automatically solve the problem?

The sources reviewed do not establish a specific Stirling release that fixes this report. Record the installed version and test a documented correction with the problematic template. Changing versions alone is not an acceptance check.

Describe your issue

Include the Stirling version and installation method, the affected step, the field name and what happens when you save. Add the error text and a short, non-sensitive test value using the same types of characters. The form type, destination program and whether the file is already digitally signed are also useful details.

Describe your issue