• 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 this category.
  

  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 low-speed 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 application serves 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 computer users.

• 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.
  

  Why?
  
  You 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.
  
  All of 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.
  
  Such a 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 is this:

  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
       Jill
  
  "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 come 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.
  
  For example, 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 be printing, 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 your company.

See also What is an HTML form?
See also What is a PDF form?