Re: Font operation takes a long time with 3.0.1

Tested the new snapshot. Performance looks good. Cache file excerpt: ➜ ~ grep -i NotoSansKannada .pdfbox.cache *skipexception*|TTF||0|0|0|0|0||/System/Library/Fonts/NotoSansKannada.ttc|b930924c|1700331239000 BR Kjetil tir. 5. des. 2023 kl. 15:10 skrev Tilman Hausherr : > Thanks for the feedba

Re: Font operation takes a long time with 3.0.1

Thanks for the feedback. It turns out that there's another error (checksum was empty because MessageDigest doesn't support CRC32), which has been fixed now, please test again (delete the file first). The second-to-last field should now not be empty. It also teaches an important lesson: a "// n

Re: Font operation takes a long time with 3.0.1

Nice! Tested it now and I can confirm that it fixes the issue. I see good performance even from the first operation. Checked the cache file and there is a line for this font there now: ➜ ~ grep -i NotoSansKannada .pdfbox.cache *skipexception*|TTF||0|0|0|0|0||/System/Library/Fonts/NotoSansKannada

Re: Font operation takes a long time with 3.0.1

Thanks, new snapshot build here: https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/3.0.2-SNAPSHOT/ Ticket: https://issues.apache.org/jira/browse/PDFBOX-5727 Tilman On 05.12.2023 08:41, Kjetil Ødegaard wrote: To clarify, this stack trace is not printed anywh

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

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

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

> Tilman > > -- Original-Nachricht -- > Von: Kjetil Ødegaard > Betreff: Font operation takes a long time with 3.0.1 > Datum: 04.12.2023, 16:21 Uhr > An: users@pdfbox.apache.org > > Hi, > > I tried to upgrade an app to PDFBox 3.0.1 and I see a performance issue. &

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

AW: Font operation takes a long time with 3.0.1

jetil Ødegaard Betreff: Font operation takes a long time with 3.0.1 Datum: 04.12.2023, 16:21 Uhr An: users@pdfbox.apache.org 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

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