QuickPDF v5.15 Release Candidate 1

I have a real problem with this release. I have just begun to evaluate it, so I don't really know how it is going to function yet, but it appears there have been a number of useless and unnecessary changes made to the code.

For example look at the function GetFormFieldBound in the unit uiSEDQuickPDF. Someone has reformatted the text to make it look like what their idea of pretty code is. There have been no changes to the code, and yet when it is run through vdiff, it shows to have had every line changed. This is a real problem and makes evaluation of changes much harder than they should be.

PLEASE DON'T CHANGE THE CODE UNLESS IT NEEDS TO BE CHANGED!

Ingo wrote: Hi Harry! Marian had made the code more readable (for himself). To evaluate you should take the freeware WinDiff. There you should activate the option "Ignore White Space" - Then it's more easier. Best regards, Ingo

I understand the reason, I just think it is a major mistake. No change should be made for any reason other than to fix a problem, or to add a feature. What is easier for one person is harder for someone else. Unnecessary changes are just asking for problems.

Ignoring white space will not solve the problem. In many cases declarations were moved from one line to another and show up as changes. The code has been altered in ways that were just completely uncalled for and should never happen.

PLEASE DON'T CHANGE THE CODE UNLESS IT NEEDS TO BE CHANGED!

swb1,

Your reply was much more diplomatic than mine and that's probably the tone I should have taken with my original post. I really don't intend to belittle all the work that has gone into making these changes, but I think this is very important. I have spent some time looking through the code.
We use Starteam for our source control and I normally just use the vdiff that comes with Starteam, but for a comparison of entire directories I use Ultracompare (http://www.ultraedit.com/). Either product makes it very simple to do quality control checks on changes. Unfortunately with the source code in the 5.15 Release Candidate 1 there are so many cosmetic changes that it becomes practically useless.

It is critical to the quality of the code base not to make unnecessary changes.

Thanks
Harry

Hi!

I've seen that few changes posted in section
"Submissions for changes for v5.15"
(specially few from JanN) are missed in the sources.

To all source-testers:
Please check which posted modifications from "Submissions for changes for v5.15" should be implemented, too and post the links here. So we (i?) can insert it in the second beta or the final release.

Thanks again to Marian for his efforts! Is there anybody else wanted to dig more deeper in the code? I can't imagine that Marian is the only one?!

Best regards,
Ingo

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.

Edited by marian_pascalau

.... 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

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

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

Hi Ido,

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