Apache OpenOffice (AOO) Bugzilla – Issue 73696
Acrobat Reader can't fill and save PDF forms exported from OOo
Last modified: 2013-08-07 14:42:39 UTC
Adobe Acrobat Reader (both version 7 and 8) complains when trying to save a PDF with forms filled, if this PDF comes from an OOo document "export to PDF". As one can read in the following official Adobe information, to make this functionality work you have to right-enable the PDF document: http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=326051 In the "Security" tab of OOo Writer there is an option to "Restrict Permissions" (free translation from the spanish localized version), and if you enter a password here it enables the following options to restrict several actions that people can do with your document: print and resolution, make changes to the PDF, etc. If you choose "fill form fields" in the "changes" section, supposedly you are right-enabling your exported PDF document, and restricting changes so to only allow form filling. Unfortunately, when you open the exported PDF with Acrobat Reader and fill the forms, it still says it cannot save a modified copy of the document. However, if you look at the document properties from Acrobat Reader (Document -> Security -> Show security settings for this document) the information matches what was specified in the OOo PDF export dialogs, including the ability to edit forms. I have used this same version of Adobe Acrobat Reader to fill and save forms previously with no problems. I don't know if the reported problem has to do with Reader being too picky about the document internals, a bad PDF export filter in OOo writer or what, but this prevents OOo full featured forms editor to be used for many kinds of things. Something as normal as a simple recruit form, published in some web page, and sent back once it is filled is something you can not currently do with OOo, and is a pity. You hace to resort to some propietary and expensive and/or Windows only software, or search an alternative path to recruiting.
Any chance of providing sample .pdf and .odt? I would also suggest trying OO 2.1.
I have downloaded and installed OOo 2.1 and repeated the test, and PDF export still fails to generate a document that Acrobat Reader considers "rights-enabled" enough to allow form filling and save of a modified copy. I attach to this issue two files, the first simple_form.odt the OOo Writer source document, and the other, simple_form.pdf, the PDF version after export. The document has a single text box, and a couple of interesting snapshots to show the options chosen for the PDF export filter. Hope it helps.
Created attachment 42361 [details] Test case: source document
Created attachment 42362 [details] Test case: resulting PDF file
Oh my, the second attachment is indeed in PDF format, but I set the mime-type incorrectly, I apologize.
This is not an issue as we use standard PDF forms. From "Beyond Adobe Reader" in Adobe Reader 8: Standard Forms Adobe Reader allows users to fill out standard PDF forms and print them. Data entered cannot be saved directly back into the PDF File. This means that you will not be able to save the form data. I even tried it with an unprotected PDF (exported from your .odt attachment) and it allowed me to save in Preview, but gave the same error message as in the attachment, which is expected. With the attached PDF, Preview (A Mac OS X application) it will not allow a save. In Adobe Reader 8, it is the same as above. I believe this issue should be marked as invalid.
Reassigned to HI.
The fact is, this very same version of Acrobat Reader is indeed able to save filled PDF forms to disk, like for example the PDF samples linked from: http://www.adobe.com/products/server/readerextensions I have tried with the following one, opened with Acrobat Reader 7.0.8.05/22/2006: http://www.adobe.com/products/server/readerextensions/pdfs/incometaxform.pdf You can fill totally or partially the form and save the modified document to disk. As per Adobe information, this is possible because the PDF is rights-enabled. My expectation (don't know if logical or not) is that exported PDF created from OOo worked the same way if exported with a "permission password" set and "allowing filling in form fields". So the real question is, is Reader unable to save modified PDF forms coming from OOo because the export filter has a bug (and should be fixed), or it is unable to save these PDF forms because the export filter was never coded to right-enable the PDF, and so this issue is just a "feature enhancement" (important in my opinion, but an enhancement)?
I'm not sure if this is a defect in Adobe Reader or the OOo export yet. If you download a form from the Adobe LiveCycle web site: http://www.adobe.com/products/server/readerextensions/ you can save data to it using simply Reader. However, another place (http://www.lagcc.cuny.edu/business/Download.htm) says you need Adobe Professional to save the filled form. If you look at the document properties (security tab in Adobe Reader), you will see that the one from OOo and Lagcc have 'not allowed' for 'allow submitting forms' and the one from Adobe LiveCycle say 'allowed' for 'allow submitting forms'. I guess the question is does the PDF spec say how to change that security setting for a PDF so that maybe OOo can add that to its export and allow PDFs generated from OOo to be filled in, saved, and sent back electronically. From what I've heard, LiveCycle costs $100K +. If OOo could do this... Wow!
double to 64064 *** This issue has been marked as a duplicate of 64064 ***
Closing duplicate
With due respect, this issue is by no way a duplicate of issue number 64064. Let me summarize both: * Issue 64064: someone uses to CutePDF (that seems to be unable to create PDF forms), and then uses OOo PDF export, and forms get exported to...exactly, forms. This seems to confuse the user and to solve this misunderstanding OOo developers add an option to not export forms when creating a PDF from OOo (don't know if this options is present in 2.0.4 or 2.1.0). * Issue 73696: someone uses OOo to create PDF forms and get them, but typical applications (Acrobat Reader 7 and 8) can't edit the fields and save a copy to disk. Information from Adobe is not completely clear about whether Reader can do this or not, but some PDF forms (even samples from Adobe) can be edited and saves modified afterwards with Reader 7 and 8. No PDF exported from OOo can be used in this way. So, I don't see the duplication. They are two very different problems, except if the fix for issue 64064 is preventing PDF forms from being exported rights-enabled and editable. In 64064 the user wants to cripple the output PDF, in 73696 we want to feature enable it.
confirm
I'll have a look
IIRC there was an e-mail thread months back discussing about this same issue (without an issuezilla opened at the time). I'll try to search the messages and comment again here, in a few days.
Sorry for the delay. I searched about this problem a few months back when it arose from a thread on the OpenOffice.org user list (http://www.openoffice.org/servlets/BrowseList?list=users&by=thread&from=1407419). At that time I found that the reason why an OpenOffice.org generated PDF form can not be saved by Acrobat Reader depends from Acrobat Reader itself: the reader will save a filled in form only if it finds some undocumented flags and a special signature in the PDF file. This signature, along with other undocumented flags, lurks in /ViewerPreferences dictionary, it appears to be Adobe's only and not part of the PDF specification. It's generated by some Adobe application and understood by Acrobat Reader. From the PDF specification side OOo is all right, I don't know if the above mentioned added signature feature can be implemented in OpenOffice.org code, currently there is lack of publicly available information.
I, too, think that we shouldn't proceed with this then. If Adobe chooses to have some undocumented extensions that is probably undocumented intentionally. If there were some public standard for this, then we should support it, but that does not seem to be the case.
closing
For the record, I've just opened a new issue closely related to this one: https://issues.apache.org/ooo/show_bug.cgi?id=121782 (I preferred to open a new one since the involved programs and formats changed significantly in the last 6 years, and I don't know if Giuseppe's remarks about the undocumented status of the feature still apply).