Corrupt File After Saving

[jeffp]

I have a corruption issue I can't seem to make sense of. See the attached two files.

Document1.pdf is a file from a client. I am able to open and save this file with the code below.

Document1 - Append.pdf is the same Document1.pdf but with two pages appended to the end using your DLL calls. However, if I open and then save this document with the code below, the file gets corrupted.

Any idea what's wrong with the appended file?

NOTE: I can open and save the append file in the ViewerAX just fine. It's just in the DLL calls it gets corrupted.

Code: Select all

hr := PXCp_ReadDocumentW(FDocID, PWChar(WideString(AFileName)), 0);

hr := PXCp_WriteDocumentW(FDocID,
      PWChar(WideString(AFileName)),
      PXCp_CreationDisposition_Overwrite,
      PXCp_Write_NoRelease);

[Lzcat - Tracker Supp]

Strange behaviour. Resulting document contain reference to non-existing object (PDFCreactiveX), and it is strange that this object was not saved.
Can you provide sample code which help us reproduce such problem?

[jeffp]

Strange. The PDFCreativeX object is a reference to the old PDF component we used from Amyuni Technologies before we switched to your PDF tools.

Is the object in both the Document1.pdf AND the Document1 - Append.pdf files?

Document1-Append.pdf was createf only with your tools so it sounds like the PDFCreativeX object was there to begin with in Document1.pdf (the original file). Is that correct? or not?

If so, the strange this is why can you open and save Document1.pdf and not the append file.

Again, the Document1.pdf is already in existence on a client machine and they have many other files like it.

Please let me know if PDFCreativeX object was in the original Document1.pdf file and I'll work up some sample code.

[Lzcat - Tracker Supp]

Reference present in both files, orginal file contain referenced object, merged - no (but reference remains there, and this is why it cannot be processed using xcpro40).

[jeffp]

If the original file contains the referenced object, then is there anything that can be done so that we can merge more PDF pages from other PDFs into the original file. Again, the original file is something the client already has on the machine.

Why does using the ViewerAX work to open and save both files, but it crashes on the merged file using the PCXp calls?

Is there a way for me to analyze and correct the original before trying to append more pages to it? What can be done here?

[jeffp]

I've been playing with this a bit more. It appears the corruption issue happens the second time you try to do something with the document. For example, if I open Document1.pdf and then append a page or two from another clean PDF document, I can then save the new document just fine using the DLL calls. However, if I then append more pages to this new document, then I get the corruption issue when saving.

Is there a way to handle the bad object in the DLL calls? This original PDF I sent you was created using the Amyuni Technologies PDF driver. The company has some pretty big clients including Intuit which makes alot of the accounting software packages. Since we sell to alot of accounting offices, we're afraid this issue may come up again and again since it's likely that these office have a lot of PDFs that were created with this bad driver. I understand that Amyuni is at fault here, but is there a way to handle this bad object in your DLL calls so that the file can be successfully appended to and saved.

Also, as I mentioned before, you appear to handle this bad object just fine in the ViewerAX when saving. Is it possible to do the same in the DLL calls.

Thanks.

[Lzcat - Tracker Supp]

Can you provide PXCp_... function call sequence to reproduce corruption? Looks like there is problem with specific files(s) and call sequence. File for testing I already have
And will se what can be done to handle already corrupted files (Viewer has completely different and more advanced code to handle pdf files, and it is impossible to migrante xcpro to this code until next version of library).

[jeffp]

Attached is a nice clean self-contained Delphi project that should illustrate how to produce the corrupted file. The main code is in Unit1.pas.

Please confirm that the attachment came through ok.

[Paul - Tracker Supp]

HI jeffp,

I heard from Lzcat that the team is working on a fix for this and are trying to get it into 2.5. Of course 2.5 is still "almost ready" and we don't want to add any new commitments that may delay it even further. We'll have to wait and see what the team can do. What ever the result, know that they are doing all they can and then some.

regards

[jeffp]

Knowing that a fix is coming is my main concern. To get it in 2.5 would be great, but I understand if it has to follow. Thanks for the update.

[Paul - Tracker Supp]

Thanks Jeff,

your patience and support are appreciated.

regards

[Paul - Tracker Supp]

Hi jeffp,

2.5 beta is out. Do let us know how that gos for you.

[jeffp]

I'm out all week, but will pick it up on Monday and let you know.

[Lzcat - Tracker Supp]

Current v2.5 beta (build 188) does not include required fix, it will be avail with next build (189).

[jeffp]

Any idea when build 189 will be out?

[John - Tracker Supp]

Unless other factors intervene, 7-10 days Jeff.

[jeffp]

Appears to be fixed in build 189. Thanks much.

[Tracker Supp-Stefan]

[jeffp]

It appears that this corruption issue has returned for my client. Attached is a self contained project with two files (Document1.pdf and Document2.pdf). Document1.pdf gets corrupted when I try to append Document2.pdf into it.

Is this a similar issue as before? Can it be fixed as well.

I know this is probably an issue the how Amyuni created the PDF, but my client notes that the same appending routine does work in Adobe without getting a corrupted file. And I just tested it in the ViewerAX and it does work there as well.

Also, can I ask you to remove the attached zip file from this post once you have downloaded the file. Thanks.

[Lzcat - Tracker Supp]

Got files and problem is reproduced.
Will fix in next build.

[jeffp]

Was this something similiar to the reason the last file I sent was corrupted. Do you think this next fix will take care of any other bad files created by that Amyuni Print Driver? I'd hate for my client to come back yet again with another bad file that may be a bit different still.

I'd like to continue using the DLLs to append files, etc., in non-visual contexts. However, I could create a non-visual instance of the ViewerAX and do my appending, etc., from there since it seems to handle bad files better than the DLLs. What do you suggest here? Do I understand correctly that in next major version both the DLLs and ViewerAX will be using the same underlying code?

Thanks again.

[Lzcat - Tracker Supp]

Issue was because one of files was broken and this was not correctly handled during save. Now it is fixed, so there should be no more issues with such files. However xcpro has issues with most broken files, which AX can handle. But using xcprto you have much more control during merging and additional functionality, which is not avail in Viewer AX. So this will be not easy decision - which way to prefer.
Yes, new major update for Viewer / DLLs will share same code to deal with pdf files.

[jeffp]

Just to confirm, the fix will be in build 191. Correct? I have 190 now.

[Tracker Supp-Stefan]

Yep,

"Now it is fixed" means that the solution is implemented already, and will be available to everyone with the next build which will be 191.

Cheers!
Stefan