PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
At 11:41 AM 7/14/2003 -0400, Todd Kueny wrote:
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.
Good point.
But I don't think requiring the user to have at least Acrobat 5.x is a problem. Acrobat 4 is no longer supported by Adobe, after all.
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;
Why isn't that the case for PDF forms? Again, that's an internal control issue, and not a PDF-specific one. You, potentially, have the same issues with HTML-based forms in some companies.
I would suggest that any company deploying PDF forms would have those forms in their DMS or version control system - like every other file they make available to customers.
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.
But that's not a PDF issue. That can be true for HTML, XForms, etc. That's a process issue in the enterprise that needs to be solved REGARDLESS of form format chosen...
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.
Right! That's the best approach to the problem - content on demand based on current information, and delivered in the best way possible.
That's the problem that the Adobe Forms Server, for example, addresses. Single set of document description that can be deployed in HTML, XML, PDF, etc. based on the user's choice or their environment (ie. don't do PDF on a small screen handheld).
(PDF notation is a really poor, non-standard way to represent data from the IT perspective.)
From ANY perspective, I would say ;). PDF is about presentation, NOT content...
We're looking at deploying tools to turn Acrobat forms into metadata and then providing tools to distribute and manage the metadata.
I would recommend you look at the Adobe Form Server as an excellent model - or perhaps even as part of your solution...
I disagree - because javascript is embedded in the form, which is "decoupled" from the web server, PDF is DIFFERENT.
But once the HTML arrives in the user's browser, the JS in there is ALSO "decoupled" from the server! I can bring up an HTML form in a browser, hide the window for a week, come back to it then, and it will NOT have updated. JUST LIKE A PDF!
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.
At the time that user initially gets the HTML, yes. But you can't control what happens when that HTML is actually run. Same is true with PDF. You can place the JavaScript into the PDF on the fly before sending to the user so it's current at delivery time.
The problem that you are trying to solve is being current at "fill in" time - and by default, HTML and PDF (and XForms, and ...) all suffer the same lack of "auto updating".
Yes, but I need technology to corral the loose Acrobat forms and get them into a metadata format first.
And also existing HTML forms into that same "metadata format"...
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
