PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
Leonard,
... spanning multiple Acrobat versions (4 - 6).
In most/all enterprises, there is standardization on Acrobat versions, so I don't believe you have this problem (at least w/in a single enterprise). And if a newer version is needed, most/all have procedures in place to handle mass updating.
Sure, enterprises have standards, that doesn't mean that the form recipient is an enterprise user - the recipient could be an enterprise customer, for example.
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.
I would say this is true for ANY form - HTML, PDF, XForms, etc.
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?"
Rebuild the form - same thing you do with any other form type. I don't see how/why PDF is any more of an issue than other form types...
Therein lies the problem - where is the source for the form? In a traditional IT-managed HTML-type world, source and data control is centralized along with version control; so finding the source file for the form is easy as is locating the data it might touch. In the Acrobat world, an enterprise can "lose control" of the form process, e.g., people make forms because they can, the forms get used and then there's a problem - the user who made the form quits and erases their PC.
UNLESS you are planning to argue "but PDF is a 'take away' format while HTML has to be kept on the server". In which case, I'd respond that's a distribution problem NOT a format problem. If the PDFs are deployed via server, then they can be changed as easily as any other format.
The customers coming to us have, in part, a deployment problem - a problem we're being asked to help with - but the problem is more than just that. I guess we see that what the form does need to be represented in the server in an abstract sense - then creating HTML or PDF or whatever is just an expression of that metadata. So our interest is extracting the metadata from the existing forms and managing that - not managing the forms themselves. (PDF notation is a really poor, non-standard way to represent data from the IT perspective.) We're looking at deploying tools to turn Acrobat forms into metadata and then providing tools to distribute and manage the metadata.
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.)
Acrobat sits ON TOP of those tools. It's the UI, just as HTML is.
Those backend/server-side tools you are talking about are great for dealing with the data, but they all need a presentation layer - be it PDF, HTML, XForms, Java Applets, etc.
I disagree - because javascript is embedded in the form, which is "decoupled" from the web server, PDF is DIFFERENT. I always can push javascript from a web server with my HTML and I know that the HTML I push will be what actually runs in the browser. In the PDF case, when the form is released into the "wild" the javascript is bound to the Acrobat form FILE, not the server or the server application. This is the problem.
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.
Wouldn't a dynamic form creation system, just as HTML forms are created, be a solution here? Something that could be given a "description language" (xsl:fo + xforms??) and generate the required PDF on demand?
Yes, but I need technology to corral the loose Acrobat forms and get them into a metadata format first.
2) managing versioning of forms (both form content and versioning with IT systems) in environments where forms change frequently.
You can solve this in two ways:
1) Examine and address document/form distribution issues. You have solve this for ANY form format that is chosen.
2) Develop/license "PDF updating" technology.
Agreed. We're looking at this for forms. We have solved this issue for PDF in the web world where the PDFs are part of an on-line ordering process.
3) managing the trade off between Acrobat forms print fidelity vs. form functionality, e.g., Acrobat javascript.
What do you see as the problems here?
People start using PDF forms because the capture the print representation accurately. Applications that require print fidelity tend to do a poor job on the IT side because the forms are coming from graphic arts and/or non-IT people. Applications of Acrobat forms appear to then "out grow" their origins and become mainstream. However, because of the above issues (javascript synchronization, etc.) the form never really gets integrated into the larger enterprise IT picture (its too different) - this coupled with the other issue above case the break down I describe.
Todd
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
