Printing using FDF forms

June 28, 2000
by Doug Brown

It's said that necessity is the mother of invention. Thomas Edison also said that invention is 90% perspiration and 10% inspiration. Any developer knows both these statements to be true. One gets into a tough situation where a new approach is required, and then sweats it out until the new tactic is found.

Recently I found myself re-living this scenario. Not that it's a bad thing; it keeps my work interesting. This time, though, it dealt with one of the more dreaded aspects of Director programming: printing. In this particular instance an application form needed to print out with all the applicant information filled in dynamically from a database. Any time printing comes up in Director, it's a challenge, and this one didn't seem too out of the ordinary. But it suddenly became very complicated when it turned out the form had to be a faithful replica of the original print version. One look at the print version told me I was in trouble, as it was a rather elaborate layout. The thought of trying to reproduce it with PrintOMatic made my head spin; and MPrint was out of the question, as the solution needed to be cross-platform.

Determined to find a way to make it work, I went to the client's Web site to download a better copy of the form than the blurred fax I had received. What I found there sent me off in a whole new direction of thought. Somehow, they had the ability on their site for users to fill in a Web form and receive back a PDF file with their information in place. If it could be done using information gathered through a Director front end, it would be a perfect answer.

After some research at the Adobe Web site and buying the full version of Acrobat (my best-spent $200 this year), I determined that something similar, and even better, could be done from Director. Using Acrobat would allow for an exact reproduction of the application form by creating a PDF form file, and then generating FDF (Form Data Format) files on the fly from Director.

What's an FDF file? That's what I found out as I dug around a bit (and what wound up saving my sanity from the morass of POM commands). One of the features of an Acrobat PDF file is the ability to create dynamic forms. A user can open the form in Acrobat Reader, fill it out by typing information into the fields on the form, and then print it out. What can't be done in Reader, but is available in the full version of Acrobat, is saving a file containing just the data that is entered into the form.

This didn't seem too important at first, until I found that the FDF file could be opened in Acrobat Reader. The upshot is that opening an FDF results in the original PDF being opened with the saved form data appearing in place. If the file format of the FDF file could be deciphered, it would be a simple matter to take the user data entered into the Director application and then output it as an FDF file to be opened and printed by Acrobat.

It turns out the format definition is really simple. Not quite HTML, but a similar cousin. The form's field names and data are stored within a tag set. Characters between tags are irrelevant and don't appear anywhere within the displayed PDF file. This is important to know for readability of the data file more than anything else.

Acrobat currently provides seven input widgets: button, check box, combo box, list box, radio button, signature, and text. Scripting of a sort is also available within Acrobat for the creation of interactive forms that can calculate values based on inputs, as well as doing several other things. Being interested in integrating the ability to print into Director means we can ignore the interactive aspect of Acrobat. The reason for this is that all the interactivity is rolled into a projector or Shockwave application. This narrows the scope of needed widgets to check boxes, radio buttons, and text fields.

The definitions for these widgets within the FDF file are easy to pull apart using a simple example. Say we create a PDF form file with a text field named textField1, a radio button group named RadioButtons with outputs of "Choice1", "Choice2", and "Choice3", and two check boxes named CheckBox1 and CheckBox2, each of which has an output of "True". Here is the form data exported by the sample application, cleaned up for readability by placing each element on its own line:

%FDF-1.2%âãÏÓ
1 0 obj<< /FDF << /Fields 
[ 
<< /V /Off /T (CheckBox1)>>
<< /V /Yes /T (CheckBox2)>>
<< /V /choice2 /T (RadioButtons)>> << /V (Doug Brown)/T (textField1)>> 
] /F (test FDF entry.pdf)>> >> 
endobjtrailer<</Root 1 0 R >>%%EOF

A sample movie is available for download in Mac or PC format

Everything related to the field names and values is between the "[" and "]" in the middle of the file. The stuff outside that: who knows? Some of it is rather cryptic, and can be re-used from file to file, so I haven't worried about it much. The name of the PDF file related to the FDF data appears with the "/F" delimiter. This information is critical for printing the completed form. The FDF and PDF need to be in the same directory by default so the one can find the other. If they will not be in the same folder, the file name in this parameter can be altered to reflect the complete path to the PDF file. When you double-click the FDF file saved by the sample application, it will open the sample PDF file with the data filled in if both files are in the same folder.

The structure of the name-value pairs should be obvious. Each set is encapsulated with "<< >>" tags. The name of the form field appears as "/T (field name)". The value for a checkbox or radio button is stored as "/V /value". The values for text fields are stored as a string in the form "/V (text string)". Note that only one radio button value is output for the entire group. Check boxes are shown as either "Off" or whatever the selected output value was set to when the PDF form was created. In this case it was left to the default of "Yes" (why is that the default, given that the uncheck value is always "Off"?), but it could just as easily have been "Betty" or "Wilma".

Two other points definitely worth noting are that the data elements do not need to appear in the same order as in the PDF form file, and that a given form field entry need not be present in the FDF file at all. If a tag is missing from the file, the form field will appear with its default value set. This works very well for creating an FDF with user data on the fly. If some portion of the application isn't relevant to the user, the data doesn't need to be written into the file. And should the application form be changed in the future, the data files will all still be relevant as long as the field names in the PDF remain the same.

The usefulness in this goes beyond filling in an application, of course. Any template form that you might normally try to do with POM can be done using more complicated layouts and formatting. These uses might include ticketing, learning worksheets, and so on. The only addition that would be useful is a graphic field for customizing logos, etc.

Mind you, it's not that the other traditional print solutions don't have good uses. And certainly none of these is the complete solution for all scenarios that we'd all love to see. Maybe we'll get to one good answer eventually, but in the meantime we'll just keep sweating out those details.

Having left his day job and striking out on his own, Doug is now the man behind the name 'Finite Monkey'. He's worked on numerous Director CD and Shockwave titles, and currently finds himself specializing in multiuser environments and games. Check out http://www.finitemonkey.com or mail at dougb@finitemonkey.com