[Xmlgraphics-fop Wiki] Update of "ExtensionPoints" by JeremiasMaerki

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The following page has been changed by JeremiasMaerki:
http://wiki.apache.org/xmlgraphics-fop/ExtensionPoints

The comment on the change is:
Thoughts and notes on extensions in FOP

New page:
This page describes all extension points inside FOP.

= The Extension Points =

== Additional Renderers ==

Non-standard Renderers can be used by setting FO!UserAgent.setRendererOverride(Renderer).

Future: Renderers will be discovered through the Service class and accessible through their supporting MIME type.

== Additional FO Event Handlers ==

Non-standard FO Event Handlers can be used by setting FO!UserAgent.setFO!EventHandlerOverride(FO!EventHandler).

Future: FO!EventHandlers will be discovered through the Service class and accessible through their supporting MIME type.

== Hyphenation Patterns ==

Compiled hyphenation pattern files will automatically be detected and available if they are in a /hyph directory inside a JAR that's in the classpath.

== Foreign XML Extensions ==

Examples are SVG, MathML, Barcode4J. They define descendants of XMLObj in a special namespace. The foreign XML can be used inside fo:instream-foreign-object elements. The different XML elements supported by the extensions are exposed through an !ExtensionElementMapping descendant which is discovered through the Service class.

Unlike in FOP 0.20.5 the extension cannot directly create areas which paint themselves with help of a renderer anymore. The extension element can only do direct conversions to SVG, for example. The current MathML and Plan extensions are good examples. The generated SVG will be available to the InstreamForeignObjectLM through the XMLObj descendant which then just transfers the DOM Document to an !ForeignObject area (inline-level).

The actual painting/rendering of the foreign XML is handled by an XMLHandler descendant. PDFSVGHandler, for example, knows how to call Batik to paint SVG to the output format. So, instead of converting the foreign XML inside the extension element into SVG, the extension can provide an XMLHandler descendant which knows how to render the foreign XML to the output format with the help of the active renderer. The extension needs to provide one XMLHandler per output format. An example here would be Barcode4J which will be able to paint the barcode XML directly as EPS graphic for the PSRenderer which is much more performant than going through SVG/Batik.

== Functionality Extensions to XSL-FO ==

Through the same basic mechanism as for foreign XML extensions it is possible to specify elements outside the XSL-FO namespace and outside an fo:instream-foreign-object. Until recently the PDF Outline extension used this facility. Now this is done directly through the support of the equivalent XSL 1.1 feature. For FOP Trunk we currently don't have any such extensions as examples. The problem with these extensions is that they are not really dynamically loadable extensions since support for them has to be hard-coded into the FOP source code, especially the FO tree.

= Ideas for the future =

== Extension Attributes on existing FO Elements ==

We might want to support extension attributes for certain FO elements, thus extending the functionality of an existing XSL-FO element. An example could be fo:external-graphic and fo:instream-foreign-object on which we could allow an fox:rendering="as-bitmap" value. This could force the XMLHandler to render the foreign XML in bitmap format instead of rendering it in the native output format.

== Making Extensions really pluggable ==

Ideally, it should be possible to add extensions which don't require a change to FOP's source code. An  example: XSL-FO doesn't provide much in terms of metadata for a document. Metadata could be specified as child of the fo:declarations element. The metadata will not be processed by the layout managers but it would need to be attached to the area tree so a PDF Renderer could take this DOM Document and embed the metadata as XMP (Extensible Metadata Platform) stream in the PDF. A simple-page-master could have a non-FO child which specifies control codes for selecting different paper types in !PostScript.

FOP should make it possible to simply attach these extension elements to the FO tree in a generic way so the LMs can either process them (after all an LM can be replaced to support additional functionality) or simply transfer them into the area tree where they are similarly stored in a generic way, so the renderers can access these DOM Documents to perform some additional task. Since there are not always 1:1 mappings between FO element, layout manager and area tree objects there will be certain restrictions to the overall extensibility, but such a mechanism would greatly improve the ability to plug in additional functionality without changing the FOP source code.

Even validation could be performed if the extension elements can signal under which FO elements they are allowed.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org