I programmed PDF form fields into Fop-0.20.1. PDF form fields have an
annotation representation in PDF files with the subtype "widget". So I
patched the external-link within the renderer code to process form fields.
Additionally a PDF fields object had to be added to the PDF stream and a
reference to it into the PDF document catalog. So far quite easy.

>From this experience I see now the design below for PDF plugins (rather
"plugin" than "FOP extension", because this is only partially FOP business).
Main areas of concern are the external interface and on the other hand
general methods provided by FOP to generate valid PDF file structures. When
this API is available, features like PDF JavaScript etc. will be easy to
implement. Plugins are not allowed to modify any FOP code.

XSL:FO will be device-dependent. So users will have to take care of that
with XSLT.

Hansuli Anderegg, Zurich, Switzerland



PDF Form Field Example:

(1)     <fo:instream-foreign-object width="50" height="12">
(2)             <FOPplugin type="PDFForm" renderClass="PDFDocument"
(3)                     /T (pb1)
(3)                     /FT /Btn
(3)                     /Ff 65536
(3)                     /H /P /F 4
(3)                     /BS << /W 2 /S /B >>
(3)                     /MK << /BC [ 0 0 0 ]
(3)                     /BG [.7529 .7529 .7529]
(3)                     /CA (Button) >>

(1) instream-foreign-object asks the FOP formatter for space.


o The foreign-object method of the PDF renderer is called by FOP
        - arguments: type, renderer class, renderer method (Strings from 2) and
rectangle coordinates, data.

o control is passed to the specified class/method in "FOPplugin"
        - arguments: rectangle coordinates and unprocessed text of XML element

(3) Just anything: in my case the text in native PDF form syntax from the
FOPplugin XML element (transforming PDF form syntax into XML syntax does not
make sense unless Adobe switches to XML). XML in case of SVG. Perhaps a
differenciation between XML and non-XML data will be helpful. Of course the
parser requires valid XML input. Character sets and line endings will have
to be looked at.

INVOKED METHOD by PDF renderer foreign object invokes in turn

o special, separate plugin method(s) (most likely added to PDFDocument
        - the plugin has to setup his PDF objects, keep track of his object

FOP has to enable the plugin to insert PDF objects by an API most likely to
be implemented in the PDFDocument class.

GENERAL PDFDocument METHODS provided by FOP

        - request a PDF object (including trailer objects) with ID and XREF
        - add entries/PDF reference ID's to catalog ("outline" requires a catalog
entry too)

Basically this means providing external interfaces to the PDF package. Not
so easy while keeping PDF integrity.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to