You're right, after further investigations on the FOP's code it seems
difficult to extend FOP without patching its core. AFAIK the AcroForm
feature requires at least a patch to the PDFRoot object to add the
"/AcroForm" dictionary in the "/Catalog" dictionary.
Regards,
Alessandro
2010/5/11 Peter Hancock
> Hi Alessandro,
>
> First off this is a development discussion and should be moved to fop-dev
> mailing list - if you have not subscribed to this yet I suggest you do for
> further discussion (see http://xmlgraphics.apache.org/fop/maillist.html).
>
> I have been working on an implementation of AcroForms (Following PDF Ref
> 1.4 - FOP's PDF library mostly adheres to this spec).
>
> Before you take on this task alone it would be a good idea if you review my
> progress:
> I am at a fairly early stage although
> * Written draft specification for fox extensions
> * Extended FOP's PDF library (package org.apache.fop.pdf) to include a
> fairly comprehensive set of PDF's acroform elements
> * Implemented a simple text label and pushbutton usecase
>
> I will shortly submit a patch to FOP and put documentation on the FOP wiki.
>
> It would be fantastic to get your thoughts on this and hopefully save you
> independently doing the same thing!
>
> Your approach to develop the extension as a pluggable module is
> theoretically the correct approach, however you may run into problems-
> perhaps insurmountable ones!
> Althougth the FO tree building and the layout/ area tree building stages
> both support pluggable extension in principle, some parts of the system
> currently do not: The rendering of fox extension elements, for example, is
> handled by the core renderers/painters and it does not seem trivial
> (possible?) to delegate at these stages to an external handler.
>
> I see some of the major challenges in developing the right implementation
> including:
> * Defining fox elements that exploit the rich appearances that can be
> prescribed to pdf fields
> * With regards to layout, defining the right bridge between existing fo
> elements and PDF e.g. text labels may behave like fo:inline elements,
> multiline text fields may have the layout behaviour of fo:blocks etc)
> * Externalising the rendering/painting code - perhaps not possible
>
>
> Peter
>
>
> On Mon, May 10, 2010 at 8:14 PM, Alessandro Marino > wrote:
>
>> I'm trying to implement an extension to add AcroForm (§ 8.6 page 671 of
>> PDF Reference 1.7) to a PDF document.
>> Below there are my thoughts about the process of building such extension,
>> could anyone tell me if there's somethig wrong?
>>
>> I have to create a jar and configure an ElementMapping provider adding the
>> file /META-INF/services/org.apache.fop.fo.ElementMapping with the fully
>> qualified classname of my ElementMapping implementation class.
>> The ElementMapping implementation is responsible to provide a "Maker
>> class" that adds an objectified representation of the xsl tag to the FOTree.
>>
>> After the creation of the FOTree the LayoutManagerMapping is initialized
>> inside the AreaTreeHandler. The LayoutManagerMapping holds the association
>> between each FONode and its LM.
>>
>> For the first version of this extension I would prefer (to simplify
>> things) to have a LM that puts an AcroForm field on its own line.
>> How do I configure a LM for these objects?
>> It doesn't seem to exist an extension point for LM, obvious extension
>> points are represented by: ElementMapping, ContentHandlerFactory, Renderer,
>> FOEventHandler, PDFImageHandler, XMLHandler (for which I can configure an
>> implementation class provider in META-INF/services).
>> I saw the LayoutManagerMaker interface that has various methods for
>> creating a LM from a FONode or from another LM.
>> Do I need to add another method to this interface?
>>
>> Then I needs two things to render an AcroForm in PDF:
>>
>> * an array in the catalog dictionary (§ 3.6.1 page 141) that holds all
>> references to each field.
>> Do I need to patch the PDFRoot object to add such array for example
>> with a method "setAcroForm"?
>>
>> * a field dictionary (page 674) for each field
>>
>> Thanks and regards,
>> Alessandro
>>
>
>