>> Various other tools which were promising this or that way to handle fields in PDF would either deliver files incompatible with several versions of Acrobat, or would require a special reader of their own... after a week of frantically reading the specs and API documents by several manufacturers, we had to drop the whole project.
>
>How did that saying go? "Standards are a good thing -- everyone should have one"

"- the more, the better". Which is exactly the reason why html won as a way to transfer data, while emailed pdf forms never got anywhere. And the latter idea was circulated a surprising number of times, by many of my clients. The idea that a client/user/visitor/applicant should fill a form and send it back comes so easily, and most of these forms already exist in pdf format. But no, Adobe tried to tie in and sell more tools, and changed the standard every time enough competitors found a way to replace/replicate the functionality with their own tools, and this line of development went nowhere. In most of the cases we had to develop a web app, just to have a tool whereby their users can fill out some forms and send them. Because pdf just didn't work, thanks to Adobe's greed.

Another point: the simplest old way to create pdf was to install a postscript printer driver, print into a .ps file, submit that to GhostScript and you're done. I've downloaded the thing from UT (it worked for frx, I reworked it for Word) and it worked flawlessly... until we got into 64-bit Windowses. Why did it stop? Because the last available PS printer driver, by Adobe, was from 1991. They never recompiled it for 64-bit. It simply won't install.