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?"
... 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.
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.
I thought you can't save the changes in the "READER" (free, aka "the one used by everyone (on windows)") version of the Acrobat. + Very much readable + easy to use + Can be saved off-line and emailed - Requires expensive full version of Acrobat to be truly a 2 way communitacation tool. - Can be parsed for data, but not an easy/cheap task. - The fields are not flexible (dont expand in relation to data volume) i.e. I always have to tweak them in full Acrobat for my last name to fit.. grrrr... InfoPath though XML-based, seems to require Office 2003 - the hole you seem to be trying to avoid. + XML-based, easy data parsing. + Fields are flexible. + Can be filled out off-line - Need extensive MS infrastructure for support of these. - Talking about a niche market! Geesh. To view forms, you NEED InfoPath. HTML forms. well... you know the story... + Can look and work in any way you want. + Parse\store in any way admin wants. - Server\Live connection required. Simple Text files: i.e.: (field code1) answer (field code2) answer (field code3) answer + Universally readable, save-able, flexible "field size". - Doesn't look good, users can mess up the filed codes.
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.
Another XML fanboy.
First you create XML. Then you build DTD/Schema to enforce a set
of constrictions on the original XML (note: DTD/Schema were added
later to XML).
Then you 'automatically' convert the said XML to XHTML.
right, you build another XML to represent how to display the
original data within original XML/DTD/Schema. Such display XML
shall not be called XML, lets call it different things, for there
are different DTD/Schemas for display XMLs. The Mozilla crowd
wants you to use XUL, the ms camp wants you to use XAML, and
ofcourse, others will say XHTML + Javascript + some server side
sollution. When I say display I really mean display with ability
to edit/add/delete.
Anyways, since XAML/XUL are esoteric we are left with XHTML +
javascript + server side scripting (jsp/asp/php). This, as you
say, is quite bad for true controlled non editing display. We
want to export to DOC (be it RTF, or ms office XML), or to
ascii or PS/PDF. Good, now hope that your original display XML,
afterall from which you generated XHTML, can also be used to do
the conversion to other formats. Here again you will come to
problems, as you need to keep playing and writting converters
from one XML format to another, massage their content, until the
PDF/DOC exporters work like you want.
Now, you have gone through tons and tons of extra hoops, with a
fairly new technology. And it took you how long?
Here is somethings that much faster:
1. sql -> setup tables / foreign keys / check constraints
2. ms access -> link tables
3. ms access -> auto wizard the forms
4. ms access -> export forms to ASP
and you are done. And anything to do is few clicks away. Now,
its not perfect, actually far from it (ms-access exported forms
to ASP leave ALOT to be desired) but atleast its not hodge podge
as it is with the magical XML.
I cringe when people say XML is a sollution to every data related
problem. The only thing that XML by itself that is amazing is
the nested data structure support. Everything else the good
old tab/comma delimited format already supported!!
--
/apz, XML is good and all when used right
We've just done a pilot of exactly what the questioner seems to be asking for - and we used online forms (written in XHTML), and a stylesheet for rendering the form to FOP, and thence an Open Source product (forget which) to render to PDF forms. User gets on to the website, fills in the form online, submits and gets a filled-in PDF back, which they can sign and send in by snail-mail if they want to. Glorious thing is we've already got all the data stored from the online form, so we're only checking for their signature.
Um, thanks for the advertisement, but the poster asked for a CROSS-PLATFORM solution. InfoPath is Windows-only.
I've used InfoPath in the past, and while it got the job done, there were about 10 different other ways to go which would have gotten the job done in the same amount of time AND been cross-platform.
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.