[PDFBOX-5684] Font cache isn't effective on my machine, always rebuilds

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.29, 3.0.0 PDFBox
• Fix Version/s: 2.0.30, 3.0.1 PDFBox, 4.0.0
• Component/s: FontBox
• Environment: macOS 13
• Assignee: Tilman Hausherr
• Reporter: Mike Hearn
• Created: 15/Sep/23 11:35
• Updated: 05/Dec/23 08:23
• Resolved: 24/Sep/23 08:58

Description

I see that FontBox has a font caching implementation. Whenever I try to use PDFTextStripped on one specific PDF I have, it triggers the computation of this cache (I'm not sure why it doesn't need to for the others). This is very slow. If the cache really worked I could live with that but every time, it decides the cache isn't valid and rebuilds it.

The issue is this line here in FileSystemFontProvider.loadDiskCache:

 

if (!pending.isEmpty())
{
    // re-build the entire cache if we encounter un-cached fonts (could be optimised)
    LOG.warn("New fonts found, font cache will be re-built");
    return null;
}
 

I don't know why "pending" is never empty as I'm not installing new fonts or changing my font configuration in any way, but my guess is, if some fonts fail to load then they don't enter the cache but this fact isn't recorded. So they are always seen as "new". It's just a guess based on the fact that I see errors related to being unable to load some fonts during this process, e.g.

Could not load font file: /System/Library/Fonts/Supplemental/NotoSansBamum-Regular.ttf
java.io.IOException: Unknown substFormat: 0 @ org.apache.fontbox.ttf.GlyphSubstitutionTable.readSingleLookupSubTable(GlyphSubstitutionTable.java:372)

Issue Links

• is related to: PDFBOX-5727 Font operation takes a long time with 3.0.1