I have a problem with my form, when opened with Adobe Reader Version 126.96.36.199 (included) or higher Reader systematically shows the annoying message "This PDF form requires a newer version of Adobe Reader ...".
I work with 3 versions of each form:
1) Dynamic PDF Form XDP: Generated with Adobe Designer ES 8.2, (target version "Acrobat and Adobe Reader 8.0 or later. "
XDP form has no "Warings"
2) PDF Form, generated from the XDP form of point 1), using Adobe LC Forms ES2 "renderXDPForm" method.
3) Flatten PDF, generated from the PDF form, resulting in point 2) value, using Adobe LC Assembler ES2.
I have generated 3 different PDF rendering, changing only the "target version":
a.1 PDFFormRenderSpec.setAcrobatVersion (AcrobatVersion.Acrobat_6): MyForm-ES-AcroVersion6.pdf.
b.1 PDFFormRenderSpec.setAcrobatVersion (AcrobatVersion.Acrobat_7_0_5): MyForm-ES-AcroVersion7.pdf
c.1 PDFFormRenderSpec.setAcrobatVersion (AcrobatVersion.Acrobat_8): MyForm-ES-AcroVersion8.pdf
Of all that I've created a flat version using Assembler:
Attach all forms of work[zip 4 download].
Well ... I tried to open all forms generated (six) with versions of Adobe Reader from 8.1.0 to 10.0.1.434 X and the findings are that the annoying warning message is displayed only with the flattened forms and from version 9.3 .0.148 (included) or higher.
Table of test, where
OK= No message at open.
Err= Message displayed.
I do not understand or just logical that the most current versions (and higher) Reader is precisely this message to appear at what may be due? What's happening?
Why the message is taught only in the flattened forms?
How I can solve this problem?
When you call renderPDFForm, what is the "Acrobat Version" setting (under PDF Options)? Can you change this setting to something lower - like Acrobat and Reader 8.0 and above?
I do not use the method "renderPDFForm" (at least not explicitly), instead use the "renderXDPForm (...)".
I added the XDP form the zip (I forgot): download from here!
And the only parameter that you can tell this method over the "target" of the resulting PDF is "com.adobe.idp.services.PDFFormRenderSpec. "
/* Common to all generated PDF */ com.adobe.idp.services.PDFFormRenderSpec renderSpec= new com.adobe.idp.services.PDFFormRenderSpec(); /* Target version 8 o superior: Usede ONLY to generate "MyForm-ES-AcroVersion8.pdf" */ /* Target version 7.0.5 o superior: Usede ONLY to generate "MyForm-ES-AcroVersion7.pdf" */ /* Target version 6 o superior: Usede ONLY to generate "MyForm-ES-AcroVersion6.pdf" */
/* Common to all generated PDF */
com.adobe.idp.services.PDFFormRenderSpec renderSpec= new com.adobe.idp.services.PDFFormRenderSpec();
/* Target version 8 o superior: Usede ONLY to generate "MyForm-ES-AcroVersion8.pdf" */
/* Target version 7.0.5 o superior: Usede ONLY to generate "MyForm-ES-AcroVersion7.pdf" */
/* Target version 6 o superior: Usede ONLY to generate "MyForm-ES-AcroVersion6.pdf" */
After this, process PDF forms resulting in Assembler.
I do not know if I answered your question.
Okay, I think I see a potential problem;
The renderXDP operation is part of the Content Services samples and is meant to be used as part of the Content Services module. Its actually a small workflow that reads the XDP from the repository, renders it (using renderPDFForm) and then applies reader extensions.
You say that you are taking the result and doing something with Assembler. I'm not sure what you are doing with Assembler, but manipulating the document after reader extensions have been added can result in some weird errors (although its the first time I've seen the one you mention).
It would be better to do the following:
You can either do this in a process and make one API call, or call each operation individually using the API.
Thanks for responding.
Well, I have developed a small workflow based on PDF forms and LiveCycle LC.
The mechanics are as follows:
1 - Designer: Create and XDP forms related to the workflow.
2 - User: Click a link that (server side) generates a request to LC Forms (renderXDPForm, on the fly) and request the PDF form.
/ * Not used ReaderExtensions * /
3 - User: The PDF form is opened in Reader, it completes the form and finally the XML data is sent to servifor (workflow).
/ * The user can reopen the form, your data modifcar ... many times as desired * /
4 - User: When the user has finished filling out the PDF form, it is necessary to show a flat copy (and for this I use Adobe LC Assembler, to flatten PDF forms).
It is a requirement at this point that PDF forms are a simple PDF planes.
The process now I have implemented with two calls:
1. LC Forms (for the PDF form).
2. LC Assembler (for the flat version of the PDF form).
The scheme is the sigueintes:
1) myForm.xdp -> LC Forms.renderXDP ... -> myForm.pdf
2) myForm.pdf -> LC Assembler.invoke ... -> myFlattenForm.pdf
Clarify that by the time I do not use ReaderExtension.
Any other ideas? Why the message is not displayed in Reader 9.1.x or earlier? How is it possible that the message says you need a version higher than the most current available?
Sorry, I think there is some misunderstanding.
The renderXDPForm operation that you are calling is NOT one of the default LiveCycle operations supplied as part of LiveCycle Forms. It is a LiveCycle workflow that comes as a sample with the LiveCycle Content Services module. I really don't recommend using it as part of the use case that you describe because:
I opened the renderXDPForm operation in LC Workbench so you can see what it does:
I'd like to see if you still get the error if you call the renderPDFForm operation instead of the renderXDPForm operation. I have tried using the renderedPDFForm with the XDP you supplied and it works fine for me.
Hello Hodmi, thanks for your time.
Sorry, commenting that in my previous post I was wrong to refer to the method invoked Adobe API LC "renderXDPForm"(it does not exist) and I'm using to render the XDP forms renderPDFForm method (as you comment in the previous post), as follows:
FormsService fs= new FormsServiceServiceLocator().getFormsService();
/* ...setUp params... */
In the previous post, when I referred to "workflow," trying to refer to my application (own development) that manages the interactivity and communication between the user and Adobe LC ES2.
I am not using ReaderExtension or LC Workbench (at least not explicitly).
Also comment that the customer has only licenses for Adobe LC Forms and the integration works by calls via WebServices.
In any case I independently of the process by which I am getting the PDF form, I think the question we should focus on is:
a) We have a PDF form "myPDFForm.pdf" that works perfectly in all versions of Reader.
b) We take "myPDFForms.pdf" and process it with Adobe LC Assembler ES2 for flat (using ddx "NoXFA").
Why is the resulting PDF form (flattening) of processed Assembler in some versions of Reader displays the message above?
Perhaps there is some other way to flatten a PDF form?
You could review the PDF form called MyForm-ES-AcroVersionX-flatten.pdf "I've attached? find any reason that can explain that you see this message? and why only in these particular versions of Reader?
I've looked at the flattened versions of the forms you supplied and I see the same error. I'm not sure why its happening (I'm using the very latest version of Acrobat and Reader).
As an experiment I took the MyForm-ES-AcroVersion8.pdf version of your form and ran it through Assembler with a noXFA operation. The result (attached) didn't have any of the errors you were having.
Here is the DDX I used:
As I said, I'm not sure why your flat file got messed up. The Forms call resulting document looks fine, so my suspicion is that it is something in the flattening operation itself. Is there anything "unusual" in your DDX?
The other thing to consider is that something is corrupting the file between when Forms renders it and Assembler flattens it. Is the MyForm-ES-AcroVersion8 file what gets sent to Assembler, or is there something else that happens to it before Assmebler flattens the file?
Finally we have opened an official Adobe incidence ... after a few weeks we have said is a problem with the Adobe LC ES2 (9.0.0) suite, which is resolved by installing the latest service pack.
We have installed and the problem no longer occurs.