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.)
Related
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.
I have a PDF with forms defined in it.
One field in the form is a multi line text field.
The value in the text field is populated by a java program using Apache PDFBox.
The issue is when the value is of around 5 to 6 lines, the text box displays the text automatically. But if it is more than 6 lines, the text box does not display the value. I had to specifically click on the text field to display the text. If I click outside the text box again, the text disappears.
The text field is read only with Multi Line and Scrolling options enabled.
Any ideas what is causing this weird issue?
I have Adobe Acrobat Pro 11, Adobe Acrobat XI and Adobe Reader to view the files. All have the same issue.
It sounds like a typical "appearance" problem. There's no form field appearance in the field widget dictionary so when you click in the field, the raw string data is shown but when you click out there is no appearance to display so you get a blank. You can test this out by toggling the multi-line setting in the field properties in Acrobat so it generates an appearance. If that fixes it, then you the problem is the one I describe.
You can use PDFBox to set the "needs appearances" flag in the file that will tell Adobe viewers to regenerate field appearances when the file is opened but that doesn't work for all PDF viewers. To make the field value visible in all PDF viewers, it's best to generate appearances when you populate the field values.
The Datalogics PDF Java Toolkit can automatically generate appearances based on field values. Full disclosure, I represent Datalogics.
all
I must fill this PDF form using iTextSharp.
I have no problems with the header fields, but I don't know how to fill the table in the bottom. I can fill its first row with PdfStamper.AcroFields.SetField(), but how can I add more rows, if it is at all possible?
Your form is a form based on AcroForm technology. This means that the form is static. Every field in the form corresponds with a widget annotation for which an absolute position is defined on the page. You can not add any data on coordinates that are not predefined, hence you can not "add more rows". What you are asking for is impossible.
Take a look under the hood of your PDF:
There's an array of /Fields and each field is defined by a dictionary that combines field entries and the entries of a single widget annotation. Each widget annotation has its fixed coordinates on the page.
It seems that you were looking for a dynamic form solution. In that case, you need a form based on the XML Forms Architecture (XFA). Your form is not an XFA form.
If you are in doubt about the difference between AcroForm and XFA technology, please download this free ebook: The Best iText Questions on StackOverflow. In this book you'll find the answer to several questions such as:
What is the difference between iText, JasperReports and Adobe LC?
Generate and design PDF with iTextSharp or similar
How can I flatten a XFA PDF Form using iTextSharp?
...
These and other answers will give you an idea of some alternative options.
Once after completion of digital signature for PDF using DocuSign, How to read value of the fields in PDF using field ID/Name (using PDF Box API)? I am not able get the field ids of Digitally Signed PDF.
The sample PDF showed that the fields in PDF are not PDF form fields after all, neither Acrofornm nor XFA, they merely are texts with some lines around them. (They may once have been PDF form fields which were flattened, or they may never have been PDF form fields to start with.)
Thus, your only option left is text extraction. PDFBox has a quite elaborate text extraction engine. Have a look at PDFTextStripper. You can try and use this class as is, looking in the extracted string for the field labels and extract the following text until the end-of-line; or if you have the time, you can try to make use of the internal PDF structure where the field contents are in a separate Xobject.
I am using GhostScript to render PDF files to PNG images. However, I have discovered that some PDF's have form fields that contain data (in this case todays date) that I would not like to be present in the output image. Is it possible to disable rendering of field values in GhostScript?
I believe that by default Ghostscript won't render PDF form fields, see:
http://ghostscript.com/doc/current/Use.htm#PDF_switches
-dShowAcroForm
Show annotations referred from the Interactive Form Dictionary (AcroForm dictionary).
By default, AcroForm is not enumerated because Adobe Acrobat doesn't do this. This
option may be useful for debugging or recovery of incorrect PDF files that don't
associate all annotations with the page objects.
You may want to set the switch -dShowAcroForm=false to be sure.
If you're referring to annotations (which are shown by default), you may wish to also set the switch -dShowAnnots=false.