Font operation takes a long time with 3.0.1

Hi, I tried to upgrade an app to PDFBox 3.0.1 and I see a performance issue. It only affects the first PDF operation (after that it's quite fast), but it's a bit annoying since it takes about 20 seconds (on my M1 Macboox). Profiling reveals that this Kotlin code triggers the delay: val font

AW: Font operation takes a long time with 3.0.1

This should happen only once in 3.0.1, unless you're working with a container without font cache file in the image. SHA512 checksum is done only if the file modification date of a font file has changed, then we check whether the content has changed. Tilman -- Original-Nachricht -- Von: Kjetil

Re: Font operation takes a long time with 3.0.1

I think the commit contains a typo: 872 private static String computeHash(byte[] ba) 873

Re: [External Sender] Re: PDFBox 3.0.1 compile dependency on junit-jupiter

For anyone else using TestNG for unit tests, you'll need to explicitly exclude JUnit until this is fixed; otherwise, Surefire will refuse to use TestNG. org.apache.pdfbox pdfbox 3.0.1 org.junit.jupiter junit-jupiter Gili On 2023-12-03 20:47, Dan Rabe wrote: Great, thank you! We’ll loo

Re: Font operation takes a long time with 3.0.1

It happens for me each time I restart the app. The first time it takes ~20 seconds, the next time it's much faster. This is using openjdk 21.0.1 on macOS Sonoma 14.1.2 (not using Docker). Checked ~/.pdfbox.cache and it gets written every run. Did some debugging and it looks like I'm hitting this c

Re: Font operation takes a long time with 3.0.1

Does the stack trace appear at every start? If yes then it's a bug. The intent of the current code is that bad fonts aren't retried. The font cache file should contain a line with "*skipexception*" for that font. Can you look at it for the two font files? I could change SHA512 to CRC32. It has

Re: Font operation takes a long time with 3.0.1

Please do also post the full (for pdfbox / fontbox) stack trace. I have a theory why it happens, which is that addTrueTypeCollection() does not add the font as "*skipexception*" to the cache file because it's not done in the exception handler. Tilman On 04.12.2023 21:17, Tilman Hausherr wrote

Re: Font operation takes a long time with 3.0.1

To clarify, this stack trace is not printed anywhere. I got it from stepping into the code and invoking printStackTrace() on the exception to get the whole stack. See complete stack trace below. I agree with your theory, it matches what I'm seeing. These fonts are never added to the cache file, so