HTML is easier for the client, but if you’re not used to doing them, you’re in for a learning curve-- unless you want to build them in tables, where the styling is a little easier but then you still have to worry about accessibility re both tables AND forms. Being volunteer still means doing it right.
Your problem might be whenever I say “back end” because that means you have a server guy who can write basic, common scripts and functions in a programming language. Not having one of those would be the ONLY reason I’d do anything with third-party software like PDFs. PDFs are larger than necessary, require a document reading program to open and view (though it doesn’t have to be Adobe Reader, and most OSes come with some sort of document reader), and those with only Adobe Reader can’t fill the forms in on the computer. We used to have that on the old websites of ours, “just fill it in and print and mail” and people were like, “How come I can’t fill it in?” They only had Reader, and you’d need the whole Acrobat suite to actually type in them.
HTML forms on the other hand can be accessed by everyone, including the blind if they needed to. IF you have a back-end guy, you can do ANYTHING with that information, set it in whatever form, make your printer in an office automatically print it, email it, send it to Russia, whatever.
Here’s the HTML side of my most recent form (that it’s in Dutch is inconsequential, the tags are still plain old HTML tags and the CSS is regular CSS), and the [url=http://stommepoes.nl/Autoverzekeren/printafsluiten.html]print version (which is fill-in-able on the computer, which is how I’d do it if I were blind but wanted to still postal-mail the form to you). To see the actual HTML, View Source. To see the CSS, the url to it is in the <head> section.
Because they’re the static demos sitting on my site they do not do anything-- the scripts are on our company comnputers which my colleague writes and they interact with our CCS, a customer insurance premium calculator we bought. So where my forms say
action=“something”
this is where the script gets referenced, like
action=“default.php?page=berekenpremie_resultaat”
If this is all above your head or just not what you want to do, and want to stick with PDF’s, I can’t go any further as I’ve had nothing but bad experiences with it and currently I’m on a Linux box and always have a hassle trying to get Adobe products working (I don’t even use Reader on this machine, I use a Gnome Document Viewer instead). On our old sites, the PDFs were never email-able, only print-and-mail-able.
I’m guessing to email a PDF you’d still need an HTML form (so everyone can fill it out, not just those with Acrobat Suite), a copy of the blank form as a PDF on the server, and a script (in the action of the form likely) that takes what was filled in and adds it to the PDF, and then maybe another script that emails you the PDF.
Actually, Adobe might have such a script or product that does that-- takes HTML input and fills it into a PDF with the same fields (is this what Distiller does??). If it does, then your users don’t need any special software, only you guys. You’ll still prolly want a back-end scripter though. Someone who can get all this working on the server. The emailing part of the script would be separate from the form submit. I’m suspecting the reason Outlook/whatever is trying to open is because your forms currently have something like
action="mailto:info@firedept.org"
the mailto part tells the browser to go tell the computer to go open the email client. If your form instead just has an action to dump the info into your PDF, then the emailing would be done on your end, not the client’s end. This is what your back-end guy writes/installs, the script for this.
If you are interested on building an HTML form, you can start another thread and we can walk you through all the HTML and CSS stuff.
so now I’m trying to figure out if i need to direct the submit button to a cgi script, php or something…?