"http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd">
<document>
<header>
- <title>Area Tree</title>
- <subtitle>Area Tree Design for FOP</subtitle>
+ <title>FO Design: Area Tree</title>
<authors>
<person name="Keiron Liddle" email="keiron@aftexsw.com"/>
</authors>
</header>
<body>
+ <section id="intro">
+ <title>Introduction</title>
<p>The Area Tree is an internal representation of the result document, representing pages and their contents.
To make the concepts clearer and easier to understand, the code to implement the area tree matches the areas defined in the XSL-FO specification.</p>
<p>The area tree is created by the layout managers once the layout is decided for a page.
The data in the area tree must be minimal and independant.
This means that the data uses less memory and can be serialized to an output stream if needed.</p>
<p>The Area Tree consists of a set of pages, which the actual implemenation places in a set of page sequences.</p>
+ </section>
<section id="structure">
<title>Structure</title>
<p>The area tree is a root element that has a list of page-viewport-areas.
<document>
<header>
- <title>Layout Managers</title>
+ <title>FOP Design: Layout Managers</title>
<subtitle>Break Possibility Proposal</subtitle>
<authors>
<person name="Karen Lease" email="klease@club-internet.fr"/>
</header>
<body>
-<section>
+<section id="intro">
<title>Introduction</title>
<p>
As explained in <link href="layout.html">Layout</link>,
<document>
<header>
- <title>Embedding Design</title>
- <subtitle>Design Approach to FOP</subtitle>
+ <title>FOP Design: Embedding FOP in Other Applications</title>
<authors>
<person name="Keiron Liddle" email="keiron@aftexsw.com"/>
</authors>
</header>
<body>
-<section>
+<section id="intro">
<title>Introduction</title>
<p>
This is the design for the external interface when FOP is to be embedded
<document>
<header>
- <title>FOP Extensions</title>
- <subtitle>Adding extensions to FOP</subtitle>
+ <title>FOP Design: Extensions</title>
<authors>
<person name="Keiron Liddle" email="keiron@aftexsw.com"/>
</authors>
</header>
<body>
-<section>
- <title>Extensions</title>
+<section id="intro">
+ <title>Introduction</title>
<p>
FOP provides an extension mechanism to add extra functionality. There
are a number of different types of extensions that apply to different
steps when converting FO into the rendered output.
</p>
+ </section>
<section>
<title>Extensions</title>
<p>
</section>
- </section>
-
</body>
</document>
<document>
<header>
- <title>Images</title>
+ <title>FOP Design: Images</title>
</header>
<body>
- <section>
- <title>Images in FOP</title>
+ <section id="intro">
+ <title>Introduction</title>
<p>Images may only be needed to be loaded when the image is rendered to the
output or to find the dimensions.<br/>
external graphic in the FO Tree and the image area in the Area Tree only
have the url as a reference.
The images are handled through a static interface in ImageFactory.</p>
+</section>
<section>
<title>Threading</title>
renderer can insert the image into the document and use that data for all
future references of the same image then it can cache the reference in the
renderer and the image can be released from the image cache.</p>
-</section>
</section>
</body>
<document>
<header>
- <title>FOP Optimisations</title>
- <subtitle>Notes for Optimising FOP</subtitle>
+ <title>FOP Design: Optimisations</title>
<authors>
<person name="Keiron Liddle" email="keiron@aftexsw.com"/>
</authors>
</header>
<body>
-<section>
- <title>Process Optimisations</title>
+<section id="intro">
+ <title>Introduction</title>
<p>
FOP should be able to handle very large documents. A document can be
supplied using SAX and the information should be passed entirely through
<document>
<header>
- <title>PDF Library</title>
+ <title>FOP Design: PDF Library</title>
</header>
<body>
-<section>
- <title>PDF Library</title>
+<section id="intro">
+ <title>Introduction</title>
<p>The PDF Library is an independant package of classes in FOP. These class
provide a simple way to construct documents and add the contents. The
classes are found in <code>org.apache.fop.pdf.*</code>.</p>
+</section>
<section>
<title>PDF Document</title>
<p>The are a number of other features for handling pdf markup relevent to creating PDF files for FOP.</p>
</section>
- </section>
-
</body>
</document>
"http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd">
<document>
<header>
- <title>Renderers</title>
- <subtitle>Design of Renderers</subtitle>
+ <title>FO Design: Renderers</title>
<authors>
<person name="Keiron Liddle" email="keiron@aftexsw.com"/>
</authors>
</header>
<body>
- <section id="issue-renderers-responsible">
- <title>Renderers are Responsible</title>
- <p>Each renderer is totally responsible for its output format.</p>
- </section>
- <section id="issue-output-stream">
- <title>Send Output to a Stream</title>
- </section>
<section id="intro">
<title>Introduction</title>
<p>A renderer is primarily designed to convert a given area tree into the output
or reference for when the page is ready to be rendered.The renderer is responsible for managing the
output format and associated data and flow.</p>
</section>
+ <section id="issues">
+ <title>Design Issues</title>
+ <section id="issue-renderers-responsible">
+ <title>Renderers are Responsible</title>
+ <p>Each renderer is totally responsible for its output format.</p>
+ </section>
+ <section id="issue-output-stream">
+ <title>Send Output to a Stream</title>
+ </section>
+ </section>
<section id="fonts">
<title>Fonts</title>
<p>Because font metrics (and therefore layout) are obtained in two different ways depending on the renderer, the renderer actually sets up the fonts being used. The font metrics are used
<document>
<header>
- <title>SVG</title>
+ <title>FOP Design: SVG</title>
</header>
<body>
-<section>
- <title>SVG</title>
+<section id="intro">
+ <title>Introduction</title>
<p>SVG is rendered through Batik.</p><p>The XML from the XSL:FO document
is converted into an SVG DOM with batik. This DOM is then set as the Document
on the Foreign Object area in the Area Tree.</p><p>This DOM is then available to
create the SVG image in the PDF document.</p><p>Most of the work is done in the
PDFGraphics2D class. There are also a few bridges that are plugged into batik
to provide different behaviour for some SVG elements.</p>
+</section>
<section>
<title>Text Drawing</title>
<p>Normally batik converts text into a set of curved
awt canvas using batik.</p><p>The PS Renderer uses a similar technique as the
PDF Renderer.</p><p>The SVG Renderer simply embeds the SVG inside an svg
element.</p>
-</section>
-
</section>
</body>
<document>
<header>
- <title>FO User Agent</title>
- <subtitle>Design of FO User Agent</subtitle>
+ <title>FOP Design: User Agent</title>
<authors>
<person name="Keiron Liddle" email="keiron@aftexsw.com"/>
</authors>
</header>
<body>
-<section>
- <title>Purpose</title>
+<section id="intro">
+ <title>Introduction</title>
<p>
Technically the user agent is FOP in the role of determining the
output format and when resolving various attributes. The user
projects / xmlgraphics-fop.git / commitdiff