Designing forms for Forms

If you will be using the same form design to render PDF and HTML forms, it is important to understand that some behavioral differences exist between the two types of output.

To create a single form design that lessens these behavioral differences, follow the guidelines outlined below:

Consult the Transformation Reference

Because PDF forms can be viewed by using Acrobat or Adobe Reader, the form supports the full range of object properties that you define in the form design. If you will be distributing HTML forms based on the same form design, some client applications (for example, web browsers) do not provide the same level of support for individual object properties. The Transformation Reference will help you to determine how objects behave in a particular client application. When creating the form design, try to work around any limitations in the client applications by finding ways to implement the form without relying on unsupported object properties. See Form transformations.

Enable form caching

Form caching can increase the performance of forms when rendered. In addition, if you are designing a form that has a fixed layout and want to render the form in HTML, you must enable form caching. See Form caching.

Include a layout that works for both PDF forms and HTML forms

When an HTML form is rendered, page sizes (required for paginating PDF forms) have no meaning. Because a form that has a flowable layout can expand on an infinitely long HTML page, it is important for you to avoid adding footers on the master page. A footer beneath the content area on a master page could overwrite HTML content that flows past what would otherwise (in a PDF form) be a page boundary.

Provide unique names for fields, exclusion groups, and subforms

For HTML output, all fields, exclusion groups, and subforms must have unique names. This will prevent possible data merge issues.

Consider accessibility

Read the section about creating accessible forms and use the guidelines to build accessibility into your form design. See About accessible forms.

Determine where to run scripts that exist in the form design

By default, scripts are run on the client. If the scripts that you include in a form design should be run on the server, or on the client and server instead, you may have to change or override the default setting. See Considerations for Creating Forms for Server Processing.

Preview the form

Periodically preview the form by using Designer (for PDF forms) or the target client application (for HTML forms) to troubleshoot problems early in the design process. See To preview and test forms in the Preview PDF tab.

Test the form design with sample data

If Forms will be merging forms with data, use test data to thoroughly test your form designs before you make finalized versions available to Forms. See To preview a form using sample data.

Consider web browser limitations

Some web browsers have limited capabilities. It is a good idea to consider the limitations of the lowest common denominator and design your forms accordingly. See Working around web browser limitations.

Before you can submit form designs to Forms, some additional work needs to be completed:

• The developer of the custom application must define the requirements of the application. The file format of your form design (XDP or PDF) depends on these requirements.

• Transformation options must be defined in the Forms API to support the required transformations. The developer of the custom application will set the options based on input from you.

• If you will be using a signature object in a PDF form design, the developer of the custom application has to integrate a third-party solution to support digital signatures.

When you create a form, you can specify the format in which to submit its data. You specify the data submission format in Designer in one of two ways:

• By placing a Button object on the form, specifying it as a submit button, and choosing the format to submit the data.

• By placing an HTTP Submit button or Email Submit button on your form.

After you add a Button object to your form design, you can specify a format to submit data in the Submit tab of the Object palette. HTTP Submit buttons and Email Submit buttons are preconfigured to use specific submission formats. For more information about data submission formats, see Submitting data using a button.

Designer supports four data submission formats:

• XML Data Package (XDP) This format is the only format that supports the inclusion of attachments.

• PDF

• XML Data (XML)

• URL-Encoded Data (HTTP Post)

The URL-Encoded Data (HTTP Post) format is the only data submission format for HTML forms.

Forms renders forms in numerous formats through transformations, which render forms to suit the capabilities of client applications such as Acrobat, Adobe Reader, a variety of web browsers, or a screen reader.

Forms supports any HTML client that follows the CSS2 specification. Because browsers vary widely in their support of CSS2, and older browsers do not provide support, several browsers and generic user agents require their own specific transformation.

For a list of all objects and the supported properties for each transformation type, see Transformation Reference.

To supply form designs to Forms, you will need write access to the location from which Forms retrieves files at run time. The developer of the custom application will know the location, and your network administrator can set up the appropriate permissions.

Completed form designs are placed in the local file system for the developer of the custom application to access. You have to include any other files that are required to support the form design (for example, images).

If you are using the stand-alone version of Designer, you can publish the form designs to that location. After your access rights are set up, use the Designer Publish command (select File > Publish to Repository). See Publishing forms.

Forms accepts form designs in either of the following formats:

• XDP

• PDF

XDP is the file format created by Designer. Choose this format to submit the form design, any form data, annotations, accessibility tags, and all other relevant information needed for Forms to subsequently render the form at run time. You must choose this format if the form will initiate server-side processing.

Save the form in PDF if the form will always be opened in Acrobat or Adobe Reader.

Choose PDF if the form contains a signature field or if users will be expected to save data directly in the PDF form at run time. If the rendered form will have a fixed layout and you expect the form to be requested often, providing the form design to Forms in PDF can improve run time performance.

Do not choose PDF in these situations:

• If the form will initiate server-side processing

• If Forms will be used to render HTML forms or forms that have a flexible layout.