Slashdot Mirror
Formats for Electronic Forms?
Bifurcati asks: "I'm a grad student at the University of Queensland, Australia. I am frequently required to submit forms (e.g., annual reports) which are sent as Word or RTF documents and must be filled in electronically. However, these are almost impossible to use under Linux (e.g., StarOffice) because the tables and formatting are just too complicated and get mangled. Even Word for Mac sometimes has problems. Can anyone suggest a better, cross-platform format? Could PDF files with forms do this? What are the costs & learning curve? User friendliness is vital for both admin and student. Alternatively, can anyone suggest ways they could make their Word files more compatible across platforms?"
Add a bit of PHP, maybe a database, and easy form processing.
What about good ol' online forms? They are accessable from almost any PC, the users can't go changing the layout of the forms, data can be real-time, and there's no need for someone to parse the forms by hand.
Anything is possible, except skiing through revolving doors.
I'm sure theres a older warez version out there somewhere (given that uni student have a tight beer budget).
if
Don't care for formatting, load in OO, fill in and save. .swx) and mailed back the result.
It's not you who has to wade through the bad formatting
once you saved as rtf (or
They allow you to save the data with the form, transfer the data to a remote source without any loss, and at the remote site you can process the PDF form with additional software. Individuals can save the form and take it with them to have the data entered, removing the requirement for a connection to the network (ala HTML forms).
Acrobat allows you to easily specify the types of data you want them to allow to input. There's quite a few PDF form creation software packages available as well allowing you to do to this.
We use them at my place of employment and have had only one problem: data entry sections that can widely vary. There's no way to make the section grow or shrink that we've found so if the form creator specified area isn't large enough to hold your data you could be out of luck when you go to print.
In that same vein they don't deal well with ad hoc data being added to the beginning or end of the form as a Word or RTF file would. The purpose of a form is to get away from that sort of data, but it happens.
My reality check bounced.
You can't just edit PostScript directly?
... and they open just fine.
As for compatibility, Word 2004 has a nice feature called "Compatibility Report" which analyzes a file before saving it and warns you which versions of Word might have problems.
My general advice for forms is to implement an XML based form server. I know that Adobe is pushing their PDF forms server but that's really an overkill. If you have money to burn, Microsoft's InfoPath is a good choice as well.
How often do anual reports come round again you lazy bastard?!
Oh wait, you posted to: ask slashdot. Duuh.
I jest, I jest.
Liberty.
i was going to suggest something along these lines. if you're serious about it, you may want to check out xforms especially if you're doing any major processing of those forms once all is said and done.
There is essentially no learning curve for using PDFs. In MS Office (or, for that matter, any Windows application), use PDFCreator. On OS X, exporting to PDFs is a function of the operating system. In Unix/Linux, there's ps2pdf (and just about any application will print postscript to file), as well as KOffice and OpenOffice.org.
XML would allow you to define (in a DTD/Schema...) the kinds of data that the form should be collecting and do it in a format neutral way. Then you could use web pages (translate the XML automatically to XHTML, grab the data and translate back). This can be fairly easily automated as could other methods to handle the input. PDF and DOC (and its cousins) are poor substitutes as you can't as easily identify the important information in the document, you can't store it concisely and you can't then do semantic level searches on it. Furthermore, in XML processing you can do consistency checks and so on.
In a web setting (or similarly "connected" kind of configuration) you could pre-populate much of the data for the user. You could even "compile" the xml to a set of online forms (XML -> GLADE or the MS .NET XML window description thing).
Once the data is entered into XML it can be massaged and output in any needed format (I don't know of any free XML to DOC format converter, but I suspect that the XML enabled MS Office stuff can do it if needed).
By the way, while that first step is easy to say, actually defining the DTD/Schema/... is likely to be rather difficult. (Look up sometime what it takes to specify an address.) But this difficulty pays off immensely in that you know much more about your data, and much more about the ways it might be used. Once this is done though, the other parts are really pretty straightforward.
It might take a bit of work, but in the long term coding this up in XML is likely to save far more work and money.
It's perhaps worth pointing out that it's also a problem for Windows users. If you have a version of Word that's very different from the one used to generate the form, there's a good chance that it'll be garbled for you, too.
The funny thing is that university admin types tend to use ancient, unpatched versions of W98 (or even W95), so it's students with an up-to-date XP machine that are likely to have problems. OO on linux can often read such files better than recent versions of Word.
Of course, the real solution is to somehow educate them to the risks of using Word docs. But they're university people; they probably can't be educated.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
PDF forms are easy as, only problem reader will let you enter the data, but only Acrobat will let you save the data back into the PDF.
The learning curve for setting up a PDF form isn't too bad, whoever creates these forms in the first place just needs to take their Word file, convert it to PDF and mark the form fields in Acrobat.
For the end user putting data into the form - if you've got a PDF printer driver under Windows then you can just print them back to a PDF, or under linux print as postscript and convert to PDF.
It all comes down to the initial effort, and if its worth it for those creating the form.
XFDL works for this, but unfortunately there is only one vendor: PureEdge. The US Air Force is using this for online/offline forms capabilities. XFDL was sort of a predecessor to XForms (one of the PureEdge lead technicals is on the XForms WG).
Eventually, XForms should have enough support to category kill this problem. It's just taking a while because it has a lot of dependencies on other XML specs that make it difficult for implementors. I was SO glad to see IBM and Novell step in to provide resources to Mozilla implement XForms.
Well two things. One scribus will let one create PDF forms. Second OpenOffice can create it's own editable forms, and then print that to PDF.
I've run into the same problem as the questioner... I don't have Adobe Acrobat (and don't really want to buy it for personal use, at $250+), and making locked forms in Word can be irritating to get working right, and many people can't fill in the form.
Sure, I can create PDFs with no problem using various software (it's built-in to OpenOffice, for one)... but I haven't seen free or open-source software that will let me create PDF *forms*, where the user can fill in the fields before printing it out.
Actually, that brings up another issue -- even if I had Acrobat, would it let me generate PDF forms that could be saved? Most of the ones I see (I'm thinking tax forms here, actually) only let you fill in the fields and print out the result, not save your modified document with the field data.
This really strikes me as a hole in available software (proprietary or not!).
Here's my personal example: For a recent school reunion, we wanted to build a "face book", where people could fill out and return (via email) a form with a photo, current name and contact info, recent history, etc... and it was a real pain to do. I ended up sending out a Word doc, with *parts* of the document locked (with form fields) and parts unlocked (for inserting photos and giving users font control in parts). Then I also sent out an OpenOffice-generated PDF, for people to print out, fill-in by hand, scan, and email back as an image. Some people who had Acrobat installed managed to edit this file and send it back.
Needless to say, there were plenty of people who had a hard time with either format. Some just emailed me back the text they wanted to enter and attached photos to the email, since they couldn't get them properly into the Word doc. Some people gave up, and didn't get a page in the book. And this is ignoring all the hoops *I* had to jump through to open the attachments from people using Outlook (winmail.dat, anyone?). [well, that last complaint is a rant for another day]
Why should this be so complicated? Yes, I considered setting up a simple webapp to collect the info. But of course every entry needed to fit on a single page... and HTML is not at all designed for specific control over that kind of thing. Plus I'd need at least some control over what I'd let people upload as a "photo", for security reasons, and have to automate cropping or at least resizing of the image... it got way too ugly way too fast.
I could have given people the password to unlock the Word doc. But I'd have to warn them that once you unlock the document, you can't edit the form fields anymore. Oh, and if you re-lock it, it kindly deletes everything you previously entered in those form fields. Ugh.
Information collected with InfoPath 2003 can be integrated with a broad range of business processes because InfoPath 2003 supports any customer-defined Extensible Markup Language (XML) schema and integrates with Web services. As a result, InfoPath 2003 can help you connect directly to organizational information and then act on it, which leads to greater business impact./ overview.mspx
http://www.microsoft.com/office/infopath/prodinfo
As a designer, I've had to make forms for a variety of idiots. Lots of idiots choose MS Word/Works, which is fine if you lock the documents and provide very specific instructions. For personal and in-office stuff, I use Excel. It's ugly but functional. For most other forms, I prefer the PDF format. For fancy stuff, a lot of design software (including Quark, Photoshop, etc.) can export to PDF, and you can drop the form boxes in later. Although Acrobat lacks the tools you might need, PitStop Pro by Enfocus will give you neat and necessary tools. It makes Acrobat more crash-prone, but it's worth the pain. If the creator of the forms has PitStop, the users just need Acrobat and a readme. Short of encrypting the data or sending it as graphics, this is (in my opinion) really the best way to send semi-sensitive form data over the internet.