Designing forms for Forms

The process of creating a form design for Forms is identical to creating any other type of form design. However, when you create a form design for Forms, the same form design can be used to render PDF or HTML forms.

Using Forms, you can post PDF and HTML forms on the Internet or an intranet. When Forms renders an HTML form, the form typically opens in a web browser. When Forms renders a PDF form, the form may open directly in Acrobat or Adobe Reader, depending on the settings of Acrobat or Adobe Reader on the user’s computer.

When you distribute forms in a web environment, you must consider the limitations of the environment. For example, some of the features that you can assign to form designs by using Designer are not supported in a web environment, and different web browsers display the same objects in different ways.

Furthermore, some form capabilities are not directly supported by web browsers or HTML technology. The full range of form capabilities is available only when a PDF form is opened using Acrobat or Adobe Reader.

For information about the properties supported by different web browsers, see Transformation Reference.

Considerations for creating form designs 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.

Additional requirements for submitting form designs to Forms

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.

Specifying the format for submitting data

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.

Form transformations

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.

Note: If you choose the HTML4 transformation to support Netscape 4.7.x, any JavaScript designated to run on the client is automatically run on the server instead.

Copying form designs to the local network

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.

Saving a form design: XDP or PDF

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.

// Ethnio survey code removed