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?"

Comments

HTML?

[Anonymous Coward]

Add a bit of PHP, maybe a database, and easy form processing.

HTML

[Fred Nerk]

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.

PDF forms would seem to be a perfect fit.

[Talonius]

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.

Re:PDF forms would seem to be a perfect fit.

[CRCulver]

I'm terribly sorry to have to be the one to inform you of this, but PDF sucks.

Some of the arguments on that site you cite are silly. I mean, the guy writes: "Have you ever looked inside a PDF file? It may preserve the document's data, but it does it in a non-standard way." What is a "standard way"? Furthermore, PDF doesn't do anything different than PostScript, and PostScript is revered in the printing industry because it is so dependable, for it will always print the same way.

The author then goes on to say: "Printed documents are unreadable until you track down the correct printer driver." Duh. This isn't a PDF problem, it's a printer problem. I'm sure MS Word, DVI documents etc. look like crap if you can't set up your system correctly.

Personally, I would like to see XMLFO become the usual method of interchanging printable documents online because then one can approach it in many ways through standard XML tools. But PDF isn't bad for documents one expects to be printed.

XML

[jefu]

This is the kind of problem that XML solves perfectly.

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.

XFDL and soon XForms

[bwt]

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.