We are finding that font selection is not consistent when using Aspose Slides. A font in a converted presentation will be set as Arial, which doesn’t match the source. This seems to be dependent on the number of fonts in the source directory we point Aspose to, with the issue more likely to appear as this directory grows.
It doesn’t look like the issue is related to any specific font: we have been able to replicate with Cambria, Segoe UI and Source Sans Pro. Even though we have included these in the fonts directory we are pointing Aspose Slides to, they occasionally get converted to Arial.
This is the specific line of code we’re using to set the font sources:
It seems you are experiencing inconsistent font selection when using Aspose.Slides, particularly with certain fonts being replaced by Arial during conversion. This issue appears to be influenced by the number of fonts in the directory you are using.
Here are some steps and considerations that may help you address this problem:
Font Availability: Ensure that the fonts you are trying to use (like Cambria, Segoe UI, and Source Sans Pro) are indeed available in the operating system where Aspose.Slides is running. If the specified font is not found, Aspose.Slides will substitute it with a default font, which in your case seems to be Arial.
Font Loading: You are currently using the following line of code to load external fonts:
Make sure that the fileConverterConfig.getFontsDirectory() is correctly pointing to the directory containing the required fonts. If the directory contains too many fonts, it might lead to conflicts or issues in font selection.
Font Substitution Rules: Check if there are any font substitution rules defined in your application. If specific rules are set, they may override the default behavior and lead to unexpected font replacements.
Testing with Fewer Fonts: Since you mentioned that the issue seems to worsen as the number of fonts increases, try testing with a smaller set of fonts in the directory. This can help identify if a specific font or a combination of fonts is causing the issue.
Aspose.Slides Documentation: For more detailed information on how Aspose.Slides handles font selection and substitution, you can refer to the official documentation on font selection sequences. This documentation outlines how Aspose.Slides searches for and applies fonts during presentation loading and conversion.
If the problem persists after trying these suggestions, consider reaching out to the Aspose support community for further assistance, as they may have additional insights or solutions based on similar experiences.
@zbowyer20bi,
Please ensure that the fonts you are trying to use are indeed available for your application on the operating system where the code is executed (try to load a font file in memory). If the fonts are available and the issue persists, please share the following additional files and information:
sample presentation file
code example to reproduce the problem
output file
OS version on which the code was executed
number of fonts in the folder from which the fonts are loaded
There are a few questions included around how the font cache works which might help to solve part of the problem, but there are a few more intermittent issues which I can’t reliably reproduce without knowing how the caching mechanism internals work. It seems like there might be some limits to the cache size affecting us.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): SLIDESJAVA-39646
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Yes, we use only FontsLoader.clearCache(). But it is worth clarifying right away that this works for adding fonts. If you remove fonts during work and then add them again, this can lead to unexpected results, since fonts are cached by the JDK itself.
Could you please describe this scenario in more detail? Do you load fonts all at once or one by one? Do you clear the cache before adding new fonts?
The message about replacing a font with itself is usually due to the fact that the font was not found among the fonts installed in the operating system. However, during the replacement, it was found in the shared fonts folder.
Could you please share the stack trace of the error? We will also need a set of fonts, the code that you use, and a presentation file that reproduces this problem (even if the frequency of reproduction is low).
This is good to know. Just to confirm, there is no way to override these? It would make it easier to create a controlled environment for reproductions.
To confirm, it is therefore expected that we should clearCache() when adding new fonts one by one to the folder, otherwise we will only have the set of fonts that were in that folder (and the system folders) the first time we added our external folder? It didn’t look like this was necessary with both Aspose Words and Aspose Cells.
I have replicated the fundamentals of our workflow in my repo at https://github.com/zbowyer20/aspose-slides-repro/tree/fonts-repro: we add sets of fonts to that folder as required. Up until now we weren’t clearing the cache each time and it sounds like that’s necessary, but doesn’t solve the full extent of the intermittent problems we’re seeing. If the fonts are cached by the JDK, maybe there’s default configuration for the cache size (or ttl?) we can tweak to reproduce our issues more reliably?
If the font was found in the shared fonts folder at the time it would ideally be used instead of substitutions - but I guess the problem is that it’s not in the cache? Maybe there’s an opportunity to have a flag to reset the cache if this situation happens? Or at least to update the warning description to avoid this confusion.
I have recreated this locally again, but it still only happens intermittently so I’m not able to share a repeatable reproduction.
The errors I’m getting indicate some classpath issue:
exception when converting to PDF class com.aspose.slides.internal.mi.t2 cannot be cast to class com.aspose.slides.internal.mi.vv (com.aspose.slides.internal.mi.t2 and com.aspose.slides.internal.mi.vv are in unnamed module of loader org.springframework.boot.loader.launch.LaunchedClassLoader @4a574795)
This happens when I’m trying to convert a file and there would be a font substitution. To start with, I’m able to convert the file as expected and have the font substitute. But at some point we start getting the above error. I have to remove the font from the file to continue. Perhaps something happens to corrupt the cache? I have witnessed this both locally and on a deployed environment, so it’s not isolated to a single environment.
I’ve also witnessed it using multiple different versions of Aspose Slides. 24.11 (which was the same as the other Aspose dependencies in my application) and now 25.3 (the other dependencies continue to sit on 24.11). But there’s only one version of Aspose Slides in my dependency tree at any one time.
@zbowyer20bi,
Since the real data you tested on still differs from the data used in our testing, we have prepared a special version of Aspose.Slides with fixes for the issues we were able to reproduce—both in Docker and on a custom Debian environment.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.
