Asian characters are not being rendered correctly.

[realtonyig]

As you can see I input the following characters: Chinese : 中文 Japanese: 日本語 English: English But after saving, only English can be correctly rendered.

Here's the screenshot of input:

Screenshot after saving and reopened by chrome:

I'm using 1.1.1 and deployed by docker. Here're the docker compose file I used:

  stirling-pdf:
    image: docker.stirlingpdf.com/stirlingtools/stirling-pdf:latest-fat
    ports:
      - '18081:8080'
    volumes:
      - /opt/StirlingPDF/trainingData:/usr/share/tessdata # Required for extra OCR languages
      - /opt/StirlingPDF/extraConfigs:/configs
      - /opt/StirlingPDF/customFiles:/customFiles/
      - /opt/StirlingPDF/logs:/logs/
      - /opt/StirlingPDF/pipeline:/pipeline/
    environment:
      - DOCKER_ENABLE_SECURITY=false
      - LANGS=en_GB,en_US,ja_JP,zh_CN,zh_TW
      - SYSTEM_DEFAULTLOCALE=en-US

It would be greatly appreciated if this issue could be addressed. Thank you!

[dosubot[bot]]

Hi @TonyInTokyo! I'm Dosu and I’m helping the Stirling-PDF team.

The most likely reason Asian characters aren't rendering is missing fonts in your Docker container. Even with the LANGS variable set, the necessary CJK fonts (like Noto Sans CJK) might not be present or installed correctly, especially if there were errors during the image build or font installation process. This is a known issue with non-Latin scripts in Docker deployments of Stirling-PDF example.

To troubleshoot:

1. Enter your running container and check if CJK fonts are present, e.g.:

   docker exec -it <container_name> ls /usr/share/fonts/opentype/noto
   

   You should see files like NotoSansCJK-Regular.ttc or similar. If not, the fonts are missing.

2. Check the container logs for any font installation errors or warnings.

3. If fonts are missing, you can manually download the required Noto CJK fonts and place them in /opt/StirlingPDF/customFiles/static/ on your host. The container will pick up custom fonts from this directory docs.

4. Restart the container after adding fonts.

If the problem persists, try rebuilding the container or using a different image version, as some builds have reported font installation failures example.

Let me know if you need specific instructions for downloading and mounting the fonts.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[realtonyig]

@dosu Thank you for the prompt reply.

1. Here're the fonts in /usr/share/fonts/opentype/noto on docker.

Meiryo.ttf                  NotoSansArabic-Regular.ttf  NotoSansSC-Regular.ttf      SimSun.ttf
NotoSans-Regular.ttf        NotoSansJP-Regular.ttf      NotoSansThai-Regular.ttf    malgun.ttf

As you can see, the NotoSansJP and NotoSansSC do exist. 2. There's no erros in log 3. I tried to download NotoSansCJK-Regular.ttc/NotoSansJP-Regular.ttf/NotoSansSC-Regular.ttf and put them into /opt/StirlingPDF/customFiles/static/ 4. Whatever restarting container or redeploying it, it won't work. Just like the screenshot I sent in the first post.

Anything else I can try?

[dosubot[bot]]

A few things to check that often resolve this issue:

1. Make sure your custom CJK fonts are in /opt/StirlingPDF/customFiles/static/fonts/ (not just /static/), and that the filenames exactly match what Stirling-PDF expects: for Japanese, Meiryo.ttf; for Chinese, SimSun.ttf; for Korean, malgun.ttf. The app looks for these specific names and locations—any difference will cause silent fallback to a default font, which usually means missing CJK text. See more on this in the docs and from code analysis.

2. Try setting LANGS=ALL in your docker-compose. There are cases where specifying only some languages in LANGS misses required fonts for proper rendering, and LANGS=ALL has fixed similar issues for other users with non-Latin scripts (example).

3. If you still have issues, check the output PDF in a viewer that can show font info (like Adobe Acrobat’s font properties) to see which fonts are actually embedded or referenced. This can help spot if the wrong font is being used or if the CJK font is missing.

Let me know if this helps or if you want to dig deeper into log verbosity or minimal font setups.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[realtonyig]

@dosu I tried to change the font to Japanese, Meiryo.ttf; for Chinese, SimSun.ttf as you mentioned and put them into /opt/StirlingPDF/customFiles/static/fonts/ . But nothing changed. But I did find something. Here's the file it generated: Welcome (6).pdf I found that it does not render correctly in chrome, but works in safari(I'm using a mac). Hope the above information can help you to address the issue soon.

[dosubot[bot]]

This is a known issue with cross-browser PDF rendering—Safari and Chrome use different PDF engines, and if a font isn't embedded in the PDF, each browser will substitute from system fonts differently. Stirling-PDF is designed to embed CJK fonts directly, so if Asian characters are missing in Chrome but visible in Safari, it's likely the fonts weren't embedded and Safari is using system fonts that Chrome can't access.

To confirm, open the PDF in a tool like Adobe Acrobat and check the document's font properties: if you don't see your CJK fonts (like Meiryo, SimSun, or Noto Sans CJK) listed as embedded, that's the cause.

The most reliable fix is to set LANGS=ALL in your Docker config and rebuild/restart the container. This ensures all necessary fonts are installed and available for embedding, which has resolved similar issues for other users with non-Latin scripts (example). Make sure your custom fonts are in /opt/StirlingPDF/customFiles/static/fonts/ with exact filenames.

If the fonts are embedded and the issue still appears only in Chrome, it's likely a limitation of Chrome's PDF engine, not Stirling-PDF itself. In that case, you may want to try viewing the PDF in a dedicated PDF reader or report the rendering difference to the Chrome team.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[realtonyig]

@dosu The font I saw is Helvetica. The other information: With font Helvetica it can be rendered in safari and PDFGear(app in macos) correctly. And once I open it by PDFGear and save without any operation, the saved file can be rendered in chrome correctly. The font is still Helvetica. Maybe the chrome's PDF engine has some issue, but what I don't understand is why with the same font, the file saved by PDFGear can be rendered correctly in chrome, while Stirling-PDF cannot. There must be something different between the 2 pdfs. Here're the 2 files

1. Saved by Stirling-PDF Stirling-pdf.pdf
2. Re-opened by PDFGear and save without any operation PDFGear.pdf Hope this can help to address the issue.

[dosubot[bot]]

The difference is that Stirling-PDF references Helvetica as a standard PDF font but does not embed it, so Chrome (which is strict about font embedding and Unicode mapping) can't render Asian characters—Helvetica doesn't include CJK glyphs. Safari and PDFGear are more forgiving and substitute system fonts, which is why you see the text there. When you re-save with PDFGear, it rewrites the PDF structure (possibly updating encoding or ToUnicode maps), making it compatible with Chrome, even though the font name is still Helvetica.

Stirling-PDF only embeds fonts (and repairs encoding) when you use the PDF/A conversion feature. If you want reliable CJK rendering in Chrome, use the "Convert to PDF/A" tool in Stirling-PDF—this will embed the necessary fonts and fix the encoding so all browsers display the text correctly. There’s no config or toggle to force this for all jobs; only the PDF/A flow guarantees embedded fonts and robust Unicode mapping.

More details on this behavior are in the codebase and have been discussed in related issues (example).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[realtonyig]

@dosu I tried PDF/A feature. Here's the result:

1. PDF/A-1b No, it doesn't work. Even worse, it removes all the asian characters. (Both Stirling-pdf.pdf and PDFGear.pdf)
2. PDF/A-2b No. It doens't work as well. But it doesn't remove asian characters, just keep as it is. Which is Stirling-pdf.pdf: not rendering, PDFGear.pdf: rendering well.

[dosubot[bot]]

This is a known limitation in Stirling-PDF: the PDF/A conversion doesn't reliably embed or handle CJK (Chinese, Japanese, Korean) fonts. The PDF/A-1b flow often removes Asian characters if it can't find or embed a suitable font, and PDF/A-2b may leave them present but still unrenderable in strict viewers like Chrome. This happens because the embedding logic is generic and doesn't have special handling for CJK fonts—if embedding fails, the code just continues, so characters disappear or remain invisible in some viewers. PDFGear, on the other hand, rewrites the PDF structure and repairs encoding or Unicode maps, which is why its output works in Chrome even if the font name is still Helvetica (details).

Right now, there isn't a config or advanced setting in Stirling-PDF to force robust CJK font embedding for PDF/A output. The most reliable workaround is to post-process the PDF with a tool like PDFGear to repair the encoding for Chrome compatibility. If you need this fixed natively, it would require an update to Stirling-PDF's PDF/A conversion logic to better handle CJK fonts and Unicode mapping (technical explanation).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[Frooodle]

Let me check on this, thanks for raising

[atimofeev]

Have you managed to solve this? I have a similar issue with cyrillic characters.