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 >
