PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
Leonard,
At 6:12 PM -0400 7/11/03, Todd Kueny wrote:A lot of customers have been asking us for the ability to convert Acrobat Forms directly to HTML.
Interesting. I've talked to more folks who want the opposite - HTML or Word forms to PDF forms...
The interest here seems to be that the customer has PDF forms working and has run into form architecture/conceptual/scalability limitations...
...
For example, you might want to have realtime validation happening at the field level - say a drop down that queries a database so that the choices are always current.
Right. There is no way to do that with non-Reader Enabled PDFs. You can, however, do that in a number of ways with Reader-enabled PDFs or with FULL Acrobat.
No one except Adobe wants to start out with a "free" forms workflow that lands them in a situation where all the users must have "full" Acrobat. But Reader-enabled PDFs (this is 6.0 only, right?) solve only part of the problem... (see below)
2) Forms seem to have the issue that the data fields they collect are time-decoupled from the server, i.e., if I create a form and later I need more data, or a check box becomes a set of radio buttons, I have no way to find all the forms in use and alter them.
I'm not sure I follow you here. The layout & specs for a form (such as whether to use check boxes or radio buttons) is a design time issue, NOT a deployment side issue.
I do agree that such things as "contents of combo boxes" may change between design and deployment - but again, those can be solved when not limited to Reader and non-enabled PDFs.
No, I'm not talking about design time/run time issues. An enterprise creating PDF's is likely have have PDF's which have life-times from weeks to years, spanning multiple Acrobat versions (4 - 6). When you mix in the concept of active data fields by creating an Acrobat form, you "bind" the form to the application and data structures present in the enterprise at the time the form is created.
The problem we see with both regular PDF's and PDF forms in terms of an enterprise is "What do you do with an Acrobat forms when that application and/or its data structures change?" These problems include:
1) the form now collects the wrong data (too much, too little, etc.),
2) the form user doesn't know that the information being provided is incorrect or incomplete,
3) the applications collecting the data must some how retain backward compatibility with old forms and their javascript functionality,
4) there is no way to "find" and/or "fix" all the old forms in an enterprise. (Yes, I understand that I can create a situation where the "submit" button on an old form causes an error or makes a new form and fills some of it out, but that's not the issue.)
When you couple this with the fact that Acrobat is not really an enterprise IT tool you have the customer set we are talking to (I define IT enterprise tool as VB/SQL, Java/SQL, Apache/CGI, etc. where there is a data management process in place.) The customer set we are looking at already has IT infrastructure as well as Acrobat forms - their problems include
1) synchronization of Acrobat forms to IT systems.
2) managing versioning of forms (both form content and versioning with IT systems) in environments where forms change frequently. (I understand managing PDFs with content management systems, but what about the data connections inside the PDFs?)
3) managing the trade off between Acrobat forms print fidelity vs. form functionality, e.g., Acrobat javascript.
Again, I am curious what the current state of the art is on the above issues...
Todd
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
