I want to sign all pages in ItextSharp and according to this thread I'm using
for (int p = 1; p <= writer.reader.getNumberOfPages(); p++) {
writer.addAnnotation(sigField, p);
}
It's worked well but when I open File with Adobe the rev no. is 1 for all signature I tried to increase rev. at the end of method FindSignatureNames() in AcroFields.cs but it doesnt reflect.
I dont know what i missed to make it worked?
I want to sign all pages in ItextSharp and according to this thread
First of all, a digital PDF signature always signs the whole PDF including in particular all pages. What the question you refer to is about, is adding visualizations (widget annotations) of a single digital signature to all document pages.
This is exactly what your code is doing, it's adding the signature widget annotation (which is merged into the signature field) to the annotation array of all the pages. (Strictly speaking this is done in an invalid way. But current validators ignore this error.)
But even though you now have signature visualizations on each page, there still is merely a single signature field holding a single digital signature. Thus, there also is only a single signed revision.
Your observation, therefore,
It's worked well but when I open File with Adobe the rev no. is 1 for all signature
is to be expected and correct.
If you want your signature visualizations to refer to different revisions, simply apply as many digital signatures to your document as it has pages, with a single visualization each, for the nth signature on page n.
Related
I'm trying check a checkbox on my PDF with iText7.
But instead of checking only one field, it's checking all fields
What I need:
What I get:
PDF when editing:
I think the exported value has something to do with it.
But I don't kown what to do.
My code:
private static void CreatePdf(string output)
{
using var _pdfDoc = new PdfDocument(new PdfReader("CheckTest.pdf"), new PdfWriter(output));
var form = PdfAcroForm.GetAcroForm(_pdfDoc, true);
var check = form.GetField("Check");
check.SetValue("01");
}
PDF: Link
Someone know how to check it properly?
Thanks!
First of all, the PDF essentially mis-uses PDF AcroForm check box fields as radio buttons instead of using genuine PDF AcroForm radio button fields.
The PDF specification does not clearly specify what a PDF viewer should do in such a case (it's mis-use after all) but the developers of the PDF form generator in question probably have experimented and determined that in the most widely used PDF viewer, Adobe Acrobat Reader, this mis-use works just as they want.
As this use is beyond specification, though, other PDF processors processing such PDFs may produce completely different results without doing anything wrong.
That being said, there is a way to fill the form using iText and achieve results similar to those generated by Adobe Reader.
The problem at hand is that iText by default for all form field types except actual AcroForm radio button fields generates new appearances in a way appropriate for the field type when setting the field value. In your document there are three check box field objects with the same name. Thus, they are considered a single check box with three widgets representing the same value, and so the appearances are generated as you observe.
But you can tell iText to not generate new appearances, using another SetValue overload accepting an additional boolean value, simply replace
check.SetValue("01");
by
check.SetValue("01", false);
Now iText makes do with the existing appearances, so only the field becomes checked that has an appearance for that "01" value.
Beware, only prevent iText from generating appearances in cases like this. In case of text fields, for example, not updating the appearances would cause the old appearances with the former field content to continue to be displayed even though the internal field value changed.
A did it like this:
Dim MyPDFFormCheckBoxField As Fields.PdfFormField = myform.GetField("myCheckBox")
MyPDFFormCheckBoxField.SetCheckType(PdfFormField.TYPE_CHECK)
MyPDFFormCheckBoxField.SetValue("", If(myCheckBox.IsChecked = True, True, False))
Notice that it is the second parameter of SetValue that is setting the checkbox True or False.
Simarly to this question I want to find the location of the last item in a PDF document and add content at that place, more specifically I would like to add an electronic signature at a position where one would normally put a regular handwritten signature on letters.
In the question above the user is making the PDF file but I am importing an existing PDF file that can have any structure as such. Therefore, as far as I can see, I can not use the same method as I do not know if the last object made was a paragraph or some other object.
I found the following function and property on the PdfWriter class that bode well but can not find any documentation that explains the output I get when I run the programme:
PdfWriter w = _document.GetWriter();
long currentPos = w.GetCurrentPos();
long pos = w.Position;
When I run this the output I get is something like the number 84178. What unit is that? Can I use this number to calculate how much vertical space there is left on the page and if it is too small then add a page and have the signature on the next page?
While extracting text from PDF file using iTextSharp using the below piece of code, I am getting this error: “Could not find image data or EI” while debugging the code found that this error is coming in certain pages but not all pages, then further investigated and also found that generally there are two types image in pdf xObject image and Inline Image and using the below piece of code Inline Image ca not be handled. There are few few comments in this issue in other similar post that suggested to use latest version(5.5.0) itextsharp, that also i did but no luck. My basic purpose is to extract the text in the page not image. How can I handle the Inline image or how can I extract only the text regardless what type of image the page having.
for (int page = 1; page <= pdfReader.NumberOfPages; page++)
{
PdfContentByte pdfData = pdfStamper.GetUnderContent(page);
LocTextExtractionStrategy its = new LocTextExtractionStrategy();
pdfData = pdfStamper.GetUnderContent(page);
string extractedTextInCurrentPage=PdfTextExtractor.GetTextFromPage(pdfReader, page, its);//In this line exception is throwing
}
Please share your PDF.
This is why:
Your PDF contains an inline image. Inline images are problematic in ISO-32000-1, but I personally saw to it that the problem will be solved in ISO-32000-2 (for PDF 2.0, to be expected in 2017).
In ISO-32000-1, an inline images starts with the BI operator, followed by some parameters. The length of the image bytes isn't one of those parameters. The actual image bytes are enclosed by an ID and an EI operator.
Software parsing PDF syntax needs to search for these operators and usually does a good job at it: find BI, then take the bytes between ID and EI. However: what to do when you encounter an image of which EI is part of the image bytes?
This hardly ever happens, but it was reported to us as a problem and we solved this in recent iText versions by converting the bytes between ID and EI to an image. If that fails, iText continues searching for the next EI. If iText doesn't find that EI parameter, you get the exception you mention.
This is a cumbersome process and, being a member of the ISO committee that writes the PDF standards, I introduced a new inline image parameter into the spec: the parameter /L will informs parsers exactly how many bytes are to be expected between the ID and EI operators. At the same time, I saw to it that the recommendation of keeping inline images smaller than 4 KB became normative: in PDF 2.0, it will be illegal to have inline images with more than 4096 bytes. Of course: this doesn't help you. PDF 2.0 doesn't exist yet. My work in the ISO committee only helps to solve the problem on the long term.
On the short term, we've written a work-around that solves the problem for the PDFs that were reported to us, but apparently, you've found a PDF that escapes the workaround. If you want us to solve the problem, you'll have to share the PDF.
I'm trying to get some information out of a PDF file. I've tried using PdfSharp, and it has properties for the information I need, but it cannot open iref streams, so i've had to abandon it.
Instead i'm trying iTextSharp. so far i've managed to get some basic information out, like the title, aurhor and subject, from the Info array.
However, i'm now after a bit more information, but cannot find where it is exposed (if it is exposed) in iTextSharp.... The information I am after is highlighted in the image below:
I cannot figure out where this information is stored. Any and all help will be much appreciated.
For documents encrypted using standard password encryption you can retrieve the permissions after opening the file in a PdfReader pdfReader using
getPermissions() in case of iText/Java
int permissions = pdfReader.getPermissions()
Permissions in case of iTextSharp/.Net
int permissions = pdfReader.Permissions
The int value returned is the P value of the encryption dictionary which contains
A set of flags specifying which operations shall be permitted when the document is opened with user access (see Table 22).
[...]
The value of the P entry shall be interpreted as an unsigned 32-bit quantity containing a set of flags specifying which access permissions shall be granted when the document is opened with user access. Table 22 shows the meanings of these flags. Bit positions within the flag word shall be numbered from 1 (low-order) to 32 (high order). A 1 bit in any position shall enable the corresponding access permission.
[...]
Bit position Meaning
3 (Security handlers of revision 2) Print the document. (Security handlers of revision 3 or greater) Print the document (possibly not at the highest quality level, depending on whether bit 12 is also set).
4 Modify the contents of the document by operations other than those controlled by bits 6, 9, and 11.
5 (Security handlers of revision 2) Copy or otherwise extract text and graphics from the document, including extracting text and graphics (in support of accessibility to users with disabilities or for other purposes). (Security handlers of revision 3 or greater) Copy or otherwise extract text and graphics from the document by operations other than that controlled by bit 10.
6 Add or modify text annotations, fill in interactive form fields, and, if bit 4 is also set, create or modify interactive form fields (including signature fields).
9 (Security handlers of revision 3 or greater) Fill in existing interactive form fields (including signature fields), even if bit 6 is clear.
10 (Security handlers of revision 3 or greater) Extract text and graphics (in support of accessibility to users with disabilities or for other purposes).
11 (Security handlers of revision 3 or greater) Assemble the document (insert, rotate, or delete pages and create bookmarks or thumbnail images), even if bit 4 is clear.
12 (Security handlers of revision 3 or greater) Print the document to a representation from which a faithful digital copy of the PDF content could be generated. When this bit is clear (and bit 3 is set), printing is limited to a low-level representation of the appearance, possibly of degraded quality.
(Section 7.6.3.2 "Standard Encryption Dictionary" in the PDF specification ISO 32000-1)
You can use the PdfWriter.ALLOW_* constants in this context.
Concerning the dialog screenshot you made, though, be aware that the operations effectively allowed do not only depend on the PDF document but also on the PDF viewer! Otherwise you might be caught in the same trap as the OP of this question.
Thanks to mkl for your answer, it was part of the story, but here is the answer which you helped me find:
using (var pdf = new PdfReader(File))
{
Console.WriteLine(PdfEncryptor.IsModifyAnnotationsAllowed(pdf.Permissions));
}
The PdfEncryptor is what was missing, it converts the P value into a simple bool for yes or no. Other methods on there are:
IsAssemblyAllowed
IsCopyAllowed
IsDegradedPrintingAllowed
IsFillInAllowed
IsModifyAnnotationsAllowed
IsModifyContentsAllowed
IsPrintingAllowed
IsScreenReadersAllowed
As for the security method part, this is what i went with:
using (var pdf = new PdfReader(File))
{
Console.WriteLine(!pdf.IsOpenedWithFullPermissions == Expected);
}
I'm using ITextSharp 5.1.1 to digitally sign a PDF with multiple signature fields. I have 4 signature fields: 3 approval signatures (users sign the document) and the 4th signature is the certification signature, which our system signs to indicate that the document is verified as correct and that no further modification can be made to the PDF.
If I add multiple approval signatures, a new revision is created for each signature and all the signatures are valid.
As soon as I then add the certification signature at the end of the signing process, it invalidates all the previous approval signatures.
Am I missing something here? Is there a different way to achieve the same effect as the certification signature without invalidating the approval signatures?
TIA
Your approach is to first add a number of approval signatures to a document and afterwards a certification signature.
This approach cannot work because it violates the PDF specification. As the question is from 2011, I quote from part 1, i.e. ISO 32000-1 published 2008, and not part 2, i.e. ISO 32000-2 published 2017; in essence both specifications agree on this issue, though.
A PDF document may contain the following standard types of signatures:
One or more approval signatures. [...]
At most one certification signature (PDF 1.5). [...] The signature dictionary shall contain a signature reference dictionary (see Table 253) that has a DocMDP transform method. See 12.8.2.2, “DocMDP” for information on how these signatures shall be created and validated.
At most two usage rights signatures. [...]
(ISO 32000-1 section 12.8 "Digital Signatures", subsection 12.8.1 "General")
The DocMDP transform method shall be used to detect modifications relative to a signature field that is signed by the author of a document (the person applying the first signature). A document can contain only one signature field that contains a DocMDP transform method; it shall be the first signed field in the document.
(ISO 32000-1 section 12.8.2.2 "DocMDP", subsection 12.8.2.2.1 "General")
Thus, it is no wonder that as soon as you then add the certification signature at the end of the signing process, it invalidates all the previous approval signatures, because adding a certification signature to an already signed document by definition makes the signature structure of the document invalid. (Ok, Adobe's error message in this case could more clearly point out the issue...)
You wonder is there a different way to achieve the same effect as the certification signature without invalidating the approval signatures?
According to raw ISO 32000-1 your options are limited. By means of a signature field lock dictionary (see section 12.7.4.5 "Signature Fields") and a FieldMDP transformation in your final signature you can lock existing form fields:
On behalf of a document author creating a document containing both form fields and signatures the following shall be supported by conforming writers:
The author specifies that form fields shall be filled in without invalidating the approval or certification signature. The P entry of the DocMDP transform parameters dictionary shall be set to either 2 or 3 (see Table 254).
The author can also specify that after a specific recipient has signed the document, any modifications to specific form fields shall invalidate that recipient’s signature. There shall be a separate signature field for each designated recipient, each having an associated signature field lock dictionary (see Table 233) specifying the form fields that shall be locked for that user.
When the recipient signs the field, the signature, signature reference, and transform parameters dictionaries shall be created. The Action and Fields entries in the transform parameters dictionary shall be copied from the corresponding fields in the signature field lock dictionary.
(ISO 32000-1 section 12.8.2.4 "FieldMDP")
But if your original certification signature allowed annotation changes or there is no certification signature to start with, you cannot dis-allow such annotation changes.
If, on the other hand, your PDF processors and viewers support ISO 32000-1 plus the Adobe Supplement with ExtensionLevel 3, an additional entry in the signature field lock dictionary is specified:
P number (Optional; ExtensionLevel 3) The access permissions granted for this document. Valid values follow:
1, no changes to the document are permitted; any change to the document invalidates the signature.
2, permitted changes are filling in forms, instantiating page templates, and signing; other changes invalidate the signature.
3, permitted changes are the same as for 2, as well as annotation creation, deletion, and modification; other changes invalidate the signature.
Default value: none; absence of this key results in no effect on signature validation rules.
If MDP permission is already in effect from an earlier incremental save section or the original part of the document, the number shall specify permissions less than or equal to the permissions already in effect based on signatures earlier in the document. That is, permissions can be denied but not added. If the number specifies greater permissions than an MDP value already in effect, the new number is ignored.
If the document does not have an author signature, the initial permissions in effect are those based on the number 3.
The new permission applies to any incremental changes to the document following the signature of which this key is part.
(Adobe Supplement to ISO 32000-1 ExtensionLevel 3 part I "Extensions to the PDF specification", section 8.6.3 "Field Types", subsection "Signature Fields")
This addition has been adopted by ISO 32000-2.
If you want to make use of these mechanisms using iText since version 5.3.0, have a look at the Digital Signatures for PDF Documents whitepaper by Bruno Lowagie, iText. Section 2.5.5 "Locking fields and documents after signing" illustrates how to use those mechanisms with iText.