>The thing I like about it the least: Let's say I develop a form for a web
>site client. Now when their customers fill out that form, my client gets an
>xml file. And my client isn't likely to have anything more than the Reader,
>so....
So... Adobe make a sale. At least potentially. That's their plan!
HOWEVER, under almost no circumstances would you do what you describe.
Email is not a reliable way to "submit" forms.
When someone designs an HTML web site and puts a form on a page, they
could submit this by email. Have you ever seen a site which submitted
a form that way? Probably not, it just doesn't work well enough.
If you are doing this commercially you need to be offering server side
form handling via PHP, ASP, CGI or whatever. These can send an email
of course, no problem there. If you want to send a PDF, you can buy
server side software for some thousands of dollars to do the merge of
data and PDF, and then email the PDF. This is not necessarily the best
client solution: usually better to email a notification and have a
private script on the server which delivers to the end user.
If all this sounds like more work than an HTML form, you should note
that you can submit in HTML format and similar processes apply. Also,
consider why you want PDF forms: what do you want to gain? There are
many, many things improved over HTML forms, but simplicity is not one
of them.
Aandi Inston
