Forms Data Format (FDF) is a specification for form data exported from forms in Adobe Portable Document Format. These data can be exported by a couple different means. One could perform an Export --> Form Data... command from the Adobe Acrobat menu bar. Alternately, if the form has a Submit button, pressing it sends an HTTP POST message to a specified script or object by means of the submitForm method of the Document object. The FDF file is in the body of this request. One could also generate an FDF file from scratch by assembling a text string, or using the FDF Toolkit provided by Adobe.
However the file gets generated, it will be similar to a PDF in its basic structure.
- First, the file has a one-line header identifying the file format and version. For example, %FDF-1.2 identifies the file as FDF version 1.2. That is all there is to the header.
- Next comes the body, which, as the name implies, consists primarily of the objects composing the files. Most often this section will consist of information about the form fields, their values, and any additional parameters for the fields. The body will also contain the root catalog for the file that references objects external to the current file that describe the file's contents. Two of the most common objects referenced in the root catalog are the filename and path of the PDF that created the FDF and the target object that will parse and use the FDF data. This target object can be another PDF, a perl or CGI script, or any other object to which can be sent an HTTP request.
- Next in the file structure comes the cross-reference table. This optional section further identifies objects within the file. (I'm not 100% sure what it is used for, but I will update this writeup when I find out.)
- Finally, there is a trailer section. As the name implies, it comes at the end of the file and identifies the location of the root catalog and the end of the file, %%EOF.
So what can one use this for? PDF Forms, when published on a web server can be a good tool for capturing user input when the need exists to have a PDF interface. One of the many strengths of PDF is that what is on the screen is the same as what gets printed. If one's users are accustomed to paper forms, migrating them to online transactions by means of a PDF form might flatten the learning curve. Also, the built in digital signature tool in Acrobat can be an inexpensive means of ensuring the form users are who they say they are. On the server, the signature key can be parsed out and validated before the data is accepted.
Furthermore, after the FDF is parsed and handled by the server, the server can generate a response FDF, merge it with a predefined PDF template form, and send that back as the server response. That can be handy if one wants to send the user a confirmation in the form of a business letter with company stationery, for instance, that the user can print at his or her leisure.
I am still learning this tool and discovering how it differs from regular HTML forms using server scripting. Also, I have yet to figure out how to make it work well, but that says more about my programming skills than about the tool. As I learn more, I will update this writeup.
Sources:
PDF Reference, Third Edition