Intermittent Issues in Font Selection When Using Aspose.Slides for Java

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:

FontsLoader.loadExternalFonts(new String[]{fileConverterConfig.getFontsDirectory()});

Aspose version: 24.11
JDK 21

@zbowyer20bi

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:

  1. 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.

  2. Font Loading: You are currently using the following line of code to load external fonts:

    FontsLoader.loadExternalFonts(new String[]{fileConverterConfig.getFontsDirectory()});
    

    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.

  3. 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.

  4. 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.

  5. 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.

Sources:
[1]: Font Selection Sequence in C#|Aspose.Slides Documentation
[2]: Java Slides Presentation Conversion - Aspose

@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

Thanks Andrey. I am building a reproduction now and will forward when ready.

@zbowyer20bi,
Thank you for helping make Aspose.Slides for Java better. We will be waiting for additional information.

Hi @andrey.potapov, I have created a reproduction here: GitHub - zbowyer20/aspose-slides-repro at fonts-repro

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.

@zbowyer20bi,
I need some time to check the issue. I will get back to you soon.

@zbowyer20bi,
Thank you for your patience.

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.

@zbowyer20bi,

We use the following list of directories:

Windows
C:\Windows\fonts

Linux
“/usr/share/fonts”,
System.getProperty(“user.home”) + “/.fonts”,
“/usr/local/share/fonts”,
“/usr/X11R6/lib/X11/fonts”,
“/usr/openwin/lib/X11/fonts”,
“/opt/kde3/share/fonts”,
“/usr/share/X11/fonts”,
“/run/current-system/sw/share/X11-fonts”

MacOS
“Path_To_Personal_Folder/Library/Fonts/”,
“/Library/Fonts/”,
“/Network/Library/Fonts/”,
“/System/Library/Fonts/”,
“/System Folder/Fonts/”

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).

Hi Andrey, thanks for the response.

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 will add a stack trace as soon as I’m able to reproduce the problem, in the meantime I did get repeated errors with the file I’ve just added to my repo: aspose-slides-repro/testFiles/diff-fonts.pptx at fonts-repro · zbowyer20/aspose-slides-repro · GitHub

@zbowyer20bi,
Thank you for your message. I have forwarded your answers and questions to our developers.

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,
Thank you for the additional information. I’ve forwarded it to our developers.

@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.

aspose-slides-25.3.4-jdk16.zip.zip (2.2 MB)
aspose-slides-25.3.4-jdk16.z01.zip (8 MB)
aspose-slides-25.3.4-jdk16.z02.zip (8 MB)
aspose-slides-25.3.4-jdk16.z03.zip (8 MB)
(Remove the last “.zip” from the file names before extracting them)

Could you please test this version and let us know the results?

Thanks Andrey. I’ll experiment with this today.

@zbowyer20bi,
Thank you for helping make Aspose.Slides better. We will be waiting for your feedback.

Hi @andrey.potapov, I’ve not reproduced any of the issues so far. I can’t be certain as it was hard to reproduce even before, but so far so good :slight_smile:

@zbowyer20bi,
Thank you for the information. I’ve forwarded it to our developers.