|
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:
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 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:
|
|
|
