Dear Sirs,
For a customer of ours we have implemented a server based system that uses FrameMaker Server 7
to convert FM documents into PDFs with form fields. The form fields are implemented using Postscript
code that uses pdfmark commands. Certain anchored frames are automatically filled with these PostScript frames,
so that they appear as form fields as soon as the fm files are converted to pdf.
The complete PDFs are sent through a LiveCycle Reader Extension Server Version 7
so they can be filled in and signed in Reader 7. After this, many users can access
these Reader-enabled PDFs and fill them in and sign them.
This workflow has been working fine for a long time.
Current Problems
================
In a current project, we are working on migrating the whole solution to work with Reader 9.
Please note: When using the term "LiveCycle ES", we mean only its Reader Extension component.
2. As far as we can see, it is possible to keep on using LiveCycle Reader Extension Server 7
to produce new PDFs to be filled in in Reader 9.
Yet, the customer has a lot of legacy PDFs that have been created using the old system
and that have already been filled in an signed. Such PDFs cannot be used Reader 9 unless
they are sent through LiveCycle Reader Extension Server ES Update 1
Result: We would need to use LiveCycle Server 8 at least to migrate existing pdfs.
2. In order to avoid having two LiveCycles (LC 7 for enabling the newly created PDFs for
first use in Reader9 and LC ES for migrating existing PDFs), we tried to replace LC7 by LC ES.
When we tried to use LiveCycle Reader Extension Server ES not only to migrate existing
PDFs, but also to enable newly created PDFs with form fields for usage in Reader 9,
we found out, that this is not possible:
3. as soon as the PDFs contain form fields the enabling throws the following
error in the JBOSS log file:
...
com.adobe.internal.pdftoolkit.core.exceptions.PDFInvalidDocumentException:
Appearances need to be generated before ubiquitizing the file and the
NeedAppearances flag turned off.
4. We tried several things to make this error disappear:
Please not beforehand:
* The pdfmark postscript code that controls the form fields
are done using a FrameMaker template file that contains a Postscript frame to
be used as a PDF prolog and one postscript frame per form field
* Our prolog had a directive saying "/NeedAppearances true"
Example snipped from our prolog:
[ {aform}
<<
/Fields {afields}
/DR << /Font << /ZaDb {ZaDb} /Helv {Helv} >> >>
/DA (/Helv 12 Tf 0 g )
/NeedAppearances true
>>
/PUT pdfmark
* Our form fields were using the \MK pdfmark to specify colors a.s.o for form fields:
Example pdfmark code for a certain radio button:
[ /T (Radio) % title
/Subtype /Widget
/FT /Btn
/Rect [ 38 0 50 12 ]
/F 4
/Ff 32768
/AP << /N << /O.K. /null >> >>
/MK <<
%
/CA (8) % cross in ZapfDingbar
/BC [ 0 ] % black borders
/BG [ 0.95 ] >> % grey form field
/A << /S /JavaScript /JS (check_FormFields\(this\)) >>
/ANN pdfmark
[ /T (Radio) % title
/Subtype /Widget
/FT /Btn
/Rect [ 113 0 125 12 ]
/F 4
/Ff 32768
/AP << /N << /N.O.K. /null >> >>
/MK <<
%
/CA (8) % cross in ZapfDingbar
/BC [ 0 ] % black borders
/BG [ 0.95 ] >> % grey form field
/A << /S /JavaScript /JS (check_FormFields\(this\)) >>
/ANN pdfmark
[ /T (Radio) % title
/Subtype /Widget
/FT /Btn
/Rect [ 156 0 168 12 ]
/F 4
/Ff 32768
/AP << /N << /N.D. /null >> >>
/MK <<
%
/CA (8) % cross in ZapfDingbar
/BC [ 0 ] % black borders
/BG [ 0.95 ] >> % grey form field
/A << /S /JavaScript /JS (check_FormFields\(this\)) >>
/ANN pdfmark
4.1 When we modified our prolog to contain /NeedAppearances false, the following happened:
* it was possible to enable the pdf for first time use in Reader 9
* the form fields were broken: they were partly invisible and didn´t react correctly any more.
(Example file for a correct file: CASE_Template_weniger.pdf
Example file for a incorrect file: CASE_Template_weniger_anderer_Prolog.pdf)
4.2 When we opened an un-enabled PDF in a proper Acrobat (not Reader) and saved it, the
enabling in LC ES was possible without the error regarding "Appearances" and "NeedAppearances"
This opening-and-saving is very tedious, as the whole production process is supposed to be
a hands-off server operation.
To put it in a nutshell:
1. As soon as we want to use Adobe Reader 9 instead of 7, we need LC ES at least for migrating existing customer PDFs.
2. As soon as we want to replace LC7 with LC ES to avoid using two different LiveCycle versions at the same time,
* we either get correctly looking PDF forms that cannot be enabled for usage in Reader 9
* or PDFs that can be enabled, but are broken, as far as there form fields are concernded
Result: We would need to use one of the following solutions
=======
1. Use two LiveCycle versions: LC7 for enabling newly created PDFs the first time,
LC ES to enable the existing ones
2. Integrate Acrobat into the server production via a plugin that uses it to
open-and-save the pdf files after they have been produced but before they are fed into LC ES
Both would mean additional cost to the customer (license, implementation, hardware).
So our questions are:
=====================
Q1: How is it possible to enable newly created PDFs with LiveCycle ES if they have been produces
using "/NeedAppearances true" without having to open-and-save them in Acrobat?
(e.g by configuring LC ES in a certain way, binding JavaScript action to form fields a.s.o)
Relevance: If this was possible, the customer wouldn´t need to invest money to buy
new licenses, hardware and implementations.
Q2: What would we have to change in our form field descriptions to make correct pdfs
with a "/NeedAppearance false"-prolog?
Relevance: If this was possible, the customer wouldn´t need two LiveCycles.
Q3: Is it possible to have two different LiveCycle versions on the same machine?
Relevance: If this was not possible, a second physical server would be necessary
as soon as two different LiveCycle versions were needed simultaneously.
Q4: Is it possible to remote-control Acrobat using the Acrobat SDK
(or a batch-processing sequence) to open-and-save PDFs?
Relevance: This would be the last resort to avoid having two LiveCycle versions
Many thanks in advance for your answer.
If you can´t answer yourself, please feel free to point us to a feasible source of information.
With kind regards,
Franz Kaufmann
