QUESTION: How do I know whether I should use HTML forms or PDF forms for my Web-to-print system?
are the conventional means of collecting
information from Internet/Intranet users
via Web browsers,
are better suited for
that purpose in some situations.
Use the information below as a guide to help
you decide which kind of form to use for
=> Internet Connection, Targeted Users
It might make sense to use PDF forms if
your users are people with high-speed
Internet connections that read PDF files
on line frequently. For example, employees
that work in a corporate environment probably
fit into this category.
On the other hand, it might make sense to use HTML forms if
your users are people that are likely to
have low-speed Internet connections
and/or might not be accustomed to reading PDF files on line.
The general public (i.e., all users of the
Internet anywhere in the world) fit into
Why is a high-speed Internet
connection needed for PDF forms?
In many cases
(although certainly not all cases), PDF forms
contain more graphics than HTML forms do, and
therefore some PDF forms might
be relatively large. This isn't a
problem for a user that has a high-speed
Internet connection, but a user that has a
connection (for example, a user that depends on a
dialup connection) might become frustrated and
impatient while waiting
for a large PDF form to be transported from a Web
server to the Web browser on his computer.
Why is it necessary that users of PDF forms
be accustomed to reading PDF files on-line?
It's not that PDF forms are difficult to read
or understand; the issue is that PDF forms
served from a Web server must be displayed within
a user's Web browser, and some Web browsers
are not set up to display PDF files.
To be able to display PDF files, a
Web browser needs to be configured to
utilize PDF-viewing software such as
Adobe Acrobat or Adobe Reader.
Once that's done, the PDF-viewing software
actually runs within
the Web browser, and that's how the
Web browser is able to display PDF files.
Some computers have Internet browsers that are configured this
way by the computer
manufacturer, but many do not. And although it is
relatively easy to obtain free software
that enables a Web
browser to display
PDF files (the Adobe Reader
this purpose and can be downloaded free of
charge from many sources on the Internet),
this extra step can be a hurdle or an annoyance to some
=> Layout and Typographic Control
- It might make sense to use PDF forms
if your users will utilize your forms as
document templates for the purpose of
creating customized versions of documents
for which precise placement of text and graphics is important.
On the other hand, it might make sense to use
HTML forms if typography and layout are not
an important issue.
can design your PDF forms
to look very much like the finished documents,
and you can set them up so that the
screen representation of the text that
a user types into your PDF forms is
very similar in appearance to the
text that will be in the finished documents.
That is, you can set up a PDF form so
that a particular text-input field where the user enters
text is located on the PDF form in the same
place where that text will appear in the finished
document — and you can also control the font,
font size, and color
that are used for the screen display so that
the screen representation that the user
sees when he's typing text is very similar
to the appearance of the text
in the finished document.
this will make it easy for a user to envision
what the final version of a document
will look like
while he is typing text into the
PDF form, and he'll also be able to
judge how much text will fit into the
space alloted for it.
high-fidelity representation is not
possible with an HTML form. In fact,
"copyfitting" is a
common problem associated with utilizing
HTML forms in a system that allows
users to enter text
that will be printed on paper documents
or rendered in electronic documents.
What is copyfitting?
Copyfitting is the process of ensuring
that a block of text isn't too long or
too short to fit the space alloted for it.
The issue that we're focusing on here
If your user
doesn't know what
the layout of the final document looks
like, and if the font and font size that's
used to display text on the screen while
the user is typing it is
nothing like the font and font size that
will be used in the finished document,
it's difficult for your user to judge
how much text to type.
Note that — in most cases — you
CANNOT solve this problem effectively by limiting
the number of characters that a user is
allowed to type into a text field in an HTML
form. The reason this doesn't work well is
that most fonts are set up so that some characters
occupy more horizontal space than other characters.
This can be illustrated by a simple example:
"Jane" has four characters and so
does "Jill," and the same font,
font style, and font size are used for both
words — but you can plainly see
that "Jane" occupies more horizontal
space than "Jill." If you are an
HTML programmer, and if you set up
an HTML text field (INPUT TYPE="TEXT") with
a MAXLENGTH of 4, and if you have a relatively
small area on your document template into
which this text must fit (for example, a
rectangle that is about ½" wide), "Jill"
might fit, but "Jane" might not fit.
NOTE: If you're not an HTML programmer, you
might not understand everything in the
preceding paragraph — but don't worry
about it. You can still follow along with
our explanation about copyfitting.
There are various ways to deal with the
issue of copyfitting when you're doing
variable-data publishing — some more effective
than others. For example, some
variable-data-publishing systems are
capable of calculating the font size for
a text block on the fly, with an aim toward
making sure that the text block isn't too
big or too small — this approach is
appropriate for some situations but not
others. However, it's not our intention here
to get involved in a comprehensive
discussion about copyfitting. The main
point is this: if you're creating a
variable-data-publishing system that
allows users to type free-form text
that will be incorporated into finished
documents, you should not gloss over the
issue of copyfitting, because it will probably
back to haunt you later when your system
starts producing documents that are
unattractive or totally unusable.
It makes sense to use HTML forms if
the variable data that gets printed on
your documents is entered on the forms by users that
do not know that the data will be used to
generate documents — or if your documents
are not yet designed at the time that your
users are typing data into the forms.
visitors to your company's Web site might be prompted
to type their names & addresses into a form —
and then you might use those names & addresses
at a later date to create personalized documents
that will be mailed to your site visitors. In
this case, a simple HTML form will probably suffice,
because visitors to your site have no
need to envision where their names & addresses
will be printed on the documents that you'll
nor do they care what font and font size will be used to
print their names & addresses. In fact, in
this situation, your site visitors probably do not
even know that their names & addresses will
be printed on any documents created by
What if you have conflicting sets of criteria?
For some reason, you might want to design a system that
allows any Internet user to type free-form text
that will be incorporated into a nicely designed,
document. These requirements conflict with
two sets of guidelines outlined above — and
have to make a judgment call as to how to
handle this situation. In time, Internet
technology and variable-data-publishing
technology will probably mature to the extent that
some of the issues discussed above will
no longer be challenges — but for now,
you'll need to decide for yourself what
to do for your particular situation.
HTML forms and with PDF forms to handle
data validation, dynamic display of form
elements, and other tasks.
See also What is an HTML form?
See also What is a PDF form?
Let our Wizard help you find the right product!
Copyright © 2001-2019 Citation Software Inc.