You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xmlgraphics.apache.org by bu...@apache.org on 2012/10/24 06:09:13 UTC
svn commit: r835962 [9/14] - in /websites/staging/xmlgraphics/trunk/content:
./ batik/ commons/ fop/ fop/0.95/ fop/1.0/ fop/1.1/ fop/dev/
fop/dev/design/ fop/trunk/
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/areas.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/areas.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/areas.html Wed Oct 24 04:09:09 2012
@@ -330,68 +330,68 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-area-tree">Apache(tm) FOP Design: Area Tree</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-area-tree">Apache™ FOP Design: Area Tree</h1>
<p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h2 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk7wzxhzdk8">Introduction <a id="intro"></a></h2>
<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. Once a completed page is finished it can then be added to the area tree. From that point forward, the area tree model can then handle the new 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>
-<h2 id="structure-wzxhzdk8wzxhzdk9">Structure <a id="structure"></a></h2>
+<h2 id="structure-wzxhzdk9wzxhzdk10">Structure <a id="structure"></a></h2>
<p>The area tree is a root element that has a list of page-viewport-areas. Each page viewport has a page-reference-area which holds the contents of the page. To handle the processing better FOP does not maintain a list at the root level but lets the area tree model handle each page as it is added.</p>
-<h2 id="page-wzxhzdk10wzxhzdk11">Page <a id="page"></a></h2>
+<h2 id="page-wzxhzdk11wzxhzdk12">Page <a id="page"></a></h2>
<p>A page consists of a page+viewport pair.</p>
<p>The PageViewPort and Page with the regions is created by the LayoutMasterSet. The contents are then placed by the layout managers. Once the layout of a page is complete then it is added to the Area Tree.</p>
<p>Inside the page is a set of RegionViewport+Region pairs for each region on the page.</p>
<p>A page is made up of five area regions. These are before, start, body, end and after. Each region has a viewport and contains the areas produced from the children in the FO object heirarchy.</p>
<p>For the body area there are more subdivisions for before floats, footnotes and the main reference area. The main reference area is made from span areas which have normal flow reference areas as children. The flow areas are then created inside these normal flow reference areas.</p>
<p>Since the layout is done inside a page, the page is created from the pagemaster with all the appropriate areas. The layout manager then uses the page to add areas into the normal flow reference areas and floats and footnotes. After adding the areas for the body region then the other regions can be done layed out and added.</p>
-<h2 id="block-areas-wzxhzdk12wzxhzdk13">Block Areas <a id="block"></a></h2>
+<h2 id="block-areas-wzxhzdk13wzxhzdk14">Block Areas <a id="block"></a></h2>
<p>Block level areas contain either other blocks or line areas (which is a special block area).</p>
<p>A block is either positoned or stacked with other block areas.</p>
<p>Block areas are created and/or returned by all top level elements in the flow. The spacing between block areas is handled by an empty block area. A block area is stacked with other block areas in a particular direction, it has a size and it contains line areas made from a group of inline areas and/or block areas.</p>
-<h2 id="line-areas-wzxhzdk14wzxhzdk15">Line Areas <a id="line-area"></a></h2>
+<h2 id="line-areas-wzxhzdk15wzxhzdk16">Line Areas <a id="line-area"></a></h2>
<p>A line areas is simply a collection of inline areas that are stacked in the inline progression direction. A line area has a height and a start position. The line area is rendered by handling each inline area.</p>
<p>A line area gets a set of inline areas added until complete then it is justified and vertically alignedi when adding the areas. If the line area contains unresolved areas then there will be a line resolver that retains the justification information until all areas in the line are resolved.</p>
-<h2 id="inline-areas-wzxhzdk16wzxhzdk17">Inline Areas <a id="inline"></a></h2>
+<h2 id="inline-areas-wzxhzdk17wzxhzdk18">Inline Areas <a id="inline"></a></h2>
<p>There are a few different types of inline areas. All inline areas have a height and width.</p>
<p>Unresolved areas can reserve some space to allow for possible sizes once it is resolved. Then the line can be re-justified and finalised.</p>
<p>Inline areas are stacked in a line area. Inline areas are objects such as character, viewport, inline-container, leader and space. A special inline area Word is also used for a group of consecutive characters.</p>
<p>The image and instream foreign object areas are placed inside a viewport. The leader (with use content) and unresolved page number areas are resolved to other inline areas.</p>
<p>Once a LineArea is filled with inline areas then the inline areas need to be aligned and adjusted to fill the line properly.</p>
-<h2 id="repeated-areas-wzxhzdk18wzxhzdk19">Repeated Areas <a id="repeated-area"></a></h2>
+<h2 id="repeated-areas-wzxhzdk19wzxhzdk20">Repeated Areas <a id="repeated-area"></a></h2>
<p>There are cases where the same subtree could be repeated in the area tree. These areas will be returned by the same layout managers. So it is possible to put a flag on the created areas so that the subtree data can be cached in the output. Examples of this are: static areas, table header/footer, svg.</p>
-<h2 id="traits-wzxhzdk20wzxhzdk21">Traits <a id="traits"></a></h2>
+<h2 id="traits-wzxhzdk21wzxhzdk22">Traits <a id="traits"></a></h2>
<p>A trait is information associated with an area. This could be information such as text colour or is-first.</p>
<p>Traits provide information about an area. The traits are derived from properties on the formatting object or are generated during the layout process. Many of the layout traits do not have actual values but can be derived from the Area Tree. Other traits that apply when rendering the areas are set on the area. Since setting the same value on every area would use a lot of memory then the traits are derived from default or parent values.</p>
<p>A dominant trait on a block area is set, for example font colour, so that every line area with the same dominant value can derive it. The text inline areas then get the font colour set on the inline area or from the line area or from the block area.</p>
-<h2 id="classes-wzxhzdk22wzxhzdk23">Classes <a id="classes"></a></h2>
+<h2 id="classes-wzxhzdk23wzxhzdk24">Classes <a id="classes"></a></h2>
<p>The following class structure will be used to represent the area tree.</p>
-<h3 id="page-area-classes-wzxhzdk24wzxhzdk25">Page Area Classes # <a id="classes-page"></a></h3>
+<h3 id="page-area-classes-wzxhzdk25wzxhzdk26">Page Area Classes # <a id="classes-page"></a></h3>
<p>The page area classes hold the top level layout of a page. The areas are created by the page master and should be ready to have flow areas added.</p>
-<h3 id="block-area-classes-wzxhzdk26wzxhzdk27">Block Area Classes # <a id="classes-block"></a></h3>
+<h3 id="block-area-classes-wzxhzdk27wzxhzdk28">Block Area Classes # <a id="classes-block"></a></h3>
<p>The block areas hold other block areas and/or line areas. The child areas are stacked in a particular direction.</p>
<p>Areas for tables, lists and block container have their child block areas stacked in different ways. These areas a placed with an absolute positioning. The absolute positioning is where the blocks are placed with an offset from the parent reference area.</p>
-<h3 id="inline-area-classes-wzxhzdk28wzxhzdk29">Inline Area Classes # <a id="classes-inline"></a></h3>
+<h3 id="inline-area-classes-wzxhzdk29wzxhzdk30">Inline Area Classes # <a id="classes-inline"></a></h3>
<p>The inline areas are used to make up a line area. An inline area typically has a height, width and some content. The inline area is offset from the baseline of the current line area. The content of the inline area can be other inline areas or a simple atomic object.</p>
-<h2 id="forward-references-wzxhzdk30wzxhzdk31">Forward References <a id="forward-references"></a></h2>
+<h2 id="forward-references-wzxhzdk31wzxhzdk32">Forward References <a id="forward-references"></a></h2>
<p>The Area Tree maintains a set of mappings from the reference to pages.</p>
<p>The PageViewPort holds the list of forward references that need resolving so that if a references is resolved during layout the page can be easily found and then fixed. Once all the forward references are resolved then the page is ready to be rendered.</p>
<p>To layout a page any areas that cannot be resolved need to reserve space. Once the inline area is resolved then the complete line should be adjusted to accomodate any change in space used by the area.</p>
-<h2 id="caching-wzxhzdk32wzxhzdk33">Caching <a id="caching"></a></h2>
+<h2 id="caching-wzxhzdk33wzxhzdk34">Caching <a id="caching"></a></h2>
<p>We may need to cache pages due to forward references or when keeping all pages.</p>
<p>This is done by serializing the Page. The PageViewport is retained to be used as a key for page references and backward references. The Page is serialized to an object stream and then all of the page contents are released. The Page is then recoved by reading from the object stream.</p>
<p>The PageViewport retains information about id areas for easy access.</p>
-<h2 id="extensions-wzxhzdk34wzxhzdk35">Extensions <a id="extensions"></a></h2>
+<h2 id="extensions-wzxhzdk35wzxhzdk36">Extensions <a id="extensions"></a></h2>
<p>The Area Tree holds the Output Document extensions. This is information such as pdf bookmarks or other output document specific information that is not handled by XSL:FO.</p>
<p>It is also possible to create custom areas that extend a normal area. The actual data that is rendered could be set in a different way or depend on resolving a forward reference.</p>
-<h2 id="area-tree-handlers-wzxhzdk36wzxhzdk37">Area Tree Handlers <a id="handlers"></a></h2>
+<h2 id="area-tree-handlers-wzxhzdk37wzxhzdk38">Area Tree Handlers <a id="handlers"></a></h2>
<p>To handle different situations the handler for the Area Tree handles each page as it is added.</p>
<p>The RenderPagesModel sends the page directly to the renderer if the page is ready to be rendered. Once a page is rendered it is discarded. The StorePagesModel stores all the pages so that any page can be later accessed.</p>
<p>The Area Tree retains the concept of page sequences (this is not in the area tree in the spec) so that this information can be passed to the renderer. This is useful for setting the title and organising the groups of page sequences.</p>
-<h2 id="status-wzxhzdk38wzxhzdk39">Status <a id="status"></a></h2>
-<h3 id="to-do-wzxhzdk40wzxhzdk41">To Do # <a id="status-todo"></a></h3>
-<h3 id="work-in-progress-wzxhzdk42wzxhzdk43">Work in Progress # <a id="status-wip"></a></h3>
-<h3 id="completed-wzxhzdk44wzxhzdk45">Completed # <a id="status-complete"></a></h3>
+<h2 id="status-wzxhzdk39wzxhzdk40">Status <a id="status"></a></h2>
+<h3 id="to-do-wzxhzdk41wzxhzdk42">To Do # <a id="status-todo"></a></h3>
+<h3 id="work-in-progress-wzxhzdk43wzxhzdk44">Work in Progress # <a id="status-wip"></a></h3>
+<h3 id="completed-wzxhzdk45wzxhzdk46">Completed # <a id="status-complete"></a></h3>
<ul>
<li>
<p>new area tree model</p>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/breakpos.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/breakpos.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/breakpos.html Wed Oct 24 04:09:09 2012
@@ -330,16 +330,16 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-layout-managers">Apache(tm) FOP Design: Layout Managers</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-layout-managers">Apache™ FOP Design: Layout Managers</h1>
<p><subtitle>Break Possibility Proposal</subtitle><version>$Revision: 1298724 $</version><authors><person email="klease@club-internet.fr" name="Karen Lease"></person></authors></p>
-<h2 id="introduction-wzxhzdk8wzxhzdk9">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk9wzxhzdk10">Introduction <a id="intro"></a></h2>
<p>As explained in <a href="layout.html">Layout</a> , the hierarchy of Layout Managers is responsible for building and placing areas. Each Layout Manager is responsible for creating and filling areas of a particular type, either inline or block. This document explains one potential algorithm for this process. It is based on the the generation of <em>break possibilities</em> (BP for short). The Layout Managers (LM for short), will generate one or more BP and choose the best one. The BP is then used to generate the corresponding areas.</p>
-<h2 id="anatomy-of-a-break-possibility-wzxhzdk10wzxhzdk11">Anatomy of a Break Possibility <a id="Anatomy+of+a+Break+Possibility"></a></h2>
+<h2 id="anatomy-of-a-break-possibility-wzxhzdk11wzxhzdk12">Anatomy of a Break Possibility <a id="Anatomy+of+a+Break+Possibility"></a></h2>
<p>A break possibility is represented by the BreakPoss class. A BreakPoss contains size information in the stacking direction and in the non-stacking direction (at least for inline areas, it must have both). Flags indicating various conditions (ISFIRST, ISLAST, CAN_BREAK_AFTER, FORCE_BREAK_AFTER, ANCHORS etc). A BreakPoss contains a reference to the top-level LayoutManager which generated it.</p>
<p>A BreakPoss contains an object implementing the BreakPoss.Position interface. This object is specific to the layout manager which created the BreakPoss. It should indicate where the break occurs and allow the LM to create an area corresponding to the BP. A higher level LM Position must somehow reference or wrap the Position returned by its child LM in its BreakPoss object. The layout manager modifies the flags and dimension information in the BP to reflect its own requirements. For example an inline FO layout manager might add space-start, space-end, border and padding values to the stacking or non-stacking dimensions. It might also modify the flags based its on keep properties.</p>
-<h2 id="turning-break-possibilities-into-areas-wzxhzdk12wzxhzdk13">Turning Break Possibilities into Areas <a id="Turning+Break+Possibilities+into+Areas"></a></h2>
+<h2 id="turning-break-possibilities-into-areas-wzxhzdk13wzxhzdk14">Turning Break Possibilities into Areas <a id="Turning+Break+Possibilities+into+Areas"></a></h2>
<p>Once break possibilities have been generated, the galley-level layout manager selects the best one and passes it back to the LayoutManager which generated it to create the area. A LayoutManager is responsible for storing enough information in its Position objects to be able to create the corresponding areas.</p>
-<h2 id="a-walk-through-wzxhzdk14wzxhzdk15">A walk-through <a id="A+walk-through"></a></h2>
+<h2 id="a-walk-through-wzxhzdk15wzxhzdk16">A walk-through <a id="A+walk-through"></a></h2>
<p>Layout Managers are created from the top down. First the page sequence creates a PageLM and a FlowLM. The PageLM will manage finding the right page model (with help from the PageSequenceMaster) and managing the balancing act between before-floats, footnotes and the normal text flow. The FlowLM will manage the normal content in the main flow. We can think of it as a <em>galley</em> manager.</p>
<p>In general, each LM asks its child LMs to return sucessive break possibilities. It passes some information to the child in a flags object and it gets back a break possibility which contains the size in the stacking direction as well as information about such things as anchors, break conditions and span conditions which can change the reference area environment. This process continues down to the lowest level of the layout manager hierarchy which corresponds to atomic inline-level FOs such as characters or graphics.</p>
<p>Each layout manager will repeatedly call getNextBreakPoss on its current child LM until the child returns a BP with the ISLAST flag set. Then the layout manager moves on to its next child LM (ie, it asks the next child FO to generate a layout manager.) Galley level layout managers which are Line and Flow will return to their parent layout managers either when they have finished their content or when they encounter a a BP which will fill one of their areas.</p>
@@ -356,17 +356,17 @@ So the Line LM will ask its child LM(s)
<p>Obviously there is more complicated logic involved when dealing with lists and tables. These cases need to be walked through in detail.</p>
<p>The FlowLM sees if the returned stacking dimension will still fit in its available block-progression-dimension (BPD). It repeatedly calls getNextBreakPoss on its child LMs until it reaches the maximum BPD for the flow reference area or until there is no more content to lay out. If one child LM is finished, it moves on to the next until the last child LM has returned a BP with the ISLAST flag set. If any child LM returns a BP with a FORCE_BREAK_BEFORE or SPAN flag set, the FlowLM will force layout of any pending break possibilities and return to its parent (the PageLM) in order to handle the break or span condition.</p>
<p>If the returned BP has any new before-float or footnote anchors in it (ANCHOR flag in the BP), the FlowLM will also return to the PageLM. The PageLM must then try to find space to place the floats, possibly asking the FlowLM for help if the body contains multiple columns.</p>
-<h2 id="some-issues-wzxhzdk16wzxhzdk17">Some issues <a id="Some+issues"></a></h2>
+<h2 id="some-issues-wzxhzdk17wzxhzdk18">Some issues <a id="Some+issues"></a></h2>
<p>Following are a few remarks on specific issues.</p>
-<h3 id="where-line-layout-managers-are-created-wzxhzdk18wzxhzdk19">Where Line Layout Managers are created # <a id="Where+Line+Layout+Managers+are+created"></a></h3>
+<h3 id="where-line-layout-managers-are-created-wzxhzdk19wzxhzdk20">Where Line Layout Managers are created # <a id="Where+Line+Layout+Managers+are+created"></a></h3>
<p>If the first child FO in a block FO is an inline-level FO such as text, the block LM creates an intermediate level LineLM to layout the sequence of inline content into Lines. Note that the whole sequence of inline FOs is managed by a single instance of LineLM. The LineLM becomes the parent to the various inline-level LM created by each individual inline FO. Since an fo:block can have both block and inline content, its LM may create a sequence of intermixed BlockLM and LineLM.</p>
-<h3 id="getting-the-reference-ipd-wzxhzdk20wzxhzdk21">Getting the reference IPD # <a id="getRefIPD"></a></h3>
+<h3 id="getting-the-reference-ipd-wzxhzdk21wzxhzdk22">Getting the reference IPD # <a id="getRefIPD"></a></h3>
<p>When the layout process starts, with the FlowLM asking its first child LM for a break possibility, the IPD isn't known, since we don't know whether the first FO might be spanning, or on which page it might start. (Of course, if all page masters in the sequence have the same region-body IPD and all have only a single column, the IPD will never change and could already be calculated before starting layout.) The FlowLM gets its first child LM and calls its getNextBreakPoss method. That is a child LM for some block-level FO. For now, suppose it's an fo:block. The BlockLM will create its first child LM, which may be another block-level LM in the case of nested blocks or a LineLM as explained above. (Question: do we need a START flag for layout status?)</p>
<p>We keep calling getNextBreakPoss on lower level layout managers until we get down to the inline level or to a level which cannot have break-before properties, such as a list-item-label. At that point, we assume we are going to have to layout some actual content. But we can't do that yet since we don't know the inline-progression-dimension. So we return a BP object which has 0 size in the stacking dimension, but which has flags set to signal to higher-level layout managers what needs to be done. If it has a break-before property or a span property, it stores these in the BP. If no reference IPD is yet defined, it sets a flag to get that. It then returns to its parent. The parent LM will inspect the BP object returned. In general, it "wraps" it with information about its own needs. If the returned BP is not actually returning any potential areas, the LM can still add information about its own break or span requirements. This return path continues back up to the PageLM. It w
ill then check break and span requirements and create a new page if necessary using the appropriate page-master. At that point, the reference IPD for the main flow is known and is set in the flags object used for the next getNextBreakPoss call to the lower level LM.</p>
<p>Using this information, the BlockLM parent can now calculate the available IPD for its LineLM child, based on its indents. (If there are any side-floats information about the intrusion must be passed down by the FlowLM to lower level managers.) The LineLM can now generate a series of BreakPoss objects, which it passes back to its parent LM.</p>
-<h3 id="hyphenation-wzxhzdk22wzxhzdk23">Hyphenation # <a id="Hyphenation"></a></h3>
+<h3 id="hyphenation-wzxhzdk23wzxhzdk24">Hyphenation # <a id="Hyphenation"></a></h3>
<p>The LineLM is responsible for initiating hyphenation if it is allowed by the properties and if no satisfactory BP can be found without hyphenating. The hyphenation manager is passed two break possibilities, one whose IPD is less than the desired line area IPD and one whose IPD is greater. These break possibilities might have been generated by different inline-level layout managers (text + a wrapper with a color change for example), though frequently they represent two positions in a single text run. If hyphenation is successful, a new BP is returned. The LineLM may look for several intermediate BP based on the "cost" of the returned possibilities. If no intermediate BP is found, the line will be "short", the white-space stretch will be exceeded, or perhaps the content will be overflowed or clipped, depending on various property settings.</p>
-<h3 id="optimizing-wzxhzdk24wzxhzdk25">Optimizing # <a id="Optimizing"></a></h3>
+<h3 id="optimizing-wzxhzdk25wzxhzdk26">Optimizing # <a id="Optimizing"></a></h3>
<p>It obviously seems inefficient to go down to the lowest level LM and back up to the FlowLM for every possible line-break decision. It seems like it would be possible to optimize by letting the lower level layout managers run until they had exceeded the current limit in the stacking direction. They would then return control to the "galley" level (LineLM or FlowLM) which would fine-tune the break decision by asking the lower level LM to find a previous BP which would fit. At the inline level, this means hyphenation as described above.</p>
<p>Another interesting question is at what point pending break possibilities can be turned into areas.The idea is to wait until we are sure we won't have to redo the breaking. This depends on the sophistication of the layout strategy. For example, if a linebreak can be considered final if the line is full and there are no anchors on the line, we could create the LineArea at that point. But if we are willing to change a previous line-end decision to get a better overall composition of a whole group of lines (to prevent multiple hyphens for example), we might wait until the LineLM had finished laying out all its material and then make all the Lines at once.</p></div>
</div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/embedding.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/embedding.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/embedding.html Wed Oct 24 04:09:09 2012
@@ -330,13 +330,13 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-embedding-apache-fop-in-other-applications">Apache(tm) FOP Design: Embedding Apache� FOP in Other Applications</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-embedding-apache-fop-in-other-applications">Apache™ FOP Design: Embedding Apache� FOP in Other Applications</h1>
<p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h2 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk7wzxhzdk8">Introduction <a id="intro"></a></h2>
<p>This is the design for the external interface when Apache™ FOP is to be embedded inside another java application.</p>
<p>Common places where FOP is embedded is in a report production application of a server side application such as<jump href="http://xml.apache.org/cocoon/index.html">Cocoon</jump>.</p>
-<h2 id="settings-wzxhzdk11wzxhzdk12">Settings <a id="Settings"></a></h2>
-<h3 id="user-agent-wzxhzdk13wzxhzdk14">User Agent # <a id="User+Agent"></a></h3>
+<h2 id="settings-wzxhzdk12wzxhzdk13">Settings <a id="Settings"></a></h2>
+<h3 id="user-agent-wzxhzdk14wzxhzdk15">User Agent # <a id="User+Agent"></a></h3>
<p>Possible meanings for a user agent:</p>
<ul>
<li>
@@ -350,7 +350,7 @@ $(document).ready(function () {
</li>
</ul>
<p>The user agent is responsible for supplying user or context specific information. The list of user agent values can be found on the<jump href="useragent.html">User Agent</jump>page.</p>
-<h3 id="logging-wzxhzdk17wzxhzdk18">Logging # <a id="Logging"></a></h3>
+<h3 id="logging-wzxhzdk18wzxhzdk19">Logging # <a id="Logging"></a></h3>
<ul>
<li>
<p>logging level</p>
@@ -365,7 +365,7 @@ $(document).ready(function () {
<p>Logging setup (LogKit, Log4J, JDK14Logging)</p>
</li>
</ul>
-<h3 id="xml-input-wzxhzdk19wzxhzdk20">XML input # <a id="XML+input"></a></h3>
+<h3 id="xml-input-wzxhzdk20wzxhzdk21">XML input # <a id="XML+input"></a></h3>
<ul>
<li>
<p>various ways to supply FOP with the xsl:fo file, fo, xml+xsl</p>
@@ -374,7 +374,7 @@ $(document).ready(function () {
<p>sax handler</p>
</li>
</ul>
-<h3 id="general-options-wzxhzdk21wzxhzdk22">general options # <a id="general+options"></a></h3>
+<h3 id="general-options-wzxhzdk22wzxhzdk23">general options # <a id="general+options"></a></h3>
<ul>
<li>
<p>base url</p>
@@ -386,7 +386,7 @@ $(document).ready(function () {
<p>which implementation of a particular LayoutManager to use</p>
</li>
</ul>
-<h3 id="rendering-options-wzxhzdk23wzxhzdk24">Rendering Options # <a id="Rendering+Options"></a></h3>
+<h3 id="rendering-options-wzxhzdk24wzxhzdk25">Rendering Options # <a id="Rendering+Options"></a></h3>
<ul>
<li>
<p>embedding fonts</p>
@@ -410,7 +410,7 @@ $(document).ready(function () {
<p>binary/ascii switch</p>
</li>
</ul>
-<h3 id="render-results-wzxhzdk25wzxhzdk26">Render Results # <a id="Render+Results"></a></h3>
+<h3 id="render-results-wzxhzdk26wzxhzdk27">Render Results # <a id="Render+Results"></a></h3>
<p>Generate Output statistics from FOP:</p>
<ul>
<li>
@@ -426,9 +426,9 @@ $(document).ready(function () {
<p>recoverable errors such as overflow</p>
</li>
</ul>
-<h3 id="setting-up-wzxhzdk27wzxhzdk28">Setting Up # <a id="Setting+Up"></a></h3>
+<h3 id="setting-up-wzxhzdk28wzxhzdk29">Setting Up # <a id="Setting+Up"></a></h3>
<p>The Driver handles the XML input. The user agent information is through the FOUserAgent. Handle logging through the user agent. Options could also be handled through the user agent, using mime type selection for renderer options.</p>
-<h3 id="others-wzxhzdk29wzxhzdk30">Others # <a id="Others"></a></h3>
+<h3 id="others-wzxhzdk30wzxhzdk31">Others # <a id="Others"></a></h3>
<p>Render to more than one renderer at once (maybe not from the command line). For example you could generate a PDF for the archive and the PS for the printer in one run. It would probably be faster than converting the PDF to PostScript afterwards. Make the fo tree reuseable. If the fonts are the same then use the same area tree to output to different renderers.</p>
<p>Several code pieces for resolving URLs and/or file locations are scattered all over FOP and Batik. These should be replaced with an URIResolver invocation to unify behaviour and remove redundancies.</p></div>
</div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/extending.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/extending.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/extending.html Wed Oct 24 04:09:09 2012
@@ -330,11 +330,11 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-extensions">Apache(tm) FOP Design: Extensions</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-extensions">Apache™ FOP Design: Extensions</h1>
<p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h2 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk7wzxhzdk8">Introduction <a id="intro"></a></h2>
<p>Apache™ 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>
-<h2 id="extensions-wzxhzdk9wzxhzdk10">Extensions <a id="Extensions"></a></h2>
+<h2 id="extensions-wzxhzdk10wzxhzdk11">Extensions <a id="Extensions"></a></h2>
<p>SVG Graphic - This applies to svg and any other xml document that can be converted into svg in the output. All that is required is the element mapping for the xml and a converter that changes the document into svg. This conversion is done in the FO Tree. The conversion is done by the top level element of the namespace or in the case of an external image a Converter.</p>
<p>XML Document - Instead of converting the document into svg it can be passed directly to the renderer. The renderer will need to have a handler for the xml document. This handler can add information directly to the output document.</p>
<p>Output Document - This is used to add document level information to the output result. Such an extension will set information that is passed to the output document. The area tree handles these extensions and passs along the information to the renderer. The extension may contain resolveable objects. The extension can be passed to the renderer once resolve either immediately, after the next page or at the end of the document. This is so that the extension can be handled according to other associated data.</p>
@@ -348,7 +348,7 @@ $(document).ready(function () {
<p>Separate page number display for a subsection. ie. - master document is page 4 of 7, but subsection is page 2 of 3.</p>
</li>
</ul>
-<h2 id="examples-wzxhzdk11wzxhzdk12">Examples <a id="Examples"></a></h2>
+<h2 id="examples-wzxhzdk12wzxhzdk13">Examples <a id="Examples"></a></h2>
<p>Plan - The plan extension is a simple SVG graphic extension. Given a plan document either inside an InstreamForeignObject or as an external graphic, it converts the plan document into an svg graphic. The svg graphic is then passed through the Area Tree to the Renderer. The Renderer then renders the svg graphic as normal.</p>
<p>PDF Outline - This is output document extension. If rendering to pdf and this extensionis used then the bookmark information is passed to the pdf document. This information is then set on the document.</p>
<p>PDF Additions - This can be done with an XML Document extension. A simple xml document is defined that provides the appropriate information. When the document is rendered a handler converts the document into PDF markup.</p>
@@ -363,9 +363,9 @@ to result in a text box referencing the
<blockquote>
<blockquote></blockquote>
</blockquote>
-<h1 id="status-wzxhzdk15wzxhzdk16">Status <a id="status"></a></h1>
-<h3 id="to-do-wzxhzdk17wzxhzdk18">To Do # <a id="status-todo"></a></h3>
-<h3 id="work-in-progress-wzxhzdk19wzxhzdk20">Work In Progress # <a id="status-wip"></a></h3>
+<h1 id="status-wzxhzdk16wzxhzdk17">Status <a id="status"></a></h1>
+<h3 id="to-do-wzxhzdk18wzxhzdk19">To Do # <a id="status-todo"></a></h3>
+<h3 id="work-in-progress-wzxhzdk20wzxhzdk21">Work In Progress # <a id="status-wip"></a></h3>
<ul>
<li>
<p>mathml extension</p>
@@ -377,7 +377,7 @@ to result in a text box referencing the
<p>svg text normal text if that can be handled otherwise stroked this is done automatically</p>
</li>
</ul>
-<h3 id="completed-wzxhzdk21wzxhzdk22">Completed # <a id="status-complete"></a></h3>
+<h3 id="completed-wzxhzdk22wzxhzdk23">Completed # <a id="status-complete"></a></h3>
<ul>
<li>
<p>svg now in an xml handler, FOP can be used without batik</p>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/fotree.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/fotree.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/fotree.html Wed Oct 24 04:09:09 2012
@@ -330,11 +330,11 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-fo-tree">Apache(tm) FOP Design: FO Tree</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-fo-tree">Apache™ FOP Design: FO Tree</h1>
<p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h2 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk7wzxhzdk8">Introduction <a id="intro"></a></h2>
<p>The FO Tree is an internal hierarchical representation (java objects and properties) of the input XSL-FO document, and is created from the <a href="parsing.html">parsing</a> of that XSL-FO document. The process of building the FO Tree corresponds to the <strong>Objectify</strong> step in the XSL-FO spec. The FO Tree is an intermediate structure which will later be <a href="layout.html">converted into the area tree</a> .</p>
-<h2 id="processing-wzxhzdk8wzxhzdk9">Processing <a id="process"></a></h2>
+<h2 id="processing-wzxhzdk9wzxhzdk10">Processing <a id="process"></a></h2>
<p>The SAX Events that are fired by the parsing process are caught by the FO Tree system. Events for starting an element, ending an element, and text data are assembled by the FO Tree system into a set of objects that represent the input FO document. A class exists for each element in the XSL-FO set, and an object in the appropriate class is created for each element in the input XSL-FO.</p>
<p>For attributes attached to an XSL-FO element, a property list mapping is used to convert the attribute into properties of the object related to the element.</p>
<p>To the extent possible, validation is checked as the FO Tree is built. An appropriate error message is returned to the user, and processing continues if possible.</p>
@@ -349,7 +349,7 @@ $(document).ready(function () {
</ul>
<p>For unrecognized namespaces, a dummy object or a generic DOM is created.</p>
<p>While the tree building is mainly about creating the FO Tree, some FO Tree events trigger processes in other parts of FOP. The end of a page-sequence element triggers the layout process for that page-sequence (see discussion of <a href="#recycle">Recycling</a> ). Also, the end of the XML document tells the renderer that it can finalize the output document.</p>
-<h2 id="recycling-fo-tree-memory-wzxhzdk10wzxhzdk11">Recycling FO Tree Memory <a id="recycle"></a></h2>
+<h2 id="recycling-fo-tree-memory-wzxhzdk11wzxhzdk12">Recycling FO Tree Memory <a id="recycle"></a></h2>
<p>To minimize the amount of memory used by FOP, we wish to recycle FO Tree memory as much as possible. There are at least three possible places that FO Tree fragments could be passed to the Layout process, so that their memory can be reused:</p>
<ul>
<li>
@@ -362,17 +362,17 @@ $(document).ready(function () {
<p><strong>fo:page-sequence</strong> The page-sequence object provides a nice clean break in the document. Content from one page-sequence will never interfere with nor affect the placement of the content of another. FOP uses this option as the optimum way to maintain compliance with the standard and to minimize memory consumption.</p>
</li>
</ul>
-<h2 id="fo-tree-serialization-wzxhzdk12wzxhzdk13">FO Tree Serialization <a id="serialize"></a></h2>
+<h2 id="fo-tree-serialization-wzxhzdk13wzxhzdk14">FO Tree Serialization <a id="serialize"></a></h2>
<p>This issue is implied by the requirement to process documents of arbitrary size. Unless some arbitrary limit is placed on the size of page-sequence objects, FOP must be able to serialize FO tree fragments as necessary.</p>
-<h2 id="notes-about-specific-elements-wzxhzdk14wzxhzdk15">Notes About Specific Elements <a id="specific-elements"></a></h2>
-<h3 id="page-master-wzxhzdk16wzxhzdk17">page-master # <a id="page-master"></a></h3>
+<h2 id="notes-about-specific-elements-wzxhzdk15wzxhzdk16">Notes About Specific Elements <a id="specific-elements"></a></h2>
+<h3 id="page-master-wzxhzdk17wzxhzdk18">page-master # <a id="page-master"></a></h3>
<p>The first elements in a document are the elements for the page master setup. This is usually only a small number and will be used throughout the document to create new pages. The root element keeps these objects as a factory to create the page and appropriate regions whenever a new page is requested by the layout. The objects in the FO Tree that represent these elements are themselves the factory.</p>
-<h3 id="flow-wzxhzdk18wzxhzdk19">flow # <a id="flow"></a></h3>
+<h3 id="flow-wzxhzdk19wzxhzdk20">flow # <a id="flow"></a></h3>
<p>The elements within the flow of a page-sequence are those that are needed for the layout process. These element will later be used to create areas in the layout process.</p>
-<h3 id="other-elements-wzxhzdk20wzxhzdk21">Other Elements # <a id="other-elements"></a></h3>
+<h3 id="other-elements-wzxhzdk21wzxhzdk22">Other Elements # <a id="other-elements"></a></h3>
<p>The remaining FO Objects are things like page-sequence, title and color-profile. Each is handled by its parent element. The root handles declarations, and declarations maintains a list of colour profiles. The page-sequences are direct descendants of root.</p>
-<h2 id="implementation-notes-wzxhzdk22wzxhzdk23">Implementation Notes <a id="implement"></a></h2>
-<h3 id="fonode-wzxhzdk24wzxhzdk25">FONode # <a id="fonode"></a></h3>
+<h2 id="implementation-notes-wzxhzdk23wzxhzdk24">Implementation Notes <a id="implement"></a></h2>
+<h3 id="fonode-wzxhzdk25wzxhzdk26">FONode # <a id="fonode"></a></h3>
<p>The base class for all objects in the tree is FONode. The base class for all FO Objects is FObj (which is a subclass of FONode). Other FONode subclasses are for foreign and unknown XML.</p>
<p>Each FO in FOP has a parent (except root) and a Vector of children. Java inheritance (superclasses and subclasses) is used to enforce constraints required by the FO hierarchy.</p>
<p>FONode, among other things, ensures that each FO has a parent, and provides the mechanism for keeping track of its children.</p>
@@ -388,7 +388,7 @@ $(document).ready(function () {
<p>other: <code>org.apache.fop.fo.*.</code> </p>
</li>
</ul>
-<h3 id="creating-fo-objects-wzxhzdk26wzxhzdk27">Creating FO Objects # <a id="create-fo"></a></h3>
+<h3 id="creating-fo-objects-wzxhzdk27wzxhzdk28">Creating FO Objects # <a id="create-fo"></a></h3>
<p>The process of creating an FO Object is as follows (see <code>FOTreeBuilder.startElement()</code> for details):</p>
<ul>
<li>
@@ -407,13 +407,13 @@ $(document).ready(function () {
<p>Child elements are then processed. This is an iterative process: the child elements go through the same process here documented for their parent.</p>
</li>
</ul>
-<h3 id="foreign-xml-wzxhzdk28wzxhzdk29">Foreign XML # <a id="foreign"></a></h3>
+<h3 id="foreign-xml-wzxhzdk29wzxhzdk30">Foreign XML # <a id="foreign"></a></h3>
<p>For SVG, the DOM needs to be created with Batik, so an element mapping is used to read all elements in the SVG namespace and pass them into the Batik DOM.</p>
<p>The base class for foreign XML is XMLObj. This class handles creating a DOM Element and the setting of attributes. It also can create a DOM Document if it is a top level element, class XMLElement. This class must be extended for the namespace of the XML elements. For unknown namespaces the class is UnknowXMLObj.</p>
<p>If some special processing is needed, then the top level element can extend the XMLObj. For example the SVGElement makes the special DOM required for batik and gets the size of the svg.</p>
<p>Foreign XML will usually be in an fo:instream-foreign-object. The XML will be passed to the renderer as a DOM, which is expected to know how to handle it. XML from an unknown namespace will be ignored.</p>
<p>See <a href="parsing.html#namespaces">Input Parsing Namespaces</a> for more discussion and links to information about using foreign XML in FOP.</p>
-<h3 id="unknown-elements-wzxhzdk30wzxhzdk31">Unknown Elements # <a id="unknown"></a></h3>
+<h3 id="unknown-elements-wzxhzdk31wzxhzdk32">Unknown Elements # <a id="unknown"></a></h3>
<p>If an element is in a known namespace but the element is unknown within that namespace, then an Unknown object is created. This generally indicates an input error: perhaps an element from an older version of the XSL-FO standard, or a misspelling. The Unknown object is mainly used to provide information to the user.</p></div>
</div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/images.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/images.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/images.html Wed Oct 24 04:09:09 2012
@@ -330,31 +330,31 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-images">Apache(tm) FOP Design: Images</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-images">Apache™ FOP Design: Images</h1>
<p><version>$Revision: 1298724 $</version></p>
-<h2 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk3wzxhzdk4">Introduction <a id="intro"></a></h2>
<p>Images may only be needed to be loaded when the image is rendered to the output or to find the dimensions.<br></br>An image url may be invalid, this can be costly to find out so we need to keep a list of invalid image urls.</p>
<p>We have a number of different caching schemes that are possible.</p>
<p>All images are referred to using the url given in the XSL:FO after removing "url('')" wrapping. This does not include any sort of resolving such as relative -> absolute. The 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>
-<h2 id="threading-wzxhzdk6wzxhzdk7">Threading <a id="Threading"></a></h2>
+<h2 id="threading-wzxhzdk7wzxhzdk8">Threading <a id="Threading"></a></h2>
<p>In a single threaded case with one document the image should be released as soon as the renderer caches it. If there are multiple documents then the images could be held in a weak cache in case another document needs to load the same image.</p>
<p>In a multi threaded case many threads could be attempting to get the same image. We need to make sure an image will only be loaded once at a particular time. Once a particular document is finished then we can move all the images to a common weak cache.</p>
-<h2 id="caches-wzxhzdk8wzxhzdk9">Caches <a id="Caches"></a></h2>
-<h3 id="lru-wzxhzdk10wzxhzdk11">LRU # <a id="LRU"></a></h3>
+<h2 id="caches-wzxhzdk9wzxhzdk10">Caches <a id="Caches"></a></h2>
+<h3 id="lru-wzxhzdk11wzxhzdk12">LRU # <a id="LRU"></a></h3>
<p>All images are in a common cache regardless of context. To limit the size of the cache the LRU image is removed to keep the amount of memory used low. Each image can supply the amount of data held in memory.</p>
-<h3 id="context-wzxhzdk12wzxhzdk13">Context # <a id="Context"></a></h3>
+<h3 id="context-wzxhzdk13wzxhzdk14">Context # <a id="Context"></a></h3>
<p>Images are cached according to the context, using the FOUserAgent as a key. Once the context is finished the images are added to a common weak hashmap so that other contexts can load these images or the data will be garbage collected if required.</p>
<p>If images are to be used commonly then we cannot dispose of data in the FopImage when cached by the renderer. Also if different contexts have different base directories for resolving relative url's then the loading and caching must be separate. We can have a cache that shares images among all contexts or only loads an image for a context.</p>
<p>The cache uses an image loader so that it can synchronize the image loading on an image by image basis. Finding and adding an image loader to the cache is also synchronized to prevent thread problems.</p>
-<h2 id="invalid-images-wzxhzdk14wzxhzdk15">Invalid Images <a id="Invalid+Images"></a></h2>
+<h2 id="invalid-images-wzxhzdk15wzxhzdk16">Invalid Images <a id="Invalid+Images"></a></h2>
<p>If an image cannot be loaded for some reason, for example the url is invalid or the image data is corrupt or an unknown type. Then it should only attempt to load the image once. All other attempts to get the image should return null so that it can be easily handled.<br></br>This will prevent any extra processing or waiting.</p>
-<h2 id="reading-wzxhzdk18wzxhzdk19">Reading <a id="Reading"></a></h2>
+<h2 id="reading-wzxhzdk19wzxhzdk20">Reading <a id="Reading"></a></h2>
<p>Once a stream is opened for the image url then a set of image readers is used to determine what type of image it is. The reader can peek at the image header or if necessary load the image. The reader can also get the image size at this stage. The reader then can provide the mime type to create the image object to load the rest of the information.</p>
-<h2 id="data-wzxhzdk20wzxhzdk21">Data <a id="Data"></a></h2>
+<h2 id="data-wzxhzdk21wzxhzdk22">Data <a id="Data"></a></h2>
<p>The data usually need for an image is the size and either a bitmap or the original data. Images such as jpeg and eps can be embedded into the document with the original data. SVG images are converted into a DOM which needs to be rendered to the PDF. Other images such as gif, tiff etc. are converted into a bitmap. Data is loaded by the FopImage by calling load(type) where type is the type of data to load.</p>
-<h2 id="rendering-wzxhzdk22wzxhzdk23">Rendering <a id="Rendering"></a></h2>
+<h2 id="rendering-wzxhzdk23wzxhzdk24">Rendering <a id="Rendering"></a></h2>
<p>Different renderers need to have the information in different forms.</p>
-<h3 id="pdf-wzxhzdk24wzxhzdk25">PDF # <a id="PDF"></a></h3>
+<h3 id="pdf-wzxhzdk25wzxhzdk26">PDF # <a id="PDF"></a></h3>
<dl>
<dt>original data</dt>
<dd>JPG, EPS</dd>
@@ -363,14 +363,14 @@ $(document).ready(function () {
<dt>other</dt>
<dd>SVG</dd>
</dl>
-<h2 id="ps-wzxhzdk26wzxhzdk27">PS # <a id="PS"></a></h2>
+<h2 id="ps-wzxhzdk27wzxhzdk28">PS # <a id="PS"></a></h2>
<dl>
<dt>bitmap</dt>
<dd>JPG, gif, tiff, bmp, png</dd>
<dt>other</dt>
<dd>SVG</dd>
</dl>
-<h2 id="awt-wzxhzdk28wzxhzdk29">awt # <a id="awt"></a></h2>
+<h2 id="awt-wzxhzdk29wzxhzdk30">awt # <a id="awt"></a></h2>
<dl>
<dt>bitmap</dt>
<dd>JPG, gif, tiff, bmp, png</dd>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/index.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/index.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/index.html Wed Oct 24 04:09:09 2012
@@ -330,10 +330,10 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-introduction">Apache(tm) FOP Design: Introduction</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-introduction">Apache™ FOP Design: Introduction</h1>
<p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
The articles in this section pertain mainly to the <em>redesign</em> or <em>trunk</em> 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.</p>
-<h1 id="the-black-box-view-wzxhzdk6wzxhzdk7">The Black Box View <a id="black-box"></a></h1>
+<h1 id="the-black-box-view-wzxhzdk7wzxhzdk8">The Black Box View <a id="black-box"></a></h1>
<p>From a user's standpoint, Apache™ FOP is a black box that an xml file as input, performs some magic, then creates the desired output:</p>
<table>
<thead>
@@ -360,16 +360,16 @@ The articles in this section pertain mai
</tbody>
</table>
<p>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.</p>
-<h2 id="primary-design-goals-wzxhzdk9wzxhzdk10">Primary Design Goals <a id="primary-goals"></a></h2>
+<h2 id="primary-design-goals-wzxhzdk10wzxhzdk11">Primary Design Goals <a id="primary-goals"></a></h2>
<p>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.</p>
-<h3 id="conformance-to-the-xsl-fo-specification-wzxhzdk11wzxhzdk12">Conformance to the XSL-FO Specification # <a id="pri-goal-conformance"></a></h3>
+<h3 id="conformance-to-the-xsl-fo-specification-wzxhzdk12wzxhzdk13">Conformance to the XSL-FO Specification # <a id="pri-goal-conformance"></a></h3>
<p>The current design goal is to reach the "basic" level of conformance, and to have enough flexibility in the design to reach "complete" conformance without major rewriting. After "basic" conformance is achieved, it is probable that higher levels of conformance will be sought.</p>
-<h3 id="process-files-of-arbitrary-size-wzxhzdk13wzxhzdk14">Process Files of Arbitrary Size # <a id="pri-goal-unlimited-size"></a></h3>
+<h3 id="process-files-of-arbitrary-size-wzxhzdk14wzxhzdk15">Process Files of Arbitrary Size # <a id="pri-goal-unlimited-size"></a></h3>
<p>Except for user storage limitations, the design goal is to be able to process files of any size. In a separate but related issue, the design goal is to be able to process page-sequence elements of any size. (See <a href="fotree.html#recycle">Recycling FO Tree Memory</a> for a discussion of the use of page-sequence as a logical subdivided "chunk" on an FO document).</p>
-<h2 id="secondary-design-goals-wzxhzdk15wzxhzdk16">Secondary Design Goals <a id="secondary-goals"></a></h2>
-<h3 id="minimize-memory-use-wzxhzdk17wzxhzdk18">Minimize Memory Use # <a id="sec-goal-memory"></a></h3>
+<h2 id="secondary-design-goals-wzxhzdk16wzxhzdk17">Secondary Design Goals <a id="secondary-goals"></a></h2>
+<h3 id="minimize-memory-use-wzxhzdk18wzxhzdk19">Minimize Memory Use # <a id="sec-goal-memory"></a></h3>
<p>Many FOP design decisions revolve around trying to minimize the use of memory. The primary purpose here is to reduce the amount of data that must be serialized to storage during processing. Since our primary design goals include the ability to process files of arbitrary size, there is no way to avoid the need to serialize. However, many FOP users provide web access to documents that are created in real time. 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.</p>
-<h2 id="the-big-picture-view-wzxhzdk19wzxhzdk20">The Big Picture View <a id="big-picture"></a></h2>
+<h2 id="the-big-picture-view-wzxhzdk20wzxhzdk21">The Big Picture View <a id="big-picture"></a></h2>
<p>With our design goals outlined, 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.</p>
<table>
<thead>
@@ -421,7 +421,7 @@ The articles in this section pertain mai
</table>
<p>In general, each piece of data will 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.</p>
<p>For a detailed discussion of the design of any component, follow its link in the table above. Each component outlines the design issues which have already been addressed. These resolution of these design issues is in support of the primary and secondary goals, so they are not necessarily written in stone. However, most of them have been discussed at length among the developers, and are reasonably well settled.</p>
-<h2 id="vocabulary-wzxhzdk21wzxhzdk22">Vocabulary <a id="vocabulary"></a></h2>
+<h2 id="vocabulary-wzxhzdk22wzxhzdk23">Vocabulary <a id="vocabulary"></a></h2>
<p>This section will attempt to provide information about any jargon used in the design documentation.</p>
<p>There is a rough relationship between terms used to describe the various trees in XSL-FO processing, all of which come from the XML and XSL-FO standards. In the table below, the <em>terms</em> (but not the actual items) in each column are roughly equivalent to each other:</p>
<table>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/layout.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/layout.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/layout.html Wed Oct 24 04:09:09 2012
@@ -330,9 +330,9 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-layout">Apache(tm) FOP Design: Layout</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-layout">Apache™ FOP Design: Layout</h1>
<p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h2 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="into"></a></h2>
+<h2 id="introduction-wzxhzdk7wzxhzdk8">Introduction <a id="into"></a></h2>
<p>The role of the layout managers is to build the Area Tree by using the information from the FO Tree. The layout managers decide where information is placed in the area tree.</p>
<p>A layout manager is typically associated with an FO Object but not always.</p>
<p>The layout managers are in between the FO Tree and the Area Tree. They get information from the FO Tree and create areas and build the pages. They hold the state of the layout process as it builds up the areas and pages. They also manage the handling of breaks and spacing between areas.</p>
@@ -341,90 +341,90 @@ $(document).ready(function () {
<p>The layout begins once the hierarchy of FO objects has been constructed. Note: it may be possible to start immediately after a block formatting object has been added to the flow but this is not currently in the scope of the layout. It is also possible to layout all pages in a page sequence after each page sequence has been added from the xml.</p>
<p>The layout process is handled by a set of layout managers. The block level layout managers are used to create the block areas which are added to the region area of a page.</p>
<p>The traversal is done by the layout or structure process only in the flow elements.</p>
-<h2 id="design-issues-wzxhzdk8wzxhzdk9">Design Issues <a id="issues"></a></h2>
-<h3 id="keep-layouts-simple-wzxhzdk10wzxhzdk11">Keep Layouts Simple # <a id="issue-simple-layout"></a></h3>
+<h2 id="design-issues-wzxhzdk9wzxhzdk10">Design Issues <a id="issues"></a></h2>
+<h3 id="keep-layouts-simple-wzxhzdk11wzxhzdk12">Keep Layouts Simple # <a id="issue-simple-layout"></a></h3>
<p>Layout should handle floats, footnotes and keeps in a simple, straightforward way.</p>
-<h3 id="keep-id-references-simple-wzxhzdk12wzxhzdk13">Keep ID References Simple # <a id="issue-simple-id-refs"></a></h3>
-<h3 id="render-pages-asap-wzxhzdk14wzxhzdk15">Render Pages ASAP # <a id="issue-area-recycle"></a></h3>
+<h3 id="keep-id-references-simple-wzxhzdk13wzxhzdk14">Keep ID References Simple # <a id="issue-simple-id-refs"></a></h3>
+<h3 id="render-pages-asap-wzxhzdk15wzxhzdk16">Render Pages ASAP # <a id="issue-area-recycle"></a></h3>
<p>The issue here is that we wish to recycle the Area Tree memory as much as possible. The problem is that forward references prevent pages from being resolved until the forward references are resolved. If memory is insufficient to store unresolved pages, Area Tree fragments must be serialized until resolved.</p>
<p>FOP developers have discussed adding the capability of using an Area Tree to render to more than one output target in the same run, which would be a complicating factor in disposal of pages as they are rendered.</p>
-<h2 id="layout-managers-wzxhzdk16wzxhzdk17">Layout Managers <a id="lm"></a></h2>
+<h2 id="layout-managers-wzxhzdk17wzxhzdk18">Layout Managers <a id="lm"></a></h2>
<p>The layout managers are set up from the hierarchy of the formatting object tree. A manager represents a hierachy of area producing objects. A manager is able to handle the block area(s) that it creates and organise or split areas for page breaks.</p>
<p>Normally any object that creates a block area will have an associated layout manager. Other cases are tables and lists, these objects will also have layout managers that will manager the group of layout managers that make up the object.</p>
<p>A layout manager is also able to determine height (min/max/optimum) and keep status. This will be used when organising the layout on a page. The manager will be able to determine the next place a break can be made and then be able to organise the height.</p>
<p>A layout manager is essentially a bridge between the formatting objects and the area tree. It will keep a list of line areas inside block areas. Each line area will contain a list of inline areas that is able to be adjusted if the need arises.</p>
<p>The objects in the area tree that are organised by the manager will mostly contain the information about there layout such as spacing and keeps, this information will be thrown away once the layout for a page is finalised.</p>
-<h2 id="creating-managers-wzxhzdk18wzxhzdk19">Creating Managers <a id="creating"></a></h2>
+<h2 id="creating-managers-wzxhzdk19wzxhzdk20">Creating Managers <a id="creating"></a></h2>
<p>The managers are created by the page sequence. The top level manager is the Page manager. This asks the flow to add all managers in this page sequence.</p>
<p>For block level objects they have a layout manager. Neutral objects don't represent any areas but are used to contain a block level area and as such these objects will ask the appropriate child to create a layout manager.</p>
<p>Any nested block areas or inline areas may be handled by the layout manager at a later stage.</p>
-<h2 id="using-managers-wzxhzdk20wzxhzdk21">Using Managers <a id="using"></a></h2>
+<h2 id="using-managers-wzxhzdk21wzxhzdk22">Using Managers <a id="using"></a></h2>
<p>Block area layout managers are used to create a block area, other block level managers may ask their child layout managers to create block areas which are then added to the area tree(subset).</p>
<p>A manager is used to add areas to a page until the page is full, then the manages contain all the information necessary to make the decision about page break and spacing. A manager can split an area that it has created will keep a status about what has been added to the current area tree.</p>
-<h2 id="page-layout-wzxhzdk22wzxhzdk23">Page Layout <a id="page"></a></h2>
+<h2 id="page-layout-wzxhzdk23wzxhzdk24">Page Layout <a id="page"></a></h2>
<p>Once the Page layout manager, belonging to the page sequence, is ready then we can start laying out each page. The page sequence will create the current page to put the page data, the next page and if it exists a last page.</p>
<p>The current page will have the areas added to it from the block layout managers. The next page will be used when splitting a block that goes over the page break. Note: any page break overrides the layout decided here. The last page will be necessary if the last block area is added to this page. The size of the last page will be considered and the areas will be added to the last page instead.</p>
<p>The first step is to add areas to the current page until the area is full and the lines of the last block area contain at least n(orphans) and at least n(orphans) + n(widows) in total. This will only be relevant for areas at the start or end of a particular reference area.</p>
<p>The spacing between the areas (including spacing in block areas inside an inline-container) will be set to the minimum values. This will allow the page to have at least all the information it needs to organise the page properly.</p>
<p>This should handle the situation where there are keeps on some block areas that go over the end of the page better. It is possible that fitting the blocks on the page using a spacing between min and optimum would give a closer value to the optimum than putting the blocks on the next page and the spacing being between optimum and max. So if the objects are placed first at optimum then you will need to keep going to see if there is a lower keep further on that has a spacing that is closer to the optimum.</p>
<p>The spacing and keep information is stored so that the area positions and sizes can be adjusted.</p>
-<h2 id="balancing-page-wzxhzdk24wzxhzdk25">Balancing Page <a id="page-balance"></a></h2>
+<h2 id="balancing-page-wzxhzdk25wzxhzdk26">Balancing Page <a id="page-balance"></a></h2>
<p>The page is vertically justified so that it distributes the areas on the page for the best result when considering keeps and spacing.</p>
-<h2 id="finding-break-wzxhzdk26wzxhzdk27">Finding Break <a id="finding-break"></a></h2>
+<h2 id="finding-break-wzxhzdk27wzxhzdk28">Finding Break <a id="finding-break"></a></h2>
<p>First the keeps are checked. The available space on the page may have changed due to the presence of before floats or footnotes. The page break will need to be at a height <= the available space on the page.</p>
<p>A page break should be made at the first available position that has the lowest keep value when searching from the bottom. Once the first possible break is found then the next possible break, with equally low keep value, is considered. If the height of the page is closer to the optimal spacing then this break will be used instead.</p>
<p>Keep values include implicit and explicit values when trying to split a block area into more than one area. Implicit keeps may be such things as widows/orphans.</p>
<p>If the page contains before floats or footnotes then as each area or line area is removed the float/footnote should also be removed. This will change the available space and is a one way operation. The footnote should be removed first as a footnote may be placed on the next page. The lowest keep value may need to be reassessed as each conditional area is removed.</p>
<p>The before float and footnote regions are managed so that the separator regions will be present if it contains at least one area.</p>
-<h2 id="optimising-wzxhzdk28wzxhzdk29">Optimising <a id="optimize"></a></h2>
+<h2 id="optimising-wzxhzdk29wzxhzdk30">Optimising <a id="optimize"></a></h2>
<p>Once the areas for the page are finalised then the spacing will need to be adjusted. The available height on the page is compared with the min and max spacing. All of the spacing in all the areas on the page is then adjusted by the appropriate percentage value.</p>
-<h2 id="multi-column-pages-wzxhzdk30wzxhzdk31">Multi-Column Pages <a id="multi-column"></a></h2>
+<h2 id="multi-column-pages-wzxhzdk31wzxhzdk32">Multi-Column Pages <a id="multi-column"></a></h2>
<p>In the case of multi-column pages the column breaks and eventually the page break must be found in a slightly different way.</p>
<p>The columns need to be layed out completely from first to last but this can only be done after a rough estimate of all the elements on the page in case of before floats or footnotes.</p>
<p>So first the complete page is layed out with all columns filled with areas and the spacing at a minimum. Then if there are any before floats or footnotes then the availabe space is adjusted. Then each the best break is found for each column starting from the first column. If any before floats or footnotes are removed as a result of the new breaks and optimised spacing then all the columns should still be layed out for the same column height.</p>
-<h2 id="completing-page-wzxhzdk32wzxhzdk33">Completing Page <a id="page-complete"></a></h2>
+<h2 id="completing-page-wzxhzdk33wzxhzdk34">Completing Page <a id="page-complete"></a></h2>
<p>After the region body has been finished the static areas can be layed out. The width of the static area is set and the height is inifinite, that is all block areas should be placed in the area and their visibility is controlled be other factors.</p>
<p>The area tree for the region body will contain the information about markers that may be necessary for the retrieve marker.</p>
<p>The ordering of the area tree must be adjusted so that the areas are before, start, body, end and after in that order. The body region should be in the order before float, main then footnote.</p>
-<h2 id="line-areas-wzxhzdk34wzxhzdk35">Line Areas <a id="line-area"></a></h2>
+<h2 id="line-areas-wzxhzdk35wzxhzdk36">Line Areas <a id="line-area"></a></h2>
<p>Creating a line areas uses a similair concept. Each inline area is placed across the available space until there is no room left. The line is then split by considering all keeps and spacing.</p>
<p>Each word (group of adjacent character inline areas) will have keeps based on hyphenation. The line break is at the lowest keep value starting from the end of the line.</p>
<p>Once a line has been layed out for a particular width then that line is fixed for the page (except for unresolved page references).</p>
-<h2 id="before-floats-and-footnotes-wzxhzdk36wzxhzdk37">Before Floats and Footnotes <a id="before-float-footnote"></a></h2>
+<h2 id="before-floats-and-footnotes-wzxhzdk37wzxhzdk38">Before Floats and Footnotes <a id="before-float-footnote"></a></h2>
<p>The before float region and footnote region are handled by the page layoutmanger. These regions will handle the addition and removal of the separator regions when before floats/footnotes area added and removed.</p>
<p>Footnotes and Before Floats are placed in special areas in the body region of the page. The size of these areas is determined by the content. This in turn effects the available size of the main reference area that contains the flow.</p>
<p>A layout manager handles the adding and removing of footnotes/floats, this in turn effects the available space in the main reference area.</p>
-<h2 id="side-floats-wzxhzdk38wzxhzdk39">Side Floats <a id="side-float"></a></h2>
+<h2 id="side-floats-wzxhzdk39wzxhzdk40">Side Floats <a id="side-float"></a></h2>
<p>If a float anchor is present in a particular line area then the available space for that line (and other in the block) will be reduced. The side float adds to the height of the block area and this height also depends on the clear value of subsequent blocks. The keep status of the block is also effected as there must be enough space on the page to fit the side float.</p>
<p>Side floats alter the length of the inline progression dimension for the current line and following lines for the size of the float.</p>
<p>This means that the float needs to be handled by the block layout manager so that it can adjust the available inline progression dimension for the relevant line areas.</p>
-<h2 id="unresolved-areas-wzxhzdk40wzxhzdk41">Unresolved Areas <a id="unresolved-area"></a></h2>
+<h2 id="unresolved-areas-wzxhzdk41wzxhzdk42">Unresolved Areas <a id="unresolved-area"></a></h2>
<p>Once the layout of the page is complete there may be unresolved areas.</p>
<p>Page number citations and links may require following pages to be layed out before they can be resolved. These will remain in the area tree as unresolved areas.</p>
<p>As each page is completed the list of unresolved id's will be checked and if the id can be resolved it will be. Once all id's are resolved then the page can be rendered.</p>
<p>Each page contains a map of all unresolved id's and the corresponding areas.</p>
<p>In the case of page number citations, the areas reserves the equivalent of 3 number nines in the current font. When the area is resolved then the area is adjusted to its proper size and the line area is re-aligned to accomodate the change.</p>
-<h2 id="id-and-link-areas-wzxhzdk42wzxhzdk43">ID and Link Areas <a id="id-link-area"></a></h2>
+<h2 id="id-and-link-areas-wzxhzdk43wzxhzdk44">ID and Link Areas <a id="id-link-area"></a></h2>
<p>Any formatting object that has an ID or any inline link defines an area that will be required when rendering and resolving id references.</p>
<p>This area is stored in the parent area and may be a shape that exists in more than one page, for example over a page break. This shape consists of the boundary of all inline (or block) areas that the shape is defined for.</p>
-<h2 id="inline-areas-wzxhzdk44wzxhzdk45">Inline Areas <a id="inline-area"></a></h2>
+<h2 id="inline-areas-wzxhzdk45wzxhzdk46">Inline Areas <a id="inline-area"></a></h2>
<p>This is the definition of all inline areas that will exist in the area.</p>
-<h2 id="fixed-areas-wzxhzdk46wzxhzdk47">Fixed Areas <a id="fixed-area"></a></h2>
+<h2 id="fixed-areas-wzxhzdk47wzxhzdk48">Fixed Areas <a id="fixed-area"></a></h2>
<p>instream-foreign-object, external-graphic, inline-container</p>
<p>These areas have a fixed width and height. They also have a viewport.</p>
-<h2 id="stretch-areas-wzxhzdk48wzxhzdk49">Stretch Areas <a id="stretch-area"></a></h2>
+<h2 id="stretch-areas-wzxhzdk49wzxhzdk50">Stretch Areas <a id="stretch-area"></a></h2>
<p>leader, inline space</p>
<p>These areas have a fixed height but the width may vary.</p>
-<h2 id="character-areas-wzxhzdk50wzxhzdk51">Character Areas <a id="character-area"></a></h2>
+<h2 id="character-areas-wzxhzdk51wzxhzdk52">Character Areas <a id="character-area"></a></h2>
<p>character</p>
<p>This is an simple character that has fixed properties according to the current font. There are implicit keeps with adjacent characters.</p>
-<h2 id="anchor-areas-wzxhzdk52wzxhzdk53">Anchor Areas <a id="anchor-area"></a></h2>
+<h2 id="anchor-areas-wzxhzdk53wzxhzdk54">Anchor Areas <a id="anchor-area"></a></h2>
<p>float anchor, footnote anchor</p>
<p>This area has no size. It keeps the position for footnotes and floats and has a keep with the associated inline area.</p>
-<h2 id="unresolved-page-numbers-wzxhzdk54wzxhzdk55">Unresolved Page Numbers <a id="unresolved-page-num"></a></h2>
+<h2 id="unresolved-page-numbers-wzxhzdk55wzxhzdk56">Unresolved Page Numbers <a id="unresolved-page-num"></a></h2>
<p>page-number-citation</p>
<p>A page number area that needs resolving, behaves as a character and has the space of 3 normal characters reserved. The size will adjust when the value is resolved.</p>
-<h2 id="block-areas-wzxhzdk56wzxhzdk57">Block Areas <a id="block-area"></a></h2>
+<h2 id="block-areas-wzxhzdk57wzxhzdk58">Block Areas <a id="block-area"></a></h2>
<p>When a block creating element is complete then it is possible to build the block area and add it to the paprent.</p>
<p>A block area will contain either more block areas or line areas, which are special block areas. The line areas are created by the LineLayoutManager in which the inline areas flow into.</p>
<p>So a block area manager handles the lines or blocks as its children and determines things like spacing and breaks.</p>
@@ -451,21 +451,21 @@ $(document).ready(function () {
</li>
</ul>
<p>Once the layout has been finalised then this information can be discarded.</p>
-<h2 id="page-areas-wzxhzdk58wzxhzdk59">Page Areas <a id="page-area"></a></h2>
+<h2 id="page-areas-wzxhzdk59wzxhzdk60">Page Areas <a id="page-area"></a></h2>
<p>Contains inforamtion about all the block areas in the body, before area and footer area.</p>
<p>Has a list of the unresolved page references and a list of id refences that can be used to obtain the area associated with that id.</p>
-<h2 id="test-cases-wzxhzdk60wzxhzdk61">Test Cases <a id="test-cases"></a></h2>
+<h2 id="test-cases-wzxhzdk61wzxhzdk62">Test Cases <a id="test-cases"></a></h2>
<p>Here a few layout possibilities areas explored to determine how the layout process will handle these situations.</p>
-<h3 id="simple-pages-wzxhzdk62wzxhzdk63">Simple Pages # <a id="test-simple"></a></h3>
+<h3 id="simple-pages-wzxhzdk63wzxhzdk64">Simple Pages # <a id="test-simple"></a></h3>
<p>All blocks (including nested) are placed on the page with minimum spacing and the last block has the minimum number of lines past the page end. The lowest keep value is then found within the body area limits. Then the next equally low keep is found to determine if the spacing will be closer to the optimum values.</p>
-<h3 id="before-floatsfootnotes-wzxhzdk64wzxhzdk65">Before Floats/Footnotes # <a id="test-before-float-footnote"></a></h3>
+<h3 id="before-floatsfootnotes-wzxhzdk65wzxhzdk66">Before Floats/Footnotes # <a id="test-before-float-footnote"></a></h3>
<p>After filling the page with the block areas then the new body height is used to find the best position to break. Before each line area or block area is remove any associated before floats and footnotes are removed. This will then adjust the available space on the page and may allow for a different breaking point. Areas are removed towards the new breaking point until the areas fit on the page. When finding the optimum spacing the removal of before floats and footnotes must also be onsidered.</p>
-<h3 id="multicolumn-wzxhzdk66wzxhzdk67">Multicolumn # <a id="test-multi-column"></a></h3>
+<h3 id="multicolumn-wzxhzdk67wzxhzdk68">Multicolumn # <a id="test-multi-column"></a></h3>
<p>First the page is filled with all columns for the intial page area. Then each column is adjusted for the new height starting from the first column. The best break for the column is found then the next column is considered, any left over areas a pre-pended to the next column. Once all the columns are finished then all the columns are adjusted to fit in the same height columns. This handles the situation where before floats or footnotes may have been removed.</p>
-<h3 id="last-page-wzxhzdk68wzxhzdk69">Last Page # <a id="test-last-page"></a></h3>
+<h3 id="last-page-wzxhzdk69wzxhzdk70">Last Page # <a id="test-last-page"></a></h3>
<p>If in the process of adding areas to a page it is found that there are no more areas in the flow then this page will need to be changed to the last page (if applicable). The areas are then placed on a last page.</p>
-<h2 id="status-wzxhzdk70wzxhzdk71">Status <a id="status"></a></h2>
-<h3 id="to-do-wzxhzdk72wzxhzdk73">To Do # <a id="status-todo"></a></h3>
+<h2 id="status-wzxhzdk71wzxhzdk72">Status <a id="status"></a></h2>
+<h3 id="to-do-wzxhzdk73wzxhzdk74">To Do # <a id="status-todo"></a></h3>
<table>
<thead>
<tr>
@@ -562,8 +562,8 @@ $(document).ready(function () {
</tr>
</tbody>
</table>
-<h3 id="work-in-progress-wzxhzdk74wzxhzdk75">Work in Progress # <a id="status-wip"></a></h3>
-<h3 id="completed-wzxhzdk76wzxhzdk77">Completed # <a id="status-complete"></a></h3></div>
+<h3 id="work-in-progress-wzxhzdk75wzxhzdk76">Work in Progress # <a id="status-wip"></a></h3>
+<h3 id="completed-wzxhzdk77wzxhzdk78">Completed # <a id="status-complete"></a></h3></div>
</div>
<div class="clear"></div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/optimise.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/optimise.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/optimise.html Wed Oct 24 04:09:09 2012
@@ -330,9 +330,9 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-optimisations">Apache(tm) FOP Design: Optimisations</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-optimisations">Apache™ FOP Design: Optimisations</h1>
<p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h2 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk7wzxhzdk8">Introduction <a id="intro"></a></h2>
<p>Apache™ FOP should be able to handle very large documents. A document can be supplied using SAX and the information should be passed entirely through the system, from fo elements to rendered output as soon as possible.</p>
<p>A top level block area, immediately below the flow, can be added to the page layout as soon as the element is complete.</p>
<p>The fo elements used to construct a page can be discarded as soon as the layout for the page is complete. Some information may be stored in the area tree of the page in order to handle unresolved page references and links.</p>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/parsing.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/parsing.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/parsing.html Wed Oct 24 04:09:09 2012
@@ -330,11 +330,11 @@ $(document).ready(function () {
<div id="content" class="grid_16">
<!-- <div id="breadcrumb"><a href="/">Home</a> » <a href="/fop/">Fop</a> » <a href="/fop/dev/">Dev</a> » <a href="/fop/dev/design/">Design</a></div> -->
- <div class="section-content"><h1 id="apachetm-fop-design-input-parsing">Apache(tm) FOP Design: Input Parsing</h1>
+ <div class="section-content"><h1 id="apachewzxhzdk0-fop-design-input-parsing">Apache™ FOP Design: Input Parsing</h1>
<p><version>$Revision: 1298724 $</version></p>
-<h2 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="intro"></a></h2>
+<h2 id="introduction-wzxhzdk3wzxhzdk4">Introduction <a id="intro"></a></h2>
<p>Parsing is the process of reading the XSL-FO input and making the information in it available to Apache™ FOP.</p>
-<h2 id="sax-for-input-wzxhzdk5wzxhzdk6">SAX for Input <a id="input"></a></h2>
+<h2 id="sax-for-input-wzxhzdk6wzxhzdk7">SAX for Input <a id="input"></a></h2>
<p>The two standard ways of dealing with XML input are SAX and DOM. SAX basically creates events as it parses an XML document in a serial fashion; a program using SAX (and not storing anything internally) will only see a small window of the document at any point in time, and can never look forward in the document. DOM creates and stores a tree representation of the document, allowing a view of the entire document as an integrated whole. One issue that may seem counter-intuitive to some new FOP developers, and which has from time to time been contentious, is that FOP uses SAX for input. (DOM can be used as input as well, but it is converted into SAX events before entering FOP, effectively negating its advantages).</p>
<p>Since FOP essentially needs a tree representation of the FO input, at first glance it seems to make sense to use DOM. Instead, FOP takes SAX events and builds its own tree-like structure. Why?</p>
<ul>
@@ -347,18 +347,18 @@ $(document).ready(function () {
</ul>
<p>See the <a href="../../trunk/embedding.html#input">Input Section of the User Embedding Document</a> for a discussion of input usage patterns and some implementation details.</p>
<p>FOP's <a href="fotree.html">FO Tree Mechanism</a> is responsible for catching the SAX events and processing them.</p>
-<h2 id="validation-wzxhzdk7wzxhzdk8">Validation <a id="validation"></a></h2>
+<h2 id="validation-wzxhzdk8wzxhzdk9">Validation <a id="validation"></a></h2>
<p>If the input XML is not well-formed, that will be reported.</p>
<p>There is no DTD for XSL-FO, so no formal validation is possible at the parser level.</p>
<p>The SAX handler will report an error for unrecognized <a href="#namespaces">namespaces</a> .</p>
-<h2 id="namespaces-wzxhzdk9wzxhzdk10">Namespaces <a id="namespaces"></a></h2>
+<h2 id="namespaces-wzxhzdk10wzxhzdk11">Namespaces <a id="namespaces"></a></h2>
<p>To allow for extensions to the XSL-FO language, FOP provides a mechanism for handling foreign namespaces.</p>
<p>See <a href="../../trunk/extensions.html">User Extensions</a> for a discussion of standard extensions shipped with FOP, and their related namespaces.</p>
<p>See <a href="../extensions.html">Developer Extensions</a> for a discussion of the mechanisms in place to allow developers to add their own extensions, including how to tell FOP about the foreign namespace.</p>
-<h2 id="status-wzxhzdk11wzxhzdk12">Status <a id="status"></a></h2>
-<h3 id="to-do-wzxhzdk13wzxhzdk14">To Do # <a id="status-todo"></a></h3>
-<h3 id="work-in-progress-wzxhzdk15wzxhzdk16">Work In Progress # <a id="status-wip"></a></h3>
-<h3 id="completed-wzxhzdk17wzxhzdk18">Completed # <a id="status-complete"></a></h3>
+<h2 id="status-wzxhzdk12wzxhzdk13">Status <a id="status"></a></h2>
+<h3 id="to-do-wzxhzdk14wzxhzdk15">To Do # <a id="status-todo"></a></h3>
+<h3 id="work-in-progress-wzxhzdk16wzxhzdk17">Work In Progress # <a id="status-wip"></a></h3>
+<h3 id="completed-wzxhzdk18wzxhzdk19">Completed # <a id="status-complete"></a></h3>
<ul>
<li>
<p>better handling of unknown xml and xml from an unknown namespace</p>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org