Hello,
We have an internal service that uses com.aspose.pdf.TextFragment.setText() to replace place holder text in various pdf documents. Our users have reported that some of the pdfs are being kicked out by our system and upon investigation I’m seeing the exception “com.aspose.pdf.internal.ms.System.l7k: Format of font “Symbol” is not supported for new composite fonts”.
I’ve reduced the code down to a simple test program to try and rule out anything on our end with the code. This test program still encounters the exception. I’m unclear what could be the cause as I’m seeing this on my dev laptop running OSX 12.6.8 and the actual server runnning RHEL 7.9.
I’ve attached the sample code and 3 sample pdfs that generate the exception. Any guidance would be greatly appreciated.
Glei_9780679747048_sr_xp_r1_p1-15.pdf (2.9 MB)
Zimb_9780812974447_sr_xp_r1_pa-4.pdf (2.7 MB)
Root_9780679738961_sr_xp_r1_p1-19.pdf (1.4 MB)
samplecode.zip (1.9 KB)
@dmauler1
We tested the case with 23.11 version of the API and got below console output:
Search String: AutomatedPrintedInLocation
There are 1 occurrences of AutomatedPrintedInLocation in the text fragment collection for page4
com.aspose.pdf.TextFragmentCollection@63716833
item com.aspose.pdf.TextFragment@7123be6c
Found an occurrence of AutomatedPrintedInLocation on page 4
Font name : TimesNewRomanMTStd
Font size : 8.49975
Line spacing: 0.0
Position : ( 139.8453, 91.21303075 )
Setting text segment to: A LOCATION
Font name : {}TimesNewRoman
Font size : 8.49975
Font style : Regular
Would you please make sure that you are using 23.11 version of the API? Also, we want to add that we tested on a Windows machine initially. Would you please confirm if program is working fine in Windows environment at your end and creating issue only in Linux? We will log an investigation ticket and share the ID with you.
It looks like we were on 23.1, so I rebuilt against 23.11 but the issue persists on linux/osx. We’re primarily a linux shop but I was able to get a hold of a windows server to run it on. It appears to execute without an exception on windows server 2019. Could this be some sort of OS supplied font issue?
@dmauler1
Yes, it is highly possible that the issue is happening due to fonts. Can you please try installing all windows fonts e.g. msttcorefonts package in Linux. You can also copy paste all windows fonts in the system where this issue is occurring. Please let us know about the outcomes you got after doing this.
Sorry for the long delay in response!
I was able to copy the fonts over from a windows server to the affected linux servers and that did the trick.
For anyone else that comes across this issue with missing ms core fonts please try the following. (Make sure you’re licensed for this)
- On the windows computer open file browser and enter %windir%\Fonts to get to the fonts.
- Copy paste each font from the fonts folder to a new folder. This should explode out the font ttf files.
- Assuming a RHEL system copy the fonts to /usr/local/share/fonts (create directory if not present)
- Run fc-cache /usr/local/share/fonts
- Restart any affected services.
@dmauler1
Its nice to know that your issue has been resolved and yes, shared details would definitely help other with the similar scenario. Please feel free to create a new topic in case you need further assistance.