I have been working with a trial of Acrobat X Pro and Livecycle ES II, to determine if we can use it effectively to replace paper forms in our workplace. We have also recently deployed Alfresco, an open source CMS, which is very tightly integrated with what we would like to do with Adobe forms. I am a little confused though, at trying to figure out what controls the format of the response.
With the forms I create in liveCycle, when distributed, the response seems to be either a pdf or an xml file. The first few forms I designed arrived on the server as pdf's when I tested them (which is exactly what I wanted). The last couple I have created (using liveCycle) however, seem to always arrive as xml. I have gone through every page of the Distribute... wizard with what I feel is rather a fine toothed comb but cannot find anywhere to control this.
Today I have discovered that Alfresco is unable to parse the form fields in the liveCycle PDF's (this is to do with the Tika parser and PDFBox, but isn't really related to this disccussion directly), so I have switched to Acrobat which, in my testing so far, does create forms parsable by Tika. When I distribute the form from Acrobat though, the responses always seem to be in xfdf format (which seems to boil down to xml anyway).
I am sure that actual PDF's were created at some point. I still have test distribution folders full of pdf responses. Does anyone know what I am missing which controls the response??
Almost all third party products for working with PDF forms are designed for Acroforms, made by Acrobat, rather than XFA forms, made by LiveCycle Designer. You may need to get other Adobe LiveCycle server products to process responses if they are PDF. XML responses are much easier to work with. No, I don't know why they are changing, sorry.
first off, thanks for your response.
Your first point, that third party products generally work better with Acroforms definately makes sense, and confirms my own growing suspicion. So yeah, I think we will go ahead with using Acrobat, rather than LiveCycle (well, that's what a trial is for I suppose, finding which product suits).
I agree, in almost every other scenario I would far prefer to work with xml responses, as a matter of fact, if I were working with XML in this case I would have saved myself a huge amount of time figuring out parsers and the situations in which they will and won't work (because xml is incredibly simple to pull data out of). The problem is that the completed forms are vital to the company for audtiability purposes down the line. Another option I am looking at is generating a static PDF in response to the xml response with the response data in it, however this is a whole 'nuther can of worms I would need to figure out how to start with, and I'd prefer not to (part of this is stubbornness on my part, "The PDF existed on the user's PC! I refuse to take some of the data out of it simply so I can recreate the exact same form somewhere else, it's inefficient and silly!").
A lot depends on what you are wanting to do with the data. In general, the data format (XML or FDF (or XFDF)) allow you to process the data and put in data bases and such without even opening Acrobat. If you want to see the data in PDF, then open Acrobat and import the data into the form under the FORMS>Manage data option. I have not dealt with XFDF data and do not know if it works like FDF. For FDF, there is a full FDF toolkit from Adobe that allows you to manipulate the data files and process them. That might be useful to you as long as you have some programming experience.
You did not indicate if you are collecting data by e-mail (that may be a bit risky if personal or confidential data is included) or by web script. The FDF toolkit also has some web stuff available, though you will probably have to modify it to meet your needs.
The major advantage of Designer forms is the dynamic option that is not part of AcroForms. Other than that, I don't know of big advantage either way. There are other folks in the forms sub-forum that know a lot about both form methods.
I know the data format would be alot more useful if we were just needing to get the data into a database or some other process or application, but the need here is moreso for the actual PDF. This is also required to be an automated process, so importing the data files into acrobat manually is not an option.
When you say are we collecting data by email or web script, I am not 100% sure I understand. When we choose distribute form... there are three choices - collect responses on Acrobat.com, collect responses in my email inbox, and collect choices in our own server. We choose the latter of the three (own server) and specify the CIFS path to a folder on the Alfresco server.
Essentially all I need here is to find out which setting allows me to have pdf's (not xml or fdf or xfdf) collected in the responses folder when the form is distributed using the "own server" option. When I go through the distribute wizard, the only options I set seem to be: How the data is collected (own server), the path to the server, whether or not to collect name and email and the server profile name. (although now I think of it, I believe that originally I was leaving the "collect name and email" checkbox ticked originally when I was seeing actual PDF's collected, so I may try that now. If that's the setting controlling the response format though I would be surprised and find it incredibly unintuitive).
Seriously, if I managed this accidentally the first time I used the program it cannot be that hard. Please, anyone, tell me if and how it is possible to distribute a pdf and have a PDF submitted to the responses folder when the user clicks 'Submit Form'. The fact that the program distinguishes in some way and makes this choice (I can set up two forms with no difference that I know of, one will be returned in XML, the other in xfdf) but has no obvious UI reflection is what I would consider a serious UI fault.
OK, fwiw, posting this here in case it helps someone else.
This became clear once I started trying to workaround the issue. I concluded I could not get Adobe to stably return pdf formats and started looking into how I could use the fdf or http responses to tailor the same result. I was investigating using pdf toolkit to build the PDF once it arrives and realized that as signing details (such as the certificate) are not included with this format it could never work to return signed forms this way. I tried setting up a form with a signature field so that I could see and test the POSTed data, and found - lo and behold - that once signed the form returns as PDF. Obviously this is because this is the format that will preserve all the data (read: signatures) in the form, but the fact that it makes this decision with no reflection anywhere in the UI is incredibly frustrating. We will set up such that all forms have a signature field so that we can expect a pdf response.