Dear Marcus,
The reason why we were unable to notify you in a timely manner when the version 13.1.3 was released was that after confirmation, Microsoft Word automatically replaces characters in Verdana font that do not support rendering when saving Word as PDF with other fonts. The replacement font chosen by Microsoft (such as Cambria) differs from the replacement font used in our product (such as Arial Unicode MS). At present, our dev team is still conducting in-depth analysis of the situation and striving to find solutions to ensure better compatibility and consistency. You can currently solve your problem by installing this font (Arial Unicode MS) in the system.
Sorry, we do not have an open system for users to independently query the status of issues based on their bug ID.
Sincerely,
Nina
E-iceblue support team
Hello,
Thank you for your feedback.
Glad to inform you that the issue has been resolved and the new version (Spire.Doc for Java Version:13.5.3) is available. Please download it for using. If you have any other questions later, please contact us in time. Thank you in advance.
Sincerely,
Tommy
E-iceblue support team
Thank you for your feedback.
Glad to inform you that the issue has been resolved and the new version (Spire.Doc for Java Version:13.5.3) is available. Please download it for using. If you have any other questions later, please contact us in time. Thank you in advance.
Sincerely,
Tommy
E-iceblue support team
-
Tommy.Tang - Posts: 85
- Joined: Mon Apr 21, 2025 7:05 am
Hello Tommy!
These are really good news. Just for my understanding: The font "Arial Unicode MS" is not required to be installed on the server that generates the PDF document. It is sufficient if the fonts that are used in the Microsoft Word document (i.e. the docx file) are embedded into it. As soon as this is the case the PDF document will show all the characters correctly and not by means of a placeholder (i.e. something that looks similar to ☐ in the generated PDF document), right?
Kind regards,
Marcus
These are really good news. Just for my understanding: The font "Arial Unicode MS" is not required to be installed on the server that generates the PDF document. It is sufficient if the fonts that are used in the Microsoft Word document (i.e. the docx file) are embedded into it. As soon as this is the case the PDF document will show all the characters correctly and not by means of a placeholder (i.e. something that looks similar to ☐ in the generated PDF document), right?
Kind regards,
Marcus
-
mgattinger - Posts: 65
- Joined: Fri May 21, 2021 9:03 am
Hi Marcus,
Sorry for the misunderstanding caused by the unclear response earlier.
Theoretically, if a font is embedded in the document, it will be used to render the text after conversion — but only if the font supports all characters in the document. The word document you provided embeds the Verdana font, which is a Western font and does not support Chinese or Hindi characters. As a result, during conversion (including when using Microsoft Word to convert to PDF), these unsupported characters will be automatically replaced with other available fonts that do support them.
Our Spire.Doc follows the same logic, when the system lacks the required font and no suitable replacement is found, the system will fall back to Arial Unicode MS, a font with better multilingual support and broader compatibility.
Therefore, we recommend conducting tests on your side with Arial Unicode MS installed to ensure accurate rendering.
Sincerely,
Nina
E-iceblue support team
Sorry for the misunderstanding caused by the unclear response earlier.
Theoretically, if a font is embedded in the document, it will be used to render the text after conversion — but only if the font supports all characters in the document. The word document you provided embeds the Verdana font, which is a Western font and does not support Chinese or Hindi characters. As a result, during conversion (including when using Microsoft Word to convert to PDF), these unsupported characters will be automatically replaced with other available fonts that do support them.
Our Spire.Doc follows the same logic, when the system lacks the required font and no suitable replacement is found, the system will fall back to Arial Unicode MS, a font with better multilingual support and broader compatibility.
Therefore, we recommend conducting tests on your side with Arial Unicode MS installed to ensure accurate rendering.
Sincerely,
Nina
E-iceblue support team
-
Nina.Tang - Posts: 1379
- Joined: Tue Sep 27, 2016 1:06 am
Hi Nina!
I should give you a short description of the use case of our web application.
1. We create a Word reporting template (a docx file). As we are the report designer we use any font (e.g. Arial, Verdana, etc.). The reporting template contains placeholders (bookmarks) that will be replaced by actual data which we don't know in advance. Hence, we also include some characters of fonts (typically on the last page) we are likely expect to find in the final generated report (e. g. SimSun, DengXian, etc.) and applying the effect "hidden" (available from the Word font properties) on these respective paragraphs so that they are not visible by default (see attached screenshot). We enable the Word setting to embed all of these fonts into the reporting template.
2. This reporting template (docx file) is uploaded into our web application which runs on an Ubuntu server. The server does not contain any fonts, so we have to rely solely on the fonts that are embedded into the reporting template.
3. Our customer requests the final report from our web application (the finished report is now generated). At this stage, Spire.Doc for Java comes into play and is used to load the reporting template (the docx file), insert the actual data (consisting of any Unicode characters) and save the generated report as a PDF document. The generated report is then downloaded from the customer's computer.
And we expect Spire.Doc for Java to handle this use case.
If you tell me to which email I can send a typical reporting template, I'm happy to do it.
I should give you a short description of the use case of our web application.
1. We create a Word reporting template (a docx file). As we are the report designer we use any font (e.g. Arial, Verdana, etc.). The reporting template contains placeholders (bookmarks) that will be replaced by actual data which we don't know in advance. Hence, we also include some characters of fonts (typically on the last page) we are likely expect to find in the final generated report (e. g. SimSun, DengXian, etc.) and applying the effect "hidden" (available from the Word font properties) on these respective paragraphs so that they are not visible by default (see attached screenshot). We enable the Word setting to embed all of these fonts into the reporting template.
2. This reporting template (docx file) is uploaded into our web application which runs on an Ubuntu server. The server does not contain any fonts, so we have to rely solely on the fonts that are embedded into the reporting template.
3. Our customer requests the final report from our web application (the finished report is now generated). At this stage, Spire.Doc for Java comes into play and is used to load the reporting template (the docx file), insert the actual data (consisting of any Unicode characters) and save the generated report as a PDF document. The generated report is then downloaded from the customer's computer.
And we expect Spire.Doc for Java to handle this use case.
If you tell me to which email I can send a typical reporting template, I'm happy to do it.
Login to view the files attached to this post.
Last edited by mgattinger on Fri Jun 13, 2025 7:15 am, edited 2 times in total.
-
mgattinger - Posts: 65
- Joined: Fri May 21, 2021 9:03 am
Hi Marcus,
Thank you for providing the detailed information — I now have a clear understanding of your use case.
To help us better investigate, please send your typical reporting template to our email [email protected], or attach it here if possible. We'll get back to you as soon as we have further findings.
Sincerely,
Nina
E-iceblue support team
Thank you for providing the detailed information — I now have a clear understanding of your use case.
To help us better investigate, please send your typical reporting template to our email [email protected], or attach it here if possible. We'll get back to you as soon as we have further findings.
Sincerely,
Nina
E-iceblue support team
-
Nina.Tang - Posts: 1379
- Joined: Tue Sep 27, 2016 1:06 am
1, 2