Why does this PDF show a signature in Foxit Reader but not Adobe Reader?
Here is the code from the Syncfusion PDF library used to generate it (see also documentation about signing an existing document):
var signature = new PdfSignature(loadedDocument, page, certificate, "Signature");
signature.Certificate = certificate;
signature.Bounds = new RectangleF(100, 100, 200, 200);
signature.Appearence.Normal.Graphics.DrawRectangle(PdfBrushes.Red, new RectangleF(0, 0, 200, 200));
When I use this on an existing PDF a signature is identified in Foxit Reader:
But not in Adobe Reader:
Here is the resulting PDF for analysis.
Why is this? Is there anything I can do to fix this so that Adobe will recognize it?
EDIT
Here is the original PDF before anything is done to it.
SOLUTION
I used the Nuget package from Syncfusion's own Nuget server, which is up to date (the ones on Nuget.org are not).
This answer concentrates on the first question:
Why is this?
As I have no experience whatsoever with the Syncfusion PDF library, though, I cannot tell what you specifically
can do to fix this so that Adobe will recognize it.
The PDF object structure
Broken field hierarchy
In the above screenshot one can see that in the AcroForm dictionary the Fields array has a single entry, field object 12 0.
Field object 12 0 only has a local name (value of T: "Signature") and a Kids array of descendant field objects containing a single descendant entry, field object 9 0.
Field object 9 0 also has a local name (also "Signature"; thus its fully qualified field name is Signature.Signature) and numerous other entries, most of them ok for a signature field and widget. It does not have a Parent entry.
According to the PDF specification a Parent entry in a field is
Required if this field is the child of another in the field hierarchy
(ISO 32000-1, Table 220 – Entries common to all field dictionaries)
The single page of the document (object 5 0) in its Annots references references the field object 9 0 in its role as a widget annotation.
Thus, coming from the AcroForm dictionary Fields array, the field object 9 0 is a descendant of another field and has the fully qualified name Signature.Signature.
But coming from the page via the Annots, the field object 9 0 does not have a parent and, therefore, appears as a root field with the fully qualified name Signature.
Thus, the identity of the signature field is unclear.
Redraw requested
Furthermore one sees in the object structure above that in the AcroForm dictionary the NeedAppearances flag is set to true.
This asks the PDF viewer
to construct appearance streams and appearance dictionaries for all widget annotations in the document.
(ISO 32000-1, Table 218 – Entries in the interactive form dictionary)
In the course of this Adobe Reader is known to remove annotations with broken structures. As explained above, the field structure of your signature field is broken.
Further peculiarities
Some of the entries of the signature field are somewhat peculiar:
BS and MK are data for generating a standard appearance for the widget. Usually, though, visible signature bring their custom signature appearances along, and so does yours. So what are these values for?
DA, the default appearance string that shall be used in formatting the text of variable text annotations, e.g. FreeText annotations or text fields, but why a DA in a signature field?
What to do
Obviously the errors and peculiarities should be cleaned up. As mentioned above, I have no experience whatsoever with the Syncfusion PDF library, so I cannot tell you how to do that exactly.
One hint, though: I doubt that the Syncfusion PDF library regularly creates such nonsense when creating signatures, so there quite likely is something special about the document you want to sign, please check it. E.g. if the original document already contained a form field named "Signature", the broken structure might be a result of some Syncfusion code trying to merge a new signature field with the old field.
We have already faced this kind of issue in our side with the older version. Now we have fixed this issue in our latest version.
Click here to download the latest version
Here is the sample to sign an existing PDF
We have checked with the data file with sample. The problem is fixed in the latest version. Nuget Package you are using is considered to be the older version. Find the below link to download the latest nuget package.
Click here to download
Try the sample with the latest version.
Related
The extended features of a pdf file, like filling out the fields or a dropdown field do not work, after adding a new page to a pdf document.
The file is opened in append mode to preserve Reader enabling:
PdfDocument pdfDoc =
new PdfDocument(pdfReader, new PdfWriter(outputStream), new StampingProperties().useAppendMode());
Filling out the form fields does not break the signature, but after adding a new page to attach images to the file, the extended features are no longer available.
A new page is added with:
PdfPage page = pdfDoc.getPage(1);
pdfDoc.addNewPage(pdfDoc.getNumberOfPages() + 1, new PageSize(page.getPageSize()));
Is it possible to add pages and attach images to the file without breaking the signature?
The option removing the usage right is not applicable, since we want to be able to fill out and save the form.
Adobe "Reader Enabling" works by adding a specific kind of signature, a usage rights signature, to the document. Such a usage rights signature has a set of UR transform parameters that define the additional rights granted to a Adobe Acrobat Reader user when opening the document in question, see ISO 32000-2, Table 258 — Entries in the UR transform parameters dictionary.
Adobe Reader apparently not only offers its users only the additional rights from those parameters, it also checks whether some other software applied other manipulations and rejects the document if it detects such changes. Or at least it checks whether any applied changes would have been allowed for PDFs with arbitrary approval signatures, see this answer.
This actually is very understandable. Otherwise one would only need to grab a single Reader Enabled PDF to create arbitrary Reader Enabled PDFs by simply adding an incremental update removing all existing content and adding the desired content. This of course is not what Adobe wants...
I'm using pdftk to fill in the form with the generated fdf.
In the PDF form, the form field is configured as a number field with 2 decimal point, and the negative value will be showing with parentheses, for example, -4444 will become (4444.00)
Using any PDF viewers and changing the value on form did make the form display the value correctly with the behaviour explained above (negative value will become value with parentheses)
Tested also with the FDF (by importing to the form), the negative value will be displayed correctly as well.
But when using the pdftk fill-form action, the negative value remains as it is without changing the display, which is still showing -4444 and not (4444.00)
Is anyone experienced this before / has a solution for this?
Update #1
I've also tested Apache PDFBox, it has the same issue :(
And now I'm trying to achieve this by using the PDF's javascript, any clue that this way will works?
Update #2
came across this thread How to refresh Formatting on Non-Calculated field and refresh Calculated fields in Fillable PDF form and so gave it a try with iText as well. However still unable to make it works
Finally, i've found some ways to get the formatting works in the PDF form fields.
Approach #1
Requirements
pdftk
PDF form with javascript
In the PDF, create a "Document Javascript" (see how) and re-assign the form's value to make it dirty as mentioned by Denis in the thread of Update #2. The script could be as simple as below:
var text1 = this.getField('text1');
text1.value = text1.value;
Downside
Javascript will only be triggered when you open the PDF, and if you would like to set the PDF with some ownerPassword to prevent user edit the file, the javascript will just failed because of read-only form fields. Otherwise, imagine you have 100 form fields in the PDF, re-assign each of them is a nightmare.
Approach #2
iText
PDF form
I personally will prefer this approach. The powerful iText already has the API to set the form field and at the same time formatting the field display (see how). The generated PDF is ready to print as well with the correct format.
Downside
Either using the iText API to find out the existing format of the form field, or you will hard code the format in your codes. Require more efforts than using the pdftk.
I'm using a simpler version of ChinKang's #1.
In Tools -> Document Javascripts:
this.calculateNow();
One thing to check is in Tools -> Set field calculation order that any calculations are ordered appropriately.
I then use https://github.com/ccnmtl/fdfgen and pdftk to fill the forms in.
The only gotcha is that you cannot flatten the PDF
I want to fill out a dual AcroForm/XFA PDF form automatically. I included an XFA dataset packet and all values showed up in Adobe Reader. I set the V= key in AcroForms entries to the new value and all values showed up alternative PDF readers.
However, when I open the PDF with XFA and AcroForm V= entries in Adobe Reader, only the value of the text field that is currently selected is visible:
I cannot find any mention in the PDF specification of a special flag to set when AcroForms and XFA are present. I hypothesized that the order of the XFA and Field keys may be important, but that's not it either.
How can I change my PDF file so that the values are visible in Adobe Reader on startup, and in PDF readers which only support AcroForms and not XFA?
There are 2 questions to be answered:
Why is Adobe Reader only displaying the field value when the field is selected?
How to determine if the AcroForm or the XFA is used?
1. Displayed field values
In some cases Adobe Reader/Acrobat will display a form field differently depending on whether it's selected or not. This is typical for a field that has a defined appearance that is different from how Reader/Acrobat would render the field based on its value (and possibly some appearance settings).
When the field is not selected, the defined appearance will be shown. When the field is selected, a preview of how Reader/Acrobat would render it is shown.
Some background:
A form field consists of a logical part (field name, field value, ...), called the field dictionary, and a visualization part, called the widget annotation. The widget annotation can optionally contain an AP entry, containing the appearance streams that define its visualization. Cf. PDF Specification, 1.7, Table 8.15:
AP - dictionary - An appearance dictionary specifying how the annotation is presented visually on the page.
In the sample PDF there are no AP entries, i.e. blank visualizations. This is what's displayed for all the fields. When selecting a field, you see Reader/Acrobat's preview, based on the field value.
You can verify this by changing a field value manually with Reader/Acrobat. In that case, a new appearance will be generated and saved. That field will now be displayed in the same way, regardless of it being selected or not.
Two options to prevent these "blank" fields in Reader/Acrobat:
Generate appearance streams for all form fields. I have done this for one field (by simply re-setting its value using iText, which automatically generates an appearance stream).
The result:
Internal PDF structure:
Set the NeedAppearances entry in the AcroForm dictionary to true. Cf. PDF Specification, 1.7, Table 8.67:
NeedAppearances - boolean - A flag specifying whether to construct appearance streams and appearance dictionaries for all widget annotations in the document
This will trigger the viewer to generate all the appearances:
2. AcroForm or XFA?
In general, a XFA capable viewer will display the XFA form. A viewer without XFA support will use the AcroForm. You can verify this by setting different values for corresponding AcroForm and XFA fields. This is the result, Chrome's built-in PDF viewer on the left (no XFA support), Acrobat on the right:
Knowing that Reader/Acrobat is using the XFA form, why did we still see the blank fields (cf question 1)?
It seems that, when the values of an XFA field and its corresponding AcroForm field are the same, Reader/Acrobat also uses some information from the AcroForm, a.o. its appearance information. When the XFA value is different from the AcroForm value, the AcroForm field seems to be ignored completely.
TL;DR Set NeedAppearances to true to solve blank fields. XFA-incapable viewers will fall back to AcroForm automatically.
(My tests are based on Adobe Acrobat X.)
I'm writing a PDF generation library and wanted to add the the ability to use other PDFs as templates. The specification notes a TemplateInstantiatedproperty on pages with the alias of the template object should be all that is needed.
Here is a gist of the pdf content:
https://gist.github.com/tyre/89c12f8203181f078001
The template itself is stored in object 16 and the page in object 19.
qpdf --check reports the PDF as invalid:
WARNING: tmp/alpaca.pdf: file is damaged
WARNING: tmp/alpaca.pdf (file position 32089): xref not found
WARNING: tmp/alpaca.pdf: Attempting to reconstruct cross-reference table
checking tmp/alpaca.pdf
PDF Version: 1.7
File is not encrypted
File is not linearized
I'm afraid your PDF document is completely and utterly broken and that you have misunderstood a number of key concepts. You cannot simply incorporate a complete PDF file into another PDF file in the way you have done and expect that to work.
The template system you are referring to is intended to include "hidden" pages - not referenced in the pages tree in the PDF file - in the context of an interactive form document (or interactive document in general). That doesn't sound like what you are intending to do. And these pages need to be valid PDF pages. You can in other words not just include the original PDF document verbatim and expect the PDF reader to sort things out; you need to insert a syntactically correct PDF page object.
What you want to do is take the content of a document and apply that as a background to a document. This most commonly is done using XObjects. Pseudo-code for this could be:
Open the original PDF document
Open the "template" document
Read the template document and copy all elements from the template page into a newly created XObject in the original PDF document.
Modify the page contents of the pages in the original PDF document to paint the new XObject at the beginning of the page description of the existing pages.
It's important to note that again, you're not supposed to simply insert the template document into the stream for the newly created XObject. You will have to create a valid XObject that contains a properly formed resources dictionary referencing all resources needed by your XObject, and that contains the content stream from your template document.
As already indicated in comments, the PDF presented by the OP is structurally defect, the cross reference table position and entries are wrong. Furthermore the transition from one PDF revision to a next update looks questionable. Essentially, therefore, the OP will have to provide a sample PDF which is at least syntactically correct.
That been said, though, the OP indicated he was
writing a PDF generation library and wanted to add the the ability to use other PDFs as templates. The specification notes a TemplateInstantiatedproperty on pages with the alias of the template object should be all that is needed.
The Named Pages mechanism is not meant for something like that. Its main current use (if it is used at all) is in the context of spawning page templates by Acroform actions.
For using pages from other PDFs, one can simply copy them (and the referenced other objects) from the source PDF if they are to be used as separate pages as is; and if multiple templates are to be put onto a single target page, one can wrap the copied sources into form xobjects and include them in the target page.
I am using FOP to generate the PDF from XSL:FO and iText to apply the digital signature and signed date field in the PDF.
Problem is i am using co ordinates to apply the signature and date in the generated PDF.
The PDF are large, dynamic and changing always based on content. therefore the signature and date fields were not positioned Properly by the co-ordinates specified.
I googled to find solution for a long days. But i didnt get any solutions.
Can u please any one suggest me to create the PDF form fields in the PDF using FOP?
Then i can apply signature and date fields by using iText.
Please tell me any other technology to try to solve this problem?
The problem is that FOP doesn't create signature fields whereas iText needs a page number and coordinates (either defined by you or by a signature field).
Where do you want the signature to be placed?
Is it always on the first page? Always on the last page?
Can you put some unique text at the location where you want the document to be signed?
I'm asking this because you could put words like SIGN HERE on the last page, and then use TextRenderInfo to retrieve the coordinates of those words. See http://itextpdf.com/examples/iia.php?id=275 in combination with http://itextpdf.com/examples/iia.php?id=282
The TextRenderInfo class has methods such as getBaseLine(), getDescentLine(),... who give you LineSegment object which reveal the coordinates of each snippet of text in your PDF.
There are plenty of caveats: FOP could cut the words SIGN HERE in different snippets, such as "SIG", "N", "HE", "RE" which would make it difficult to recognize the unique string, but it's worth investigating.