What do you mean "sequential scanning"? Text extraction is fast, but
rendering is indeed slow.
I mentioned the website just to prove that PDFBox isn't the only one
slow in rendering. The cause is the incredible complexity of that PDF. I
suspect that it results in lots of intermediate images getting created.
Tilman
On 28.06.2023 20:02, William Melendez wrote:
Seems to me we are redirecting the issue away from the original submission. The program
is not written to "display" anything except print to screen in a stand-alone
PC. No web version. The issue here is the inability to do sequential scanning of each
Interactive PDF. That was the issue I had sought help with.
I think if we can stay focused on that, we may be able to find out why the
problem exists. Anyways, thank you for your input.
Will Melendez, MBA
Product Development Engineer | Stratis IoT | RealPage, Inc.
2201 Lakeside Blvd | Richardson, TX 75082
william.melen...@realpage.com |http://www.realpage.com/
w: 1-972-810-2191
-----Original Message-----
From: Tilman Hausherr<thaush...@t-online.de>
Sent: Wednesday, June 28, 2023 12:41 PM
To:users@pdfbox.apache.org
Subject: Re: Slow rendering
[You don't often get email fromthaush...@t-online.de. Learn why this is
important athttps://aka.ms/LearnAboutSenderIdentification ]
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On 28.06.2023 19:24, Esteban R wrote:
Hello. The following pdf:https://gofile.io/d/mlmpoW (simplification of a real
life example) takes too long to render (PDFToImage or PDFDebugger) with pdfbox
2.0.28 (more than 30 secs) and less then 5 secs with other tools. I get the
same results for pdfbox-app-3.0.0-alpha3.
The file also takes a long time to render on that website, probably with
PDF.js. From what I see it goes very deep (but not endless), this is one of the
objects in that PDF:
