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 <peter.hanc...@gmail.com> > 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 <ale.marin...@gmail.com > > 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 >> > >