mirrors
/
fop
kopia lustrzana https://github.com/apache/fop.git


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
							<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<!-- $Id$ -->
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.3//EN" "http://forrest.apache.org/dtd/document-v13.dtd">
<document>
  <header>
    <title>Apache™ FOP Development: Implementation Overview</title>
    <subtitle>Following a Document Through Apache� FOP</subtitle>
    <version>$Revision$</version>
    <authors>
      <person name="Arved Sandstrom" email=""/>
    </authors>
  </header>
  <body>
    <p>The purpose of this document is to tie together the Apache™ FOP design (interface) with some of the key points where control is passed within FOP (implementation), so that developers can quickly find the section of code that is relevant to their needs. The process described is for a "typical" command-line document. All classes are in org.apache.fop unless otherwise designated.</p>
    <section>
      <title>Overview</title>
      <p>The input FO document is sent to the FO tree builder via SAX events. Fragments of an FO Tree are built from this process. As each page-sequence element is completed, it is passed to a layout processor, which in turn converts it into an Area Tree. The Area Tree is then given to the Renderer, which converts it into a stream of data containing the output document. The sections below will provide additional details. Where needed differences between the trunk and maintenance branches are shown in tabular format.</p>
    </section>
    <section>
      <title>Startup</title>
      <ul>
        <li>The job starts in <em>apps.Fop.main()</em>.</li>
        <li>Control is passed to <em>apps.CommandLineStarter.run()</em>.</li>
        <li>Control is passed to <em>apps.Driver.render()</em>. This class fires up a SAX parser, the events from which indirectly control the remaining processing, including building the FO Tree, building the Area Tree, rendering, output and logging.</li>
      </ul>
    </section>
    <section>
      <title>Formatting Object Tree</title>
      <table>
        <tr>
          <th>Trunk</th><th>Maintenance</th>
        </tr>
        <tr>
          <td colspan="2">The SAX events that the parser creates are handled by <em>fo.FOTreeBuilder</em>, which uses <code>startElement()</code>, <code>endElement()</code>, and <code>characters()</code> methods to build the FO Tree.</td>
        </tr>
        <tr>
          <td><code>fo.FOTreeBuilder.endElement()</code> runs the <code>end()</code> method for each node as it is created. The <em>fo.pagination.PageSequence</em> class overrides this <code>end()</code> method to run <code>apps.LayoutHandler.endPageSequence()</code>, which in turn runs <code>fo.pagination.PageSequence.format()</code>.</td>
          <td>the end of a PageSequence element causes the PageSequence object to be passed to <code>apps.StreamRenderer.render()</code>, which in turn runs <code>fo.pagination.PageSequence.format()</code>.</td>
        </tr>
        <tr>
          <td><code>fo.pagination.PageSequence.format()</code> creates a <em>layoutmgr.PageLayoutManager</em>, passing the AreaTree and PageSequence objects to it, then calls its <code>run()</code> method.</td>
          <td><code>fo.pagination.PageSequence.addFlow()</code> programatically adds a Flow object to the page sequence.</td>
        </tr>
        <tr>
          <td>.</td>
          <td><code>fo.pagination.PageSequence.makePage()</code> creates a BodyArea and passes it to <em>fo.Flow.layout</em></td>
        </tr>
        <tr>
          <td>.</td>
          <td>the layout process is then driven from <code>fo.pagination.PageSequence.format()</code>.</td>
        </tr>
      </table>
    </section>
    <section>
      <title>Layout</title>
      <p>There are layout managers for each type of layout decision.
They take an FO Tree as input and build a laid-out Area Tree from it.
The layout process involves finding out where line breaks and page breaks should be made, then creating the areas on the page.
Static areas can then be added for any static regions.
As pages are completed, they are added to the Area Tree.</p>
    </section>
    <section>
      <title>Area Tree</title>
      <p>The area tree is a data structure designed to hold the page areas.
These pages are then filled with the page regions and various areas.
The area tree is used primarily as a minimal structure that can be rendered
by the renderers.</p>
      <p>The area tree is supported by an area tree model. This model
handles the adding of pages to the area tree. It also handles
page sequence starts, document level extensions, id references
and unresolved id areas. This model allows the pages to be handled
directly by a renderer or to store the pages for later use.
</p>
    </section>
    <section>
      <title>Rendering</title>
      <p>
The renderer receives pages from the area tree and renders those pages.
If a renderer supports out of order rendering then it will either
render or prepare a page in the correct order. Otherwise the
pages are rendered in order.
The task of the renderer is to take the pages and output them to
the requested type.
In the case of the AWTRenderer it needs to be able to view any page.
</p>
      <p>
When rendering a page it takes the page and renders each page region.
The main work for a renderer implementation is to handle the viewports
and inline areas. The inline areas need to be drawn on the page in the
correct place.
</p>
    </section>
  </body>
</document>