PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
At 09:02 AM 7/14/2003 -0400, Todd Kueny wrote:
The interest here seems to be that the customer has PDF forms working and has run into form architecture/conceptual/scalability limitations...
Such as??
There are indeed issues - I'm just curious which ones you are seeing/hearing...
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)
Hence the reason for Reader-enabling - which works with Reader 5.1 and later.
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,
Agreed.
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.
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...
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.
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.)
There have been at least two attempts that I know of to implement "self-updating" PDFs - though not for forms, per se, but for updating content. The concept is sound and there are a number of technical ways to approach the problem.
But again, I would argue that the issue here is NOT format, but deployment strategy!
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.
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?
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.
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?
Leonard --------------------------------------------------------------------------- Leonard Rosenthol <mailto:[EMAIL PROTECTED]> Chief Technical Officer <http://www.pdfsages.com> PDF Sages, Inc. 215-629-3700 (voice)
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
