Hi,
I'm interested in using the exportAsFDFStr() method in Acrobat 8 inorder to store form data within a database using ADBC.
This needs to include sinature fields.
If I reopen a form and retrievethe FDF string from the database is there then a way to reapply this to the form (i.e. to populate the fields)?
I've looked through the JavaScript API documentation and cannot find a way to do this.
To put this into context, I need to have a number of test certificates available to users who can fill them in and save one or more instances of the form. The user will fill in the form, sign it and then it needs to be stored. The user could reopen the form data too to complete it at a later date.
I do not want the user to have to choose a location to save form data and therefore want to avoid any methods that require a save to the file system (e.g. exportAsFDF() ). I am also using the database already for other functionality.
Any help greatly appreciated.
Mark Poston
Mekon Ltd.
Passing FDF string back to a PDF form
2008-04-21 04:03:12
My Product Information:
Acrobat Pro 8.1.2, Windows
Acrobat Pro 8.1.2, Windows
2008-04-23 04:00:54
#2
Hi,
Thanks for your reply. I suspected this was the case.
I already have the database doing other things so have that's set up. Users are all on Acrobat Pro 8 on Windows because of the need for the DB.
The solution I have developed actually runs on fullscreen/landscape on tablet PCs. Each tablet is taken out "in the field" and used to follow procedures that are audited in the database. Later each tablet is synchronised with a master system where reports on procedures can be created.
I had considered running a web server on each tablet for submission of forms but am not sure this is a good option for each standalone use. There are 18 in total and I want to avoid any risk that it stops working.
The main issues I have is that Acrobat 8's JavaScript security is too restrictive. I can fully understand it not allowing save activities by default but it would be nice to have them available as privileged functions in folder level JS for purpose built solutions like mine.
The problem with parsing FDF is that I doubt I could parse the digital signatures that will be included. I had also considered using XMLforScript (a JavaScript XML parser with DOM & SAX capabilities) to allow me to parse an XML file with the form data (e.g. XFDF).
My current thinking is to use page templates to create separate instances of a form in the same PDF. I already use this in my solution to allow for users to add amendments to procedures and sign for them. It would have been nice to have the form data saved out though!
Thanks again
Kind regards
Mark Poston
Thanks for your reply. I suspected this was the case.
I already have the database doing other things so have that's set up. Users are all on Acrobat Pro 8 on Windows because of the need for the DB.
The solution I have developed actually runs on fullscreen/landscape on tablet PCs. Each tablet is taken out "in the field" and used to follow procedures that are audited in the database. Later each tablet is synchronised with a master system where reports on procedures can be created.
I had considered running a web server on each tablet for submission of forms but am not sure this is a good option for each standalone use. There are 18 in total and I want to avoid any risk that it stops working.
The main issues I have is that Acrobat 8's JavaScript security is too restrictive. I can fully understand it not allowing save activities by default but it would be nice to have them available as privileged functions in folder level JS for purpose built solutions like mine.
The problem with parsing FDF is that I doubt I could parse the digital signatures that will be included. I had also considered using XMLforScript (a JavaScript XML parser with DOM & SAX capabilities) to allow me to parse an XML file with the form data (e.g. XFDF).
My current thinking is to use page templates to create separate instances of a form in the same PDF. I already use this in my solution to allow for users to add amendments to procedures and sign for them. It would have been nice to have the form data saved out though!
Thanks again
Kind regards
Mark Poston
2008-04-23 09:13:26
#3
Wow, that's quite a setup. Since you have a closed system, you contol all the PCs, and all your users are on Acrobat Pro, you are in luck. The sky is the limit with what you can do in this system.
Your users should have no problems saving filled and signed documents and reading and writing from a DB using ODBC. In fact, you could automate many of these activities from toolbar automation scirpts so you don't have to put code into every document used.
And there are two XML parsers already included in Acrobat JavaScript, not just one. The latest X4E (that you mentioned above), thats in core JS, and the old XMLData object used by LiveCycle. You could very easily store the XFDF, and then reparse and apply it later.
Don't worry about the digital signatures, they don't show up in the data.
Your users should have no problems saving filled and signed documents and reading and writing from a DB using ODBC. In fact, you could automate many of these activities from toolbar automation scirpts so you don't have to put code into every document used.
And there are two XML parsers already included in Acrobat JavaScript, not just one. The latest X4E (that you mentioned above), thats in core JS, and the old XMLData object used by LiveCycle. You could very easily store the XFDF, and then reparse and apply it later.
Don't worry about the digital signatures, they don't show up in the data.
2008-04-23 09:43:01
#4
Thanks again thomp!
This has been a very interesting project that is continually being improved upon.
You'd think the sky was the limit but there are still Acrobat security issues that prevent me from saving data programmatically.
I want to avoid the human error in saving things in the wrong place!!
Because the solution runs in fullscreen on the tablets the toolbars and menus are not visible. Therefore I have been adding all my functionality into the PDFs. My approach to this is to use a batch process to add all of the interactivity and to use handler functions that call folder-level JS. This way I can change the code without changing the PDFs.
Unfortunately, I need the digital signatures!! Therefore, whatever I do need to carry them around too.
Cheers
Mark
This has been a very interesting project that is continually being improved upon.
You'd think the sky was the limit but there are still Acrobat security issues that prevent me from saving data programmatically.
I want to avoid the human error in saving things in the wrong place!!
Because the solution runs in fullscreen on the tablets the toolbars and menus are not visible. Therefore I have been adding all my functionality into the PDFs. My approach to this is to use a batch process to add all of the interactivity and to use handler functions that call folder-level JS. This way I can change the code without changing the PDFs.
Unfortunately, I need the digital signatures!! Therefore, whatever I do need to carry them around too.
Cheers
Mark
2008-04-23 10:15:30
#5
You're approach seems solid, using folder level JS functions to do all the heavy lifting. And instrmenting the docs with a batch process. You could probably use the same batch code on a toolbar button to setup individual documents. Save you some keystrokes if all you are working on is one document.
When the user signs a PDF, they are actually affecting the entire PDF, the signature isn't on the signature field, that's just the UI. The signature is on the entire document. The user's signature is used to create a checksum of all the bytes in the PDF. Then, at a later time, you can validate that it was a particular user that signed it, and validate that nothing has changed since the doc was signed.
Signatures are not in any way like handling good old form data. They are a universe unto themselves. If you want to use signatures then you'd better do some reading. BTW: the vast majority of people that use digital signatures do it incorrectly. They are a very misunderstood feature.
When the user signs a PDF, they are actually affecting the entire PDF, the signature isn't on the signature field, that's just the UI. The signature is on the entire document. The user's signature is used to create a checksum of all the bytes in the PDF. Then, at a later time, you can validate that it was a particular user that signed it, and validate that nothing has changed since the doc was signed.
Signatures are not in any way like handling good old form data. They are a universe unto themselves. If you want to use signatures then you'd better do some reading. BTW: the vast majority of people that use digital signatures do it incorrectly. They are a very misunderstood feature.
2008-04-24 00:38:06
#6
There are two uses of signatures in my solution. The first is as a means of approving changes to the PDF. Each change requires 3 signatures.
A "change" is either the addition, removal or replacement of a step within a procedure; or a change to a bit of text. Whenever a change is made, a template page is spawned in the PDF that describes the change and then has the 3 signatures fields on it. The database keeps a track of the status of each amendment and its signatures so that a user can see what amendments they might need to sign for.
This is ALL done in Acrobat ... I do not mean signing for a change in the source document (FrameMaker in this case) and then signing for that.
The second use of signatures will be for certificates that need signing at various stages in a process. These are more traditional form-based documents that require one or more signatures.
The key to this solution is maintaining an audit trail by way of digi sigs and database event logs in case of a problem.
So in my case signatures are being used to approve things. This means that a document could have many signatures. Although it's only the latest one that is current, by using trusted certificates a user can validate all signatures in the document and thererfore see that all amendments that have been made have been correctly authorised ... thereby maintaining the audit trail that is required.
Thanks very much for this discussion. It's been very useful to confirm my approach!!
Cheers
Mark Poston
A "change" is either the addition, removal or replacement of a step within a procedure; or a change to a bit of text. Whenever a change is made, a template page is spawned in the PDF that describes the change and then has the 3 signatures fields on it. The database keeps a track of the status of each amendment and its signatures so that a user can see what amendments they might need to sign for.
This is ALL done in Acrobat ... I do not mean signing for a change in the source document (FrameMaker in this case) and then signing for that.
The second use of signatures will be for certificates that need signing at various stages in a process. These are more traditional form-based documents that require one or more signatures.
The key to this solution is maintaining an audit trail by way of digi sigs and database event logs in case of a problem.
So in my case signatures are being used to approve things. This means that a document could have many signatures. Although it's only the latest one that is current, by using trusted certificates a user can validate all signatures in the document and thererfore see that all amendments that have been made have been correctly authorised ... thereby maintaining the audit trail that is required.
Thanks very much for this discussion. It's been very useful to confirm my approach!!
Cheers
Mark Poston
But you've got some other problems here. First ADBC is not enabled by default on the user's system. See this technote
http://kb.adobe.com/selfservice/viewContent.do?externalId=333472
Second, you can't create a DB from ADBC in Acrobat. The DB has to already exist and be connected into ODBC. So unless you have control over the user systems this is going to be a very awkward solution.
Third, and most critical, ADBC doesn't work on Reader, or on Macs. This is very narrow functionality. More useful for Developer/Designer automation and interoffice solutions than for the generic end user.
A cleaner solution would be to store the data on a server, and use a server script to set and get the user's form info. Or even better, Reader Enable the form for save.
Thom Parker
The source for PDF Scripting Info
www.pdfscripting.com
Very Important - How to Debug Your Script