https://issues.apache.org/jira/browse/PDFBOX-6220
I looked at it again now that I'm more awake and I think it's easy, I'll do something and post when done. Tilman On 2026/07/16 19:04:05 Tilman Hausherr wrote: > Hi, > > Thank you, that makes sense. > > Feel free to create a ticket in JIRA with a patch attached. If you need to > register, put a short text that we know it's you and not a spammer. > > I assume what you did was to check the gsubWorkers map before calling > gsubWorkerFactory.getGsubWorker(), correct? > > Tilman > > On 2026/07/16 09:15:07 Olivier Bruchez wrote: > > Hi, > > > > Profiling PDF text rendering with openhtmltopdf (PDFBox 3.0.4, but I also > > checked 3.0.8 and trunk), I found that GsubWorkerForLatin.applyGsubFeature > > builds a new GlyphArraySplitterRegexImpl on every call. That regex depends > > only on the font, not on the text, but it gets rebuilt on every showText > > call, because PDAbstractContentStream recreates the GsubWorker in setFont > > on every call instead of keeping the one already cached in gsubWorkers. > > > > In our specific case, on a 14-page PDF, using a font with a ccmp feature > > (Inter), this rebuilding represents most of the time spent drawing text. > > Caching the splitter regex per font (local test with patched PDFBox) saves > > about 250 ms. The output is unchanged. > > > > I'm not familiar with the PDFBox code, so I'd appreciate your advice on > > whether this is the best way to fix this. I'm happy to open a JIRA issue > > and a PR if that's useful. > > > > Thanks, > > Olivier > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
