Introduction

- Introduction -

- Overview -

FOP takes an xml file does its magic and then writes a document to a - stream.

xml -> [FOP] -> document

The document could be pdf, ps etc. or directed to a printer or the - screen. The principle remains the same. The xml document must be in the XSL:FO - format.

For convenience we provide a mechanism to handle XML+XSL as - input.

The xml document is always handled internally as SAX. The SAX events - are used to read the elements, attributes and text data of the FO document. - After the manipulation of the data the renderer writes out the pages in the - appropriate format. It may write as it goes, a page at a time or the whole - document at once. Once finished the document should contain all the data in the - chosen format ready for whatever use.

+ The articles in this section pertain mainly to the redesign or trunk line of development. +The redesign is mainly focusing on parts of the layout process (converting the FO tree into the Area Tree). +Therefore other (non-layout) sections in this document are probably largely accurate for the maintenance branch, but should be used with care in that context. +

+ The Black Box View +

From a user's standpoint, FOP is a black box that an xml file as input, performs some magic, then creates the desired output:

+ + + + + + + + + + + + + + +

FOP from a User's Standpoint
Process	Result
.	XSL-FO document
FOP	Output: PDF, Postscript, Print, etc.

Although this is simple, it is useful in defining the outer limits of FOP's core processing. There may be other things going on under FOP's control that are not really part of FOP. For example, FOP provides a convenience mechanism that takes semantic XML + an XSLT transformation as input, instead of XSL-FO. This is done outside of FOP's core processing (by Xalan), and it is therefore outside the scope of FOP's design, and outside the scope of the FOP design documents.

- Stages -

The fo data goes through a few stages. Each piece - of data will generally go through the process in the same way but some - information may be used a number of times or in a different order. To reduce - memory one stage will start before the previous is completed.

SAX Handler -> FO Tree -> Layout Managers -> Area Tree - -> Render -> document

In the case of rtf, mif etc.
SAX Handler -> FO Tree -> - Structure Renderer -> document

The FO Tree is constructed from the xml document. It is an internal - representation of the xml document and it is like a DOM with some differences. - The Layout Managers use the FO Tree do their layout stuff and create an Area - Tree. The Area Tree is a representation of the final result. It is a - representation of a set of pages containing the text and other graphics. The - Area Tree is then given to a Renderer. The Renderer can read the Area Tree and - convert the information into the render format. For example the PDF Renderer - creates a PDF Document. For each page in the Area Tree the renderer creates a - PDF Page and places the contents of the page into the PDF Page. Once a PDF Page - is complete then it can be written to the output stream.

For the structure documents the Structure listener will read - directly from the FO Tree and create the document. These documents do not need - the layout process or the Area Tree.

Primary Design Goals

A discussion of project design properly begins with a list of the goals of the project. Out of these goals will flow the design issues and details, and eventually, the implementation.

@@ -82,6 +57,57 @@ Performance is therefore an important issue in these real-world applications. To the extent that it can be done so without jeopardizing the primary design goals, FOP developers have identified keeping a small memory footprint as being an important secondary goal.

+ The Big Picture View +

With our design goals outlines, we'll now open the Black Box and look at the major processes inside. +FOP has adopted the basic structure of the XSL-FO standard itself as a convenient model for the major processes in FOP. The Result in each row is the input for the next.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

FOP from a Big Picture Standpoint
Process	Result	Notes
.	XSL-FO document	.
SAX Handler	FO Tree	.
Refinement	Refined FO Tree	.
Layout	Area Tree	Layout and Area Tree are not needed or used for the structural outputs (MIF and RTF), as they are not paginated.
Renderer	Output: PDF, Postscript, Print, etc.	.

In general, each piece of data will go be processed in the same way. +However, some information may be used more than once, and some may be used out of order. +To reduce memory, one process may start before the previous process is completed.

The FO Tree is constructed from the xml document. It is an internal + representation of the xml document and it is like a DOM with some differences. + The Layout Managers use the FO Tree do their layout stuff and create an Area + Tree. The Area Tree is a representation of the final result. It is a + representation of a set of pages containing the text and other graphics. The + Area Tree is then given to a Renderer. The Renderer can read the Area Tree and + convert the information into the render format. For example the PDF Renderer + creates a PDF Document. For each page in the Area Tree the renderer creates a + PDF Page and places the contents of the page into the PDF Page. Once a PDF Page + is complete then it can be written to the output stream.