Hi Ido,

FYI, The next version of QuickPDF will solve that speed problem.

Hi Ido,

Because I cannot confirm that you have the same problem it is impossible to give you a categoric answer. Would you be so kind and give it yurself a try with the 5.15 version? Of course that I can do a test myself, but as I say always :-) please send me a sample PDF + sample Delphi/C++/VB/c#/VB.NET snippet to test your problem.

Regards, Marian

Ingo, I did not forget about those.

The change proposed by Ulrich was already implemented. Because of that there is no information about Ulrich in that place. Anyway if you check the sourcecode you will see major changes around that place (code optimization + other bug corrections).

The second suggestion proposed by IanN is a little bit complicated and I was not able to confirm the reality of this problem. I have profiled a lot of times my sourcecode and I was never able to identify performace penalty caused by PDF page selection. The only penalty I may confirm is the processing of PDF Images. Because of that I skiped over this change till some real proof (email with PDF sample to me) or time is available.

Regards, Marian

.... before I will not forget I want to thank everybody for your feedback. I have spent a lot of time improving on this library and I'm sure that with the propper support we can go further.

Regards, Marian

Hi, before I continue I have a question for Ingo.

Ingo, you said that some changes are missing from sources. Can you please be more specific about which changes you are talking about?

Hi, great to see that someone is checking my results. I am not happy to see when someone is checking unnecessary my cosmetic work(expected to see more checks on program results) but I have to admit that I am happy to see some feedback at all.

First I see that everybody wants to know why I had to change the source code layout. The reason is that I use QPDF.ActiveX in one of my projects and because I hat a lot of troubles with rendering I changed and checked everything what from my point of view was suspicious. The cosmetic change was necessary because I found most of the times small troubles hidden inside the old compacted layout and I wanted to understand the whole logic before I go through with a new design.

This way I was able not only to identify logic problems but also points of interest for a future redesign.

I understand that someone may hope that the development will continue from the old base code, but as long as the manufacturer is not active I believe is better to go further with a new design.

I understand that this change may scare you but without this change there is no hope for a real next release and my work is finished. At the end we don't want to keep the old not-yet-detected stuff but fix them and continue with that what is missing (at least that was my intention when I joined this community).

For your information all of my changes regards exclusive the rendering capabilities. Everything else comes from discussions with other members. Most of my changes are commented inside the source code (search for "Marian" or "// <"Marian" ) and you will see:

• enhancements (annotation processing (document link, Url, external link))
• logic improvements (like added "else" between "if"'s)
• remove redundant blocks
• rewrite entire logic: in image processing I process data without buffering + correction on processing image operation (inversed image or image with mask).

... to be continued.