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

[zbowyer20bi]

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

[Professionalize.Discourse]

@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

[andrey.potapov]

@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

[zbowyer20bi]

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

[andrey.potapov]

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

[zbowyer20bi]

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.

[andrey.potapov]

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

[andrey.potapov]

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

[andrey.potapov]

@zbowyer20bi,

@zbowyer20bi

This is necessary as Aspose uses a number of default directories to fetch fonts from. These often contain system default fonts. This set of directories can’t be configured.

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/”

@zbowyer20bi

Fonts are sometimes substituted for defaults even though the font is available on the system and has been loaded using FontsLoader.loadExternalFonts. This is at least partially related to the Aspose cache used for fonts. FontsLoader.clearCache() will sometimes fix the issue. Question: Is this the only way to update the cache when the external font folder has been updated? No write expiry or TTL?

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.

@zbowyer20bi

Sometimes even when using FontsLoader.clearCache() and ensuring all fonts are available, fonts are substituted. This is not reproducible in a predictable way, but seems to be related to the number of fonts in the cache and we have reproduced it when the cache contains 30+ fonts.

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?

@zbowyer20bi

Sometimes in our warning messages we see that fonts are being substituted for themselves. For instance, 1 - Font will be substituted from Wingdings to {Wingdings,OpenSymbol}. Question: Is this just confusion around the wording of the log message? Or is there a bug here? When Consolas is being substituted we don’t see that in the bracket-enclosed list.

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.

@zbowyer20bi

Sometimes including some fonts in the file triggers an error around casting from one Aspose type to another. This recurs until specific fonts are removed from the file, but later on the same files can be converted without issue. I noticed this happening with Farisi, Baghdad and Mishafi fonts.

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