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