Do you have an issue with a specific file(s)? : No
Can you reproduce using one of our samples or online demos? : Yes
Are you using the WebViewer server? : No
Does the issue only happen on certain browsers? : No
Is your issue related to a front-end framework? : No
Is your issue related to annotations? : No
Please give a brief summary of your issue: the line break shifting issue with Japanese fonts in Office files.
(Think of this as an email subject)
Please describe your issue and provide steps to reproduce it:
(The more descriptive your answer, the faster we are able to help you)
When uploading Office files that have Japanese fonts embedded, the line breaks may shift. Even if we install the fonts on our server and upload the files, the same situation occur. There may be no issue with MS P Gothic regarding line break shifts. However, with the most commonly used Japanese fonts currently on Windows, such as Meiryo and Yu Gothic, problems occur.
Is there any way to avoid these issues and align the line breaks? If not, we would like you to take measures regarding the line breaks of Japanese fonts and perform a version upgrade.
Please provide a link to a minimal sample where the issue is reproducible:
attachments are when uploading a file with embedded Japanese fonts and uploading it to Showcase.
A yellow line is drawn where the line breaks are shifted.
I’m Marcus from the Apryse support team. Thank you for bringing this to our attention. Our team was able reproduce the issue you are seeing when converting your word files to PDF.
I have brought up this behavior to our development team. We will reach out to you when we have more information on a solution here.
I received an email from you in January and learned that this issue had been resolved.
Since I am currently unable to upgrade the development SDK, I checked using the following URL: https://sdk.apryse.com/samples/web/samples/viewing/viewing/
While the line-breaking issue has been resolved, the embedded fonts are being replaced with different fonts.
The “Meiryo” font in the top block is clearly not “Meiryo.”
Additionally, the three blocks below it should each have different fonts, but they are all displayed with the same font.
Is there any possibility that this can be improved?
I believe the reasoning for why you are seeing a potential difference of font is because of how font is handled in accordance to our documentation:
Basically when certain fonts are not available, a substitution is performed which changes the fonts that are used to the next most similar. You can configure this in a few ways, such as ensuring that the proper fonts are available when your original DOCX file is loaded.
You can also choose to embed the fonts within the file before you load the file. The file when loaded into WebViewer converts the file to PDF, so ensuring the fonts are embedded within the file will ensure proper font is used. I have uploaded a version of the DOCX file which contains the fonts that are embedded, and an output PDF which shows what the results will now look like.
Please let me know if you see any other issues here.
The screenshot attached on April 7, 2025, uses the file “フォント用(埋め込みあり).docx” that was attached on September 25, 2024.
This file has embedded fonts.
Here, I am not referring to the downloaded file, but rather to the display on the viewer side.
As you showed in your attachment, I have confirmed that the downloaded file retains the embedded font and that the line breaks are correct. However, that is not the issue I am pointing out.
In our currently used version 10.12.1, fonts are not hosted on the server, but the embedded fonts can still be confirmed when the same file is displayed in the viewer.
(Same as I mentioned in the attachment from September 25, 2024. but there was still the issue of the line breaks not displaying correctly.)
In the newer version, the line break issue appears to have been resolved.
However, does this mean that, unless the fonts are hosted on the server, the viewer will not display the fonts correctly, even if they are embedded in the file?
I recognize this as a significant change.
Is there any plan for the viewer to display as it did in the previous versions?
The fonts should be retained when you choose to embed them within the file. Below I have attached a screenshot which shows the results I’m getting when loading your file between WebViewer and how it looks like when you display it with Microsoft Word.
When examining the PDF file metadata for the fonts used, the correct fonts appear to be retained when you compare the paragraph fonts between the two. Can you please examine the screenshot and let me know which parts you are having problems with? My screenshot looks different from the one you provided. I am using the WebViewer demo we host on our website to test this.
If the issue is reproducible, what are the differences between the Viewer hosted by you and the above URL’s Viewer?
If the issue is not reproducible, could the differences between the devices on our side have an impact on this behavior?
We conducted testing using the latest version of Chrome on Windows 11 across two devices, and in both cases, the fonts displayed were different (as seen in the provided screenshot).
Could you let us know why this happens, or share any potential factors that may influence this behavior?
This is not fully accurate, only some fonts are embedded. It can be difficult to get MS Word to fully embed all fonts in a Word file. The last two font styles are not actually embedded.
As for the difference between showcase.apryse.com and https://sdk.apryse.com/samples/web/samples/viewing/viewing/ is that the latter is just the sample that comes in our SDK download and is maintained by the SDK dev team, while showcase is special sample created and managed by our website team. So there can be subtle differences between the two.
or share any potential factors that may influence this behavior?
You would want to setup your own self serve web fonts so that you have full control over font substitution (for the missing embedded fonts), see this guide.
