Interested in working on the integration of jfor into FOP?

You're most welcome, this page gives some background and starting points. --BertrandDelacretaz

Please read this first:


== What is jfor =

Jfor takes XSL-FO documents as input (like FOP) and generates RTF documents as its output.

== Current status of jfor - what will we keep? =

Although heavily used in production and very stable, jfor is fairly limited in its handling of XSL-FO properties (the XSL-FO attributes that define text appearance and formatting options). Many properties are ignored or only partially implemented.

Codewise, jfor mostly consists of a "Converter" that interprets SAX events provided by and XML parser, and uses an "RTFLibrary" written for jfor, that is able to generate RTF documents based on the instructions of the Converter.

Only the RTFLibrary will be used by FOP, the Converter will be replaced by the FOP front-end.

== Why integrate jfor into FOP? =

FOP and jfor have many things in common, mostly at the front-end stages: XML parsing and interpretation of XSL-FO properties. It makes sense to use the same front-end for RTF and PDF generation, although the back-ends are very different.

Compared to jfor as it currently stands, an RTF-enabled FOP should be able to handle many more properties correctly, and improving this property handling will impact both RTF and PDF documents later on.

Also, jfor is currently weak in its handling of nested fo:block and fo:inline elements. Rewriting the front-end (based on FOP) is a good opportunity to improve this. I think moving from a "nested elements" model to a "linear text runs" model for fo:blocks and fo:inlines should help a lot with this.

For RTF documents, no layout computations (line and page breaks, etc.) need to be done, as the layout is done by the wordprocessor when opening the RTF document.

For PDF documents, on the other hand, the layout must be computed down to the smallest details in order to generate pages with all elements in the right places. This is a much more complicated backend than the RTF one.

The { { { StructureHandler } } } concept was introduced in FOP this year to facilitate integration of non-layout based "renderers" into FOP. The RTF renderer based on jfor code will be one of these.

So, in conclusion, it make sense to integrate the RTF generation capabilities of jfor in FOP, mostly to leverage the current FOP front-end for both PDF and RTF formats.

== How can you help? =

Although it already uses the existing jfor RTF library, the RTFHandler in FOP (as of December 2002) recognizes almost no useful XSL-FO constructs. It only shows that the integration is possible but needs to be expanded to produce useful documents.

I (BertrandDelacretaz) am available to help steer this in the (hopefully) right direction so you're not left in the dark.


== The plan =

The plan was to first use jfor in binary form, but now the RTF library of jfor has been donated to FOP and adapted so that basic RTF documents work without needing the jfor jar.

== Where we stand now =

== How to go on =

Here are a few suggestions:

== Testing the RTF generation =

Currently the easiest way to test is as follows:


JforIntegrationInFop (last edited 2009-09-20 23:52:18 by localhost)