string docuAddr = #"C:\Users\psimmon\source\repos\PDFTESTAPP\PDFTESTAPP\TempForms\forms-www.courts.state.co.us-Forms-PDF-JDF1117.pdf";
byte[] bytes = Encoding.Unicode.GetBytes(docuAddr);
PdfLoadedDocument loadedDocument = new PdfLoadedDocument(bytes, true);---blows here
PdfLoadedForm myForm = loadedDocument.Form;
PdfLoadedFormFieldCollection fields = myForm.Fields;
not sure what I have done wrong here, but the PDF file is opening, either in a browser or a fileexployer window. so it has to be me, guessed at most of this, all you very smart folks, I could use your gray matter. forgive my stupidity.
The reported exception “could not find valid signature (%PDF-)” may occurs due to the file is not a PDF document. We suspect it seems the other format files are saved with the “.pdf” extension. We could not open and repair this type of document on our end, we have already added the details in our documentation,
Please find some of the following corrupted error messages that cannot be repaired:
UG: https://help.syncfusion.com/file-formats/pdf/open-and-save-pdf-file-in-c-sharp-vb-net#possible-error-messages-of-invalid-pdf-documents-while-loading
If you want to find this type of corrupted document, Syncfusion PDF Library provides support to check and report whether the existing PDF document is corrupted or not with corruption details and structure-level syntax errors.
UG: https://help.syncfusion.com/file-formats/pdf/working-with-document#find-corrupted-pdf-document
Blog: https://www.syncfusion.com/blogs/post/how-to-find-corrupted-pdf-files-in-c-sharp.aspx
KB: https://www.syncfusion.com/kb/9686/how-to-identify-the-corrupted-pdf-document-using-c-and-vb-net
Related
I had some pdf multi signing workflow requirement. In this pdf will get signed multiple times without changes to the document say 2 or more people can sign same document.
I am trying to add the signatures in pdf twice but after signing pdf second time first signature get invalid. I have used PDFBox Java api for pdf signature creation.
PDF Creation steps:
Created pdf by adding empty signature fields names: suhasb#gmail.com and nikhil.courser#gmail.com using original hello.pdf out put file name hello_tag.pdf run program >TagPDFSignatureFields.java
First time signing by fetching signature field suhasb#gmail.com from hello_tag.pdf file, out file name is hello_signed.pdf run program >SignAndIdentifySignatureFields.java
Second time signing by fetching signature field nikhil.courser#gmail.com from hello_signed.pdf file, out file name is hello_singed2.pdf run program >Sign2.java
In 2nd step pdf gets signed properly but after 3rd step, 2nd step signed version gets invalided and 3rd step signature shows okay in acrobat reader.
Please find link Java source code and pdf sample for reference.
Google drive link pdf_multi_signs_pdfbox_java
Any help would be appreciated.
In short there are a number of issues in your code. The issue causing Adobe Reader to mark your first signature as invalid after adding a second signature actually already is in your preparation step TagPDFSignatureFields where you create an invalid duplicate pages tree entry. The other issues should also be fixed, even though Adobe Reader currently does not complain.
The issues in detail...
Duplicate Page Entry
In TagPDFSignatureFields your method addEmptySignField starts like this:
private void addEmptySignField(String[] args) throws Exception, IOException {
// Create a new document with an empty page.
try (PDDocument document = PDDocument.load(new File(args[0]));)
{
PDPage page = document.getPage(0);
document.addPage(page);
Here you retrieve the first page of document and immediately add that page to document again. This causes the pages root tree node in your file hello_tag.pdf to look like this:
2 0 obj
<<
/Type /Pages
/Count 2
/Kids [6 0 R 6 0 R]
>>
endobj
I.e. the pages tree contains the same page object twice which Adobe Reader does not accept but repairs under the hood. For the signed documents Adobe Reader warns about this in a vague way:
And in current versions (e.g. 2020.013.20066) Adobe Reader in the twice signed file even marks the first signature as broken. In earlier versions (e.g. 2019.012.20040) it did not do so. Probably this is an effect of the hardening of the validation code after the Shadow Attacks had been published.
As an aside: If you have a situation in which manipulating a signed document (form fill-ins, signing again, ...) breaks the old signatures, always also check whether the original document might already have issues. The check whether changes applied to a signed document are allowed, are quite sensitive to errors which otherwise are fixed under the hood and, therefore, not visible.
Invalid Partial Field Names
You use email addresses as field names, suhasd#gmail.com and nikhil.courser#gmail.com in case of your example:
signatureField.setPartialName("suhasd#gmail.com");
...
signatureField1.setPartialName("nikhil.courser#gmail.com");
(TagPDFSignatureFields method addEmptySignField)
These partial field names are invalid, partial field names must not contain period characters ('.').
PDFBox in future versions will try to prevent this, see PDFBOX-5028.
Setting the Default Resources And Default Appearances Upon Signing
During signing you set the default resources and default appearance of the AcroForm dictionary:
acroForm.setDefaultResources(resources);
...
acroForm.setDefaultAppearance(defaultAppearanceString);
(SignAndIdentifySignatureFields and Sign2 method addEmptySignField)
By itself this is not a bad thing but beware, if you do this to a previously signed file which already has such entries and you set them to different values than before, this can invalidate the former signature, see the issue answered here.
Setting PDF Version Without Need
You try to change the claimed PDF version of the document:
document.setVersion(1.0f);
(SignAndIdentifySignatureFields method addEmptySignField)
document.setVersion(2.0f);
(Sign2 method addEmptySignField)
The first instruction is ignored as the document itself already requires a version of at least 1.5, but the second instruction indeed sets the document PDF version to 2.0 which may cause issues with older viewers.
...
There quite likely are more issues. I merely first spotted these issues before I recognized that already fixing the only first one, the Duplicate Page Entry, sufficed to heal the first signature...
I'm reaching out to larger community of developers in seek of help to understand the real cause and possibly finding a fix. I have asked questions from Aspose, and they have also tracked the issue (PDFNET-42880) in their system. I think they are not going to investigate this anytime soon as it is very specific case. And now I am posting this here to ask more details about:
What is difference in Adobe 'save as' vs. Foxit Reader 'save as' vs. Windows Reader 'save as' feature?
Issues with Adobe product that are not so obvious to figure out. I don't even know what to ask :D
Link to their (Aspose) old forum: https://www.aspose.com/community/forums/thread/845549/removing-stamps-fails-after-saving-stamped-file-from-adobe-acrobat.aspx
Case:
Created PDF with forms using OpenOffice (version 3.4.0), stamped with Aspose PDF, opened with Adobe Reader DC (or Adobe Acrobat XI), filled, saved as new file. Now this new file is fine, but when I try to remove stamps using Aspose (and replace with new stamp later), this is where things get interesting.
Files that I've tested with: https://1drv.ms/f/s!Auvpijam7a73iDzOqc6wZPuY9l81
Stamp_Location.png
OoPdfFormExample_WithStamp.pdf
OoPdfFormExample_WithStamp_StampRemoved.pdf
OoPdfFormExample_WithStamp_SavedFromFoxit.pdf
OoPdfFormExample_WithStamp_SavedFromFoxit_StampRemoved.pdf
OoPdfFormExample_WithStamp_SavedFromWindowsReader.pdf
OoPdfFormExample_WithStamp_SavedFromWindowsReader_StampRemoved.pdf
OoPdfFormExample_WithStamp_SavedFromAdobeReader.pdf
OoPdfFormExample_WithStamp_SavedFromAcrobat_StampRemoved.pdf
C# code that is used to remove the stamp(s):
/// <summary>
/// Removes stamps from PDF file.
/// </summary>
/// <param name="pdfFile"></param>
private static void RemoveStamps( string pdfFile )
{
// Create PDF content editor.
Aspose.Pdf.Facades.PdfContentEditor contentEditor = new Aspose.Pdf.Facades.PdfContentEditor();
// Open the temp file.
contentEditor.BindPdf( pdfFile );
// Process all pages.
foreach ( Page page in contentEditor.Document.Pages )
{
// Get the stamp infos.
Aspose.Pdf.Facades.StampInfo[] stampInfos = contentEditor.GetStamps( page.Number );
//Process all stamp infos
foreach ( Aspose.Pdf.Facades.StampInfo stampInfo in stampInfos )
{
// Use try catch so we can output possible error w/out break point.
try
{
contentEditor.DeleteStampById( stampInfo.StampId );
}
catch ( Exception e )
{
Console.WriteLine( e );
}
}
}
// Save changes to the temp file.
contentEditor.Save( StampRemovedPdfFile );
}
Using Adobe: The process of removing stamp works fine, but trying to open the file will end up having an issue with the file.
"An error exists on this Page. Acrobat may not display the page correctly. Please contact the person who created the PDF document to correct the problem."
EDIT: After testing more, and just opening file to Aspose, and saving it without modifications, that didn't break the file, only once the stamp was removed with Aspose method it was broken.
Using Foxit: Only difference in the process is that opening the file to Foxit Reader and save form there. The stamp is removed and file is fine, works with any PDF reader.
Using Windows (10) Reader: Only difference in the process is that opening the file to Windows Reader and save from there. The stamp is removed and file is fine, works with any PDF reader.
Ok - The thing you are referring to is not a stamp annotation. It's an XObject that gets drawn into the page content. Why Aspose refers to it as a Stamp is... well... a mystery. When you remove the "stamp" (not a stamp) Aspose seems to be removing the XObject but not the instructions to draw it from the page Contents stream... that's why you're getting the error in Acrobat. The other applications are more permissive with bad PDF and my guess is when they write out the file, they are removing references to non-existent objects. You can make Acrobat attempt to fix problems like this by selecting Save As Optimized PDF. However, you are far better off removing the drawing instruction in addition to the XObject.
Because of the way you've created the file and added the "stamp", your page content stream is an array of streams. Remove the last item in the array, which is the instruction to draw the XObject, and you file will work without errors in all the viewers. Note: It won't always be the case that the last item in the content array will be your stamp. It's just that your stamp is the last thing to get drawn so it goes at the end.
If your intention is to "replace" the "stamp", you'll want to do so by removing the XObject as you are doing now, then remove the instruction, then add the new "stamp".
I am using using the Aspose.Email to get attachments out of an Outlook email like this:
var mailMessage = Aspose.Email.Mail.MailMessage.Load(stream);
var attachments = Aspose.Email.Outlook.MapiMessage.FromMailMessage(mailMessage).Attachments;
var pdfAttachment = attachments.ToList()[attachmentIndexDesired];
Then, I am loading the attachment into DataLogics like this:
var pdfStream = new MemoryStream(pdfAttachment.BinaryData);
var pdfDocument = new Datalogics.PDFL.Document(pdfStream);
Here I get the following exception:
PDF Library Error: File does not begin with '%PDF-'. Error number: 537001985
I cannot find anything on this error anywhere.
Note that the initial stream object above is a *.msg Outlook file and originates from a sharepoint SPFile. Also note that if the stream object SPFile is itself a PDF file (as opposed to an attachment to a *.msg file) I can load it into DataLogics just fine.
I know the error is being thrown by the DataLogics library, but is there something about how I am getting the attachment that could be changed/improved that would prevent this error from occurring?
Any ideas?
So just a few minutes ago I was trying to grab the BinaryData from the attachment and convert it to a string that I could read so I could visually inspect its contents. So I did this.
(new StreamReader(new MemoryStream(curAttachment.BinaryData))).ReadToEnd()
When I did that, it printed this error:
"Evaluation copy of Aspose.Email limits to extract only 3 attachments in the messages. Please contact sales#aspose.com to purchase a valid license."
Kind of strange as I am using my production license, but either way I went ahead and deleted some attachments from the parent *.msg file (it previously had 4) and tried to load it again. Then... poof... it started working.
Seems like it should throw an exception or something instead as that would have made this issue a lot easier to track down.
I'm trying to execute the following code:
PdfReader reader = new PdfReader("/path/to/file.pdf");
int pages = reader.getNumberOfPages();
It works on most files, but on one particular file, it crashes with error:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
at java.lang.StringBuffer.append(StringBuffer.java:320)
at com.itextpdf.text.pdf.PRTokeniser.readString(PRTokeniser.java:158)
at com.itextpdf.text.pdf.PRTokeniser.getStartxref(PRTokeniser.java:224)
at com.itextpdf.text.pdf.PRTokeniser.getStartxref(PRTokeniser.java:229)
...goes on for a while
at com.itextpdf.text.pdf.PRTokeniser.getStartxref(PRTokeniser.java:229)
I know that it's something wrong with the input file. I'm just wondering if there's a way of knowing before attempting to make the method call, that the file is going to cause a problem.
It turns out it was a bug with the version of itext I am using (5.0.1). I logged a query with the developers, and a fix was put in - that I tested - and which hopefully will find it's way into the next version (5.0.2)
I am trying to use Aspose to set the values of fields in a pdf. This pdf works fine in ITextSharp. That is the main frustration I am experiencing.
Here's my code
string outputPdf = String.Format(#"C:\PDF\output\test{0:dd-MM-yyyy-HH-mm-ss}.pdf", DateTime.Now);
string inputPdf = #"C:\PDF\application.pdf";
Aspose.Pdf.Facades.Form form = new Aspose.Pdf.Facades.Form(inputPdf, outputPdf);
form.FillField("MY_FIELD", "Test Value");
form.FlattenAllFields();
form.Save();
the line Aspose.Pdf.Facades.Form form = new Aspose.Pdf.Facades.Form(inputPdf, outputPdf); is causing an error.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Here's the stacktrace
[NullReferenceException: Object reference not set to an instance of an object.]
Aspose.Pdf.EmbeddedFileCollection.( node, Hashtable hash) +57
Aspose.Pdf.EmbeddedFileCollection..ctor(Document document) +161
Aspose.Pdf.Document.() +58
Aspose.Pdf.Document.(Stream input, String password) +181
Aspose.Pdf.Facades.Form..ctor(String srcFileName, Stream destStream) +92
I posted on their forums and it appears Aspose.Pdf 6.0.0 has known bugs due to a project merge between Aspose.Pdf and Aspose.Pdf.Kit. I am unable to open a Document or access the form in 6.0.0, so I grabbed Aspose.Pdf.Kit 5.6.0 and I was able to make it work.
Aspose.Pdf.Kit.Form form = new Aspose.Pdf.Kit.Form(inputPdf, outputPdf);
form.FillField("MyField", "Some Value");
Hope that helps anyone else who tries to use their software. After I did that, everything works fine for my demo version.
Have you tried Aspose.Pdf for .NET 6.2.0? Our team is also reviewing the upcoming version 6.3.0 which will be published in a week. Please try the latest one. If you still find any such issue please report it along with the input PDF file in Aspose.Pdf forum so our team could help you resolve this issue.
Disclosure: I work as developer evangelist at Aspose.