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]
