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/23 17:07:26 UTC
svn commit: r835894 [13/20] - in
/websites/staging/xmlgraphics/trunk/content: ./ batik/ batik/dev/
batik/tools/ batik/using/ batik/using/scripting/ 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/images.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/images.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/images.html Tue Oct 23 15:07:21 2012
@@ -331,29 +331,29 @@ $(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"><p><version>$Revision: 1298724 $</version></p>
-<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="intro"></a></h1>
<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>
-<h1 id="threading-wzxhzdk6wzxhzdk7">Threading <a id="#Threading"></a></h1>
+<h1 id="threading-wzxhzdk6wzxhzdk7">Threading <a id="Threading"></a></h1>
<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>
-<h1 id="caches-wzxhzdk8wzxhzdk9">Caches <a id="#Caches"></a></h1>
-<h2 id="lru-wzxhzdk10wzxhzdk11">LRU # <a id="#LRU"></a></h2>
+<h1 id="caches-wzxhzdk8wzxhzdk9">Caches <a id="Caches"></a></h1>
+<h2 id="lru-wzxhzdk10wzxhzdk11">LRU # <a id="LRU"></a></h2>
<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>
-<h2 id="context-wzxhzdk12wzxhzdk13">Context # <a id="#Context"></a></h2>
+<h2 id="context-wzxhzdk12wzxhzdk13">Context # <a id="Context"></a></h2>
<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>
-<h1 id="invalid-images-wzxhzdk14wzxhzdk15">Invalid Images <a id="#Invalid+Images"></a></h1>
+<h1 id="invalid-images-wzxhzdk14wzxhzdk15">Invalid Images <a id="Invalid+Images"></a></h1>
<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>
-<h1 id="reading-wzxhzdk18wzxhzdk19">Reading <a id="#Reading"></a></h1>
+<h1 id="reading-wzxhzdk18wzxhzdk19">Reading <a id="Reading"></a></h1>
<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>
-<h1 id="data-wzxhzdk20wzxhzdk21">Data <a id="#Data"></a></h1>
+<h1 id="data-wzxhzdk20wzxhzdk21">Data <a id="Data"></a></h1>
<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>
-<h1 id="rendering-wzxhzdk22wzxhzdk23">Rendering <a id="#Rendering"></a></h1>
+<h1 id="rendering-wzxhzdk22wzxhzdk23">Rendering <a id="Rendering"></a></h1>
<p>Different renderers need to have the information in different forms.</p>
-<h2 id="pdf-wzxhzdk24wzxhzdk25">PDF # <a id="#PDF"></a></h2>
+<h2 id="pdf-wzxhzdk24wzxhzdk25">PDF # <a id="PDF"></a></h2>
<dl>
<dt>original data</dt>
<dd>JPG, EPS</dd>
@@ -362,14 +362,14 @@ $(document).ready(function () {
<dt>other</dt>
<dd>SVG</dd>
</dl>
-<h2 id="ps-wzxhzdk26wzxhzdk27">PS # <a id="#PS"></a></h2>
+<h2 id="ps-wzxhzdk26wzxhzdk27">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-wzxhzdk28wzxhzdk29">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 Tue Oct 23 15:07:21 2012
@@ -332,7 +332,7 @@ $(document).ready(function () {
<!-- <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"><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-wzxhzdk6wzxhzdk7">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>
@@ -359,16 +359,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>
-<h1 id="primary-design-goals-wzxhzdk9wzxhzdk10">Primary Design Goals <a id="#primary-goals"></a></h1>
+<h1 id="primary-design-goals-wzxhzdk9wzxhzdk10">Primary Design Goals <a id="primary-goals"></a></h1>
<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>
-<h2 id="conformance-to-the-xsl-fo-specification-wzxhzdk11wzxhzdk12">Conformance to the XSL-FO Specification # <a id="#pri-goal-conformance"></a></h2>
+<h2 id="conformance-to-the-xsl-fo-specification-wzxhzdk11wzxhzdk12">Conformance to the XSL-FO Specification # <a id="pri-goal-conformance"></a></h2>
<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>
-<h2 id="process-files-of-arbitrary-size-wzxhzdk13wzxhzdk14">Process Files of Arbitrary Size # <a id="#pri-goal-unlimited-size"></a></h2>
+<h2 id="process-files-of-arbitrary-size-wzxhzdk13wzxhzdk14">Process Files of Arbitrary Size # <a id="pri-goal-unlimited-size"></a></h2>
<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>
-<h1 id="secondary-design-goals-wzxhzdk15wzxhzdk16">Secondary Design Goals <a id="#secondary-goals"></a></h1>
-<h2 id="minimize-memory-use-wzxhzdk17wzxhzdk18">Minimize Memory Use # <a id="#sec-goal-memory"></a></h2>
+<h1 id="secondary-design-goals-wzxhzdk15wzxhzdk16">Secondary Design Goals <a id="secondary-goals"></a></h1>
+<h2 id="minimize-memory-use-wzxhzdk17wzxhzdk18">Minimize Memory Use # <a id="sec-goal-memory"></a></h2>
<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>
-<h1 id="the-big-picture-view-wzxhzdk19wzxhzdk20">The Big Picture View <a id="#big-picture"></a></h1>
+<h1 id="the-big-picture-view-wzxhzdk19wzxhzdk20">The Big Picture View <a id="big-picture"></a></h1>
<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>
@@ -420,7 +420,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>
-<h1 id="vocabulary-wzxhzdk21wzxhzdk22">Vocabulary <a id="#vocabulary"></a></h1>
+<h1 id="vocabulary-wzxhzdk21wzxhzdk22">Vocabulary <a id="vocabulary"></a></h1>
<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 Tue Oct 23 15:07:21 2012
@@ -331,7 +331,7 @@ $(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"><p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="#into"></a></h1>
+<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="into"></a></h1>
<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>
@@ -340,90 +340,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>
-<h1 id="design-issues-wzxhzdk8wzxhzdk9">Design Issues <a id="#issues"></a></h1>
-<h2 id="keep-layouts-simple-wzxhzdk10wzxhzdk11">Keep Layouts Simple # <a id="#issue-simple-layout"></a></h2>
+<h1 id="design-issues-wzxhzdk8wzxhzdk9">Design Issues <a id="issues"></a></h1>
+<h2 id="keep-layouts-simple-wzxhzdk10wzxhzdk11">Keep Layouts Simple # <a id="issue-simple-layout"></a></h2>
<p>Layout should handle floats, footnotes and keeps in a simple, straightforward way.</p>
-<h2 id="keep-id-references-simple-wzxhzdk12wzxhzdk13">Keep ID References Simple # <a id="#issue-simple-id-refs"></a></h2>
-<h2 id="render-pages-asap-wzxhzdk14wzxhzdk15">Render Pages ASAP # <a id="#issue-area-recycle"></a></h2>
+<h2 id="keep-id-references-simple-wzxhzdk12wzxhzdk13">Keep ID References Simple # <a id="issue-simple-id-refs"></a></h2>
+<h2 id="render-pages-asap-wzxhzdk14wzxhzdk15">Render Pages ASAP # <a id="issue-area-recycle"></a></h2>
<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>
-<h1 id="layout-managers-wzxhzdk16wzxhzdk17">Layout Managers <a id="#lm"></a></h1>
+<h1 id="layout-managers-wzxhzdk16wzxhzdk17">Layout Managers <a id="lm"></a></h1>
<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>
-<h1 id="creating-managers-wzxhzdk18wzxhzdk19">Creating Managers <a id="#creating"></a></h1>
+<h1 id="creating-managers-wzxhzdk18wzxhzdk19">Creating Managers <a id="creating"></a></h1>
<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>
-<h1 id="using-managers-wzxhzdk20wzxhzdk21">Using Managers <a id="#using"></a></h1>
+<h1 id="using-managers-wzxhzdk20wzxhzdk21">Using Managers <a id="using"></a></h1>
<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>
-<h1 id="page-layout-wzxhzdk22wzxhzdk23">Page Layout <a id="#page"></a></h1>
+<h1 id="page-layout-wzxhzdk22wzxhzdk23">Page Layout <a id="page"></a></h1>
<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>
-<h1 id="balancing-page-wzxhzdk24wzxhzdk25">Balancing Page <a id="#page-balance"></a></h1>
+<h1 id="balancing-page-wzxhzdk24wzxhzdk25">Balancing Page <a id="page-balance"></a></h1>
<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>
-<h1 id="finding-break-wzxhzdk26wzxhzdk27">Finding Break <a id="#finding-break"></a></h1>
+<h1 id="finding-break-wzxhzdk26wzxhzdk27">Finding Break <a id="finding-break"></a></h1>
<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>
-<h1 id="optimising-wzxhzdk28wzxhzdk29">Optimising <a id="#optimize"></a></h1>
+<h1 id="optimising-wzxhzdk28wzxhzdk29">Optimising <a id="optimize"></a></h1>
<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>
-<h1 id="multi-column-pages-wzxhzdk30wzxhzdk31">Multi-Column Pages <a id="#multi-column"></a></h1>
+<h1 id="multi-column-pages-wzxhzdk30wzxhzdk31">Multi-Column Pages <a id="multi-column"></a></h1>
<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>
-<h1 id="completing-page-wzxhzdk32wzxhzdk33">Completing Page <a id="#page-complete"></a></h1>
+<h1 id="completing-page-wzxhzdk32wzxhzdk33">Completing Page <a id="page-complete"></a></h1>
<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>
-<h1 id="line-areas-wzxhzdk34wzxhzdk35">Line Areas <a id="#line-area"></a></h1>
+<h1 id="line-areas-wzxhzdk34wzxhzdk35">Line Areas <a id="line-area"></a></h1>
<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>
-<h1 id="before-floats-and-footnotes-wzxhzdk36wzxhzdk37">Before Floats and Footnotes <a id="#before-float-footnote"></a></h1>
+<h1 id="before-floats-and-footnotes-wzxhzdk36wzxhzdk37">Before Floats and Footnotes <a id="before-float-footnote"></a></h1>
<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>
-<h1 id="side-floats-wzxhzdk38wzxhzdk39">Side Floats <a id="#side-float"></a></h1>
+<h1 id="side-floats-wzxhzdk38wzxhzdk39">Side Floats <a id="side-float"></a></h1>
<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>
-<h1 id="unresolved-areas-wzxhzdk40wzxhzdk41">Unresolved Areas <a id="#unresolved-area"></a></h1>
+<h1 id="unresolved-areas-wzxhzdk40wzxhzdk41">Unresolved Areas <a id="unresolved-area"></a></h1>
<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>
-<h1 id="id-and-link-areas-wzxhzdk42wzxhzdk43">ID and Link Areas <a id="#id-link-area"></a></h1>
+<h1 id="id-and-link-areas-wzxhzdk42wzxhzdk43">ID and Link Areas <a id="id-link-area"></a></h1>
<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>
-<h1 id="inline-areas-wzxhzdk44wzxhzdk45">Inline Areas <a id="#inline-area"></a></h1>
+<h1 id="inline-areas-wzxhzdk44wzxhzdk45">Inline Areas <a id="inline-area"></a></h1>
<p>This is the definition of all inline areas that will exist in the area.</p>
-<h1 id="fixed-areas-wzxhzdk46wzxhzdk47">Fixed Areas <a id="#fixed-area"></a></h1>
+<h1 id="fixed-areas-wzxhzdk46wzxhzdk47">Fixed Areas <a id="fixed-area"></a></h1>
<p>instream-foreign-object, external-graphic, inline-container</p>
<p>These areas have a fixed width and height. They also have a viewport.</p>
-<h1 id="stretch-areas-wzxhzdk48wzxhzdk49">Stretch Areas <a id="#stretch-area"></a></h1>
+<h1 id="stretch-areas-wzxhzdk48wzxhzdk49">Stretch Areas <a id="stretch-area"></a></h1>
<p>leader, inline space</p>
<p>These areas have a fixed height but the width may vary.</p>
-<h1 id="character-areas-wzxhzdk50wzxhzdk51">Character Areas <a id="#character-area"></a></h1>
+<h1 id="character-areas-wzxhzdk50wzxhzdk51">Character Areas <a id="character-area"></a></h1>
<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>
-<h1 id="anchor-areas-wzxhzdk52wzxhzdk53">Anchor Areas <a id="#anchor-area"></a></h1>
+<h1 id="anchor-areas-wzxhzdk52wzxhzdk53">Anchor Areas <a id="anchor-area"></a></h1>
<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>
-<h1 id="unresolved-page-numbers-wzxhzdk54wzxhzdk55">Unresolved Page Numbers <a id="#unresolved-page-num"></a></h1>
+<h1 id="unresolved-page-numbers-wzxhzdk54wzxhzdk55">Unresolved Page Numbers <a id="unresolved-page-num"></a></h1>
<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>
-<h1 id="block-areas-wzxhzdk56wzxhzdk57">Block Areas <a id="#block-area"></a></h1>
+<h1 id="block-areas-wzxhzdk56wzxhzdk57">Block Areas <a id="block-area"></a></h1>
<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>
@@ -450,21 +450,21 @@ $(document).ready(function () {
</li>
</ul>
<p>Once the layout has been finalised then this information can be discarded.</p>
-<h1 id="page-areas-wzxhzdk58wzxhzdk59">Page Areas <a id="#page-area"></a></h1>
+<h1 id="page-areas-wzxhzdk58wzxhzdk59">Page Areas <a id="page-area"></a></h1>
<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>
-<h1 id="test-cases-wzxhzdk60wzxhzdk61">Test Cases <a id="#test-cases"></a></h1>
+<h1 id="test-cases-wzxhzdk60wzxhzdk61">Test Cases <a id="test-cases"></a></h1>
<p>Here a few layout possibilities areas explored to determine how the layout process will handle these situations.</p>
-<h2 id="simple-pages-wzxhzdk62wzxhzdk63">Simple Pages # <a id="#test-simple"></a></h2>
+<h2 id="simple-pages-wzxhzdk62wzxhzdk63">Simple Pages # <a id="test-simple"></a></h2>
<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>
-<h2 id="before-floatsfootnotes-wzxhzdk64wzxhzdk65">Before Floats/Footnotes # <a id="#test-before-float-footnote"></a></h2>
+<h2 id="before-floatsfootnotes-wzxhzdk64wzxhzdk65">Before Floats/Footnotes # <a id="test-before-float-footnote"></a></h2>
<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>
-<h2 id="multicolumn-wzxhzdk66wzxhzdk67">Multicolumn # <a id="#test-multi-column"></a></h2>
+<h2 id="multicolumn-wzxhzdk66wzxhzdk67">Multicolumn # <a id="test-multi-column"></a></h2>
<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>
-<h2 id="last-page-wzxhzdk68wzxhzdk69">Last Page # <a id="#test-last-page"></a></h2>
+<h2 id="last-page-wzxhzdk68wzxhzdk69">Last Page # <a id="test-last-page"></a></h2>
<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>
-<h1 id="status-wzxhzdk70wzxhzdk71">Status <a id="#status"></a></h1>
-<h2 id="to-do-wzxhzdk72wzxhzdk73">To Do # <a id="#status-todo"></a></h2>
+<h1 id="status-wzxhzdk70wzxhzdk71">Status <a id="status"></a></h1>
+<h2 id="to-do-wzxhzdk72wzxhzdk73">To Do # <a id="status-todo"></a></h2>
<table>
<thead>
<tr>
@@ -561,8 +561,8 @@ $(document).ready(function () {
</tr>
</tbody>
</table>
-<h2 id="work-in-progress-wzxhzdk74wzxhzdk75">Work in Progress # <a id="#status-wip"></a></h2>
-<h2 id="completed-wzxhzdk76wzxhzdk77">Completed # <a id="#status-complete"></a></h2></div>
+<h2 id="work-in-progress-wzxhzdk74wzxhzdk75">Work in Progress # <a id="status-wip"></a></h2>
+<h2 id="completed-wzxhzdk76wzxhzdk77">Completed # <a id="status-complete"></a></h2></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 Tue Oct 23 15:07:21 2012
@@ -331,7 +331,7 @@ $(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"><p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h1>
<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 Tue Oct 23 15:07:21 2012
@@ -331,9 +331,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"><p><version>$Revision: 1298724 $</version></p>
-<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="intro"></a></h1>
<p>Parsing is the process of reading the XSL-FO input and making the information in it available to Apache™ FOP.</p>
-<h1 id="sax-for-input-wzxhzdk5wzxhzdk6">SAX for Input <a id="#input"></a></h1>
+<h1 id="sax-for-input-wzxhzdk5wzxhzdk6">SAX for Input <a id="input"></a></h1>
<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>
@@ -346,18 +346,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>
-<h1 id="validation-wzxhzdk7wzxhzdk8">Validation <a id="#validation"></a></h1>
+<h1 id="validation-wzxhzdk7wzxhzdk8">Validation <a id="validation"></a></h1>
<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>
-<h1 id="namespaces-wzxhzdk9wzxhzdk10">Namespaces <a id="#namespaces"></a></h1>
+<h1 id="namespaces-wzxhzdk9wzxhzdk10">Namespaces <a id="namespaces"></a></h1>
<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>
-<h1 id="status-wzxhzdk11wzxhzdk12">Status <a id="#status"></a></h1>
-<h2 id="to-do-wzxhzdk13wzxhzdk14">To Do # <a id="#status-todo"></a></h2>
-<h2 id="work-in-progress-wzxhzdk15wzxhzdk16">Work In Progress # <a id="#status-wip"></a></h2>
-<h2 id="completed-wzxhzdk17wzxhzdk18">Completed # <a id="#status-complete"></a></h2>
+<h1 id="status-wzxhzdk11wzxhzdk12">Status <a id="status"></a></h1>
+<h2 id="to-do-wzxhzdk13wzxhzdk14">To Do # <a id="status-todo"></a></h2>
+<h2 id="work-in-progress-wzxhzdk15wzxhzdk16">Work In Progress # <a id="status-wip"></a></h2>
+<h2 id="completed-wzxhzdk17wzxhzdk18">Completed # <a id="status-complete"></a></h2>
<ul>
<li>
<p>better handling of unknown xml and xml from an unknown namespace</p>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/pdf-library.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/pdf-library.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/pdf-library.html Tue Oct 23 15:07:21 2012
@@ -331,28 +331,28 @@ $(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"><p><version>$Revision: 1298724 $</version></p>
-<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="intro"></a></h1>
<p>The PDF Library is an independant package of classes in Apache™ 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>
-<h1 id="pdf-document-wzxhzdk5wzxhzdk6">PDF Document <a id="#PDF+Document"></a></h1>
+<h1 id="pdf-document-wzxhzdk5wzxhzdk6">PDF Document <a id="PDF+Document"></a></h1>
<p>This is where most of the document is created and put together.</p>
<p>It sets up the header, trailer and resources. Each page is made and added to the document. There are a number of methods that can be used to create/add certain PDF objects to the document.</p>
-<h1 id="building-pdf-wzxhzdk7wzxhzdk8">Building PDF <a id="#Building+PDF"></a></h1>
+<h1 id="building-pdf-wzxhzdk7wzxhzdk8">Building PDF <a id="Building+PDF"></a></h1>
<p>The PDF Document is built by creating a page for each page in the Area Tree.</p>
<p>This page then has all the contents added. The page is then added to the document and available objects can be written to the output stream.</p>
<p>The contents of the page are things such as text, lines, images etc. The PDFRenderer inserts the text directly into a pdf stream. The text consists of markup to set fonts, set text position and add text.</p>
<p>Most of the simple pdf markup is inserted directly into a pdf stream. Other more complex objects or commonly used objects are added through java classes. Some pdf objects such as an image consists of two parts.</p>
<p>It has a separate object for the image data and another bit of markup to display the image in a certain position on the page.</p>
<p>The java objects that represent a pdf object implement a method that returns the markup for inserting into a stream. The method is: byte[] toPDF().</p>
-<h1 id="features-wzxhzdk9wzxhzdk10">Features <a id="#Features"></a></h1>
-<h2 id="fonts-wzxhzdk11wzxhzdk12">Fonts # <a id="#Fonts"></a></h2>
+<h1 id="features-wzxhzdk9wzxhzdk10">Features <a id="Features"></a></h1>
+<h2 id="fonts-wzxhzdk11wzxhzdk12">Fonts # <a id="Fonts"></a></h2>
<p>Support for embedding fonts and using the default Acrobat fonts.</p>
-<h2 id="images-wzxhzdk13wzxhzdk14">Images # <a id="#Images"></a></h2>
+<h2 id="images-wzxhzdk13wzxhzdk14">Images # <a id="Images"></a></h2>
<p>Images can be inserted into a page. The image can either be inserted as a pixel map or directly insert a jpeg image.</p>
-<h2 id="stream-filters-wzxhzdk15wzxhzdk16">Stream Filters # <a id="#Stream+Filters"></a></h2>
+<h2 id="stream-filters-wzxhzdk15wzxhzdk16">Stream Filters # <a id="Stream+Filters"></a></h2>
<p>A number of filters are available to encode the pdf streams. These filters can compress the data or change it such as converting to hex.</p>
-<h2 id="links-wzxhzdk17wzxhzdk18">Links # <a id="#Links"></a></h2>
+<h2 id="links-wzxhzdk17wzxhzdk18">Links # <a id="Links"></a></h2>
<p>A pdf link can be added for an area on the page. This link can then point to an external destination or a position on any page in the document.</p>
-<h2 id="patterns-wzxhzdk19wzxhzdk20">Patterns # <a id="#Patterns"></a></h2>
+<h2 id="patterns-wzxhzdk19wzxhzdk20">Patterns # <a id="Patterns"></a></h2>
<p>The fill and stroke of graphical objects can be set with a colour, pattern or gradient.</p>
<p>The are a number of other features for handling pdf markup relevent to creating PDF files for FOP.</p></div>
</div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/properties.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/properties.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/properties.html Tue Oct 23 15:07:21 2012
@@ -331,9 +331,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"><p><version>$Revision: 1298724 $</version><authors><person email="" name="Karen Lease"></person></authors></p>
-<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h1>
<p>As the input XSL-FO is being parsed and the FO Tree is being built, the attributes of the FO elements are passed by the parser to the related FO object. The java object that represent the FO object then converts the attributes into properties that are stored in the FO Tree.</p>
-<h1 id="issues-wzxhzdk8wzxhzdk9">Issues <a id="#issues"></a></h1>
+<h1 id="issues-wzxhzdk8wzxhzdk9">Issues <a id="issues"></a></h1>
<p>The following are some issues when dealing with properties:</p>
<ul>
<li>
@@ -352,7 +352,7 @@ $(document).ready(function () {
<p>Expressions: XSL-FO expressions can be included in properties.</p>
</li>
</ul>
-<h1 id="overview-of-processing-wzxhzdk10wzxhzdk11">Overview of Processing <a id="#process-overview"></a></h1>
+<h1 id="overview-of-processing-wzxhzdk10wzxhzdk11">Overview of Processing <a id="process-overview"></a></h1>
<p>The general flow of property processing is as follows:</p>
<ul>
<li>
@@ -365,10 +365,10 @@ $(document).ready(function () {
<p>FObj.handleAttrs then cross-references the returned PropertyList with the FObj, creates a PropertyManager to facilitate downstream processing of the PropertyList, and handles the special case of the writing-mode property.</p>
</li>
</ul>
-<h1 id="propertylistbuilder-wzxhzdk12wzxhzdk13">PropertyListBuilder <a id="#plb"></a></h1>
+<h1 id="propertylistbuilder-wzxhzdk12wzxhzdk13">PropertyListBuilder <a id="plb"></a></h1>
<p>Each plb object contains a hash of property names and <em>their</em> respective Makers. It may also contain element-specific property maker hashes; these are based on the <em>local name</em> of the flow object, ie. <em>table-row</em> , not <em>fo:table-row</em> . If an element-specific property mapping exists, it is preferred to the generic mapping.</p>
<p>The PLB loops through each attribute in the list, finds an appropriate "Maker" for it, then calls the Maker to convert the attribute value into a Property object of the correct type, and stores that Property in the PropertyList.</p>
-<h1 id="property-datatypes-wzxhzdk14wzxhzdk15">Property datatypes <a id="#datatypes"></a></h1>
+<h1 id="property-datatypes-wzxhzdk14wzxhzdk15">Property datatypes <a id="datatypes"></a></h1>
<p>The property datatypes are defined in the org.apache.fop.datatypes package, except Number and String which are java primitives. The FOP datatypes are:</p>
<ul>
<li>
@@ -399,27 +399,27 @@ $(document).ready(function () {
<p>The <em>org.apache.fop.fo.Property</em> class is the superclass for all Property subclasses. There is a subclass for each kind of property datatype. These are named using the datatype name plus the word Property, resulting in NumberProperty, StringProperty, and so on. There is also a class EnumProperty which uses an <code>int</code> primitive to hold enumerated values. There is no corresponding Enum datatype class.</p>
<p>The Property class provides a "wrapper" around any possible property value. Code manipulating property values (in layout for example) usually knows what kind (or kinds) of datatypes are acceptable for a given property and will use the appropriate accessor.</p>
<p>The base Property class defines accessor methods for all FO property datatypes, such as getNumber(), getColorType(), getSpace(), getEnum(), etc. It doesn't define accessors for SVG types, since these are handled separately (at least for now.) In the base Property class, all of these methods return null, except getEnum which returns 0. Individual subclasses return a value of the appropriate type, such as Length or ColorType. A subclass may also choose to return a reasonable value for other accessor types. For example, a SpaceProperty will return the optimum value if asked for a Length.</p>
-<h1 id="property-makers-wzxhzdk16wzxhzdk17">Property Makers <a id="#makers"></a></h1>
+<h1 id="property-makers-wzxhzdk16wzxhzdk17">Property Makers <a id="makers"></a></h1>
<p>The Property class contains a nested class called <em>Maker</em> . This is the base class for all other property Makers. It provides basic framework functionality which is overridden by the code generated by properties.xsl from the *properties.xml files. In particular it provides basic expression evaluation, using PropertyParser class in the org.apache.fop.fo.expr package.</p>
<p>Other Property subclasses such as LengthProperty define their own nested Maker classes (subclasses of Property.Maker). These handle conversion from the Property subclass returned from expression evaluation into the appropriate subclass for the property.</p>
<p>For each generic or specific property definition in the properties.xml files, a new subclass of one of the Maker classes is created. Note that no new Property subclasses are created, only new PropertyMaker subclasses. Once the property value has been parsed and stored, it has no specific functionality. Only the Maker code is specific. Maker subclasses define such aspects as keyword substitutions, whether the property can be inherited or not, which enumerated values are legal, default values, corresponding properties and specific datatype conversions.</p>
<p>The PLB finds a "Maker" for the property based on the attribute name and the element name. Most Makers are generic and handle the attribute on any element, but it's possible to set up an element-specific property Maker. The attribute name to Maker mappings are automatically created during the code generation phase by processing the XML property description files.</p>
-<h1 id="processing-the-attribute-list-wzxhzdk18wzxhzdk19">Processing the attribute list <a id="#attribute-list"></a></h1>
+<h1 id="processing-the-attribute-list-wzxhzdk18wzxhzdk19">Processing the attribute list <a id="attribute-list"></a></h1>
<p>The PLB first looks to see if the font-size property is specified, since it sets up relative units which can be used in other property specifications. Each attribute is then handled in turn. If the attribute specifies part of a compound property such as space-before.optimum, the PLB looks to see if the attribute list also contains the "base" property (space-before in this case) and processes that first.</p>
-<h1 id="how-the-property-maker-works-wzxhzdk20wzxhzdk21">How the Property Maker works <a id="#maker-design"></a></h1>
+<h1 id="how-the-property-maker-works-wzxhzdk20wzxhzdk21">How the Property Maker works <a id="maker-design"></a></h1>
<p>There is a family of Maker objects for each of the property datatypes, such as Length, Number, Enumerated, Space, etc. But since each Property has specific aspects such as whether it's inherited, its default value, its corresponding properties, etc. there is usually a specific Maker for each Property. All these Maker classes are created during the code generation phase by processing (using XSLT) the XML property description files to create Java classes.</p>
<p>The Maker first checks for "keyword" values for a property. These are things like "thin, medium, thick" for the border-width property. The datatype is really a Length but it can be specified using these keywords whose actual value is determined by the "User Agent" rather than being specified in the XSL standard. For FOP, these values are currently defined in foproperties.xml. The keyword value is just a string, so it still needs to be parsed as described next.</p>
<p>The Maker also checks to see if the property is an Enumerated type and then checks whether the value matches one of the specified enumeration values.</p>
<p>Otherwise the Maker uses the property parser in the fo.expr package to evaluate the attribute value and return a Property object. The parser interprets the expression language and performs numeric operations and function call evaluations.</p>
<p>If the returned Property value is of the correct type (specificed in foproperties.xml, where else?), the Maker returns it. Otherwise, it may be able to convert the returned type into the correct type.</p>
<p>Some kinds of property values can't be fully resolved during FO tree building because they depend on layout information. This is the case of length values specified as percentages and of the special proportional-column-width(x) specification for table-column widths. These are stored as special kinds of Length objects which are evaluated during layout. Expressions involving "em" units which are relative to font-size <em>are</em> resolved during the FO tree building however.</p>
-<h1 id="structure-of-the-propertylist-wzxhzdk22wzxhzdk23">Structure of the PropertyList <a id="#property-list-struct"></a></h1>
+<h1 id="structure-of-the-propertylist-wzxhzdk22wzxhzdk23">Structure of the PropertyList <a id="property-list-struct"></a></h1>
<p>The PropertyList extends HashMap and its basic function is to associate Property value objects with Property names. The Property objects are all subclasses of the base Property class. Each one simply contains a reference to one of the property datatype objects. Property provides accessors for all known datatypes and various subclasses override the accessor(s) which are reasonable for the datatype they store.</p>
<p>The PropertyList itself provides various ways of looking up Property values to handle such issues as inheritance and corresponding properties.</p>
<p>The main logic is:<br></br>If the property is a writing-mode relative property (using start, end, before or after in its name), the corresponding absolute property value is returned if it's explicitly set on this FO.<br></br>Otherwise, the writing-mode relative value is returned if it's explicitly set. If the property is inherited, the process repeats using the PropertyList of the FO's parent object. (This is easy because each PropertyList points to the PropertyList of the nearest ancestor FO.) If the property isn't inherited or no value is found at any level, the initial value is returned.</p>
-<h1 id="implementing-standard-properties-wzxhzdk28wzxhzdk29">Implementing Standard Properties <a id="#property-spec"></a></h1>
+<h1 id="implementing-standard-properties-wzxhzdk28wzxhzdk29">Implementing Standard Properties <a id="property-spec"></a></h1>
<p>Because the properties defined in the standard are basically static, FOP currently builds the source code for the related Property classes from an XML data file. All properties are specified in src/codegen/foproperties.xml. The related classes are created automatically during the build process by applying an XSLT stylesheet to the foproperties.xml file.</p>
-<h2 id="generic-properties-wzxhzdk30wzxhzdk31">Generic properties # <a id="#generic"></a></h2>
+<h2 id="generic-properties-wzxhzdk30wzxhzdk31">Generic properties # <a id="generic"></a></h2>
<p>In the properties xml files, one can define generic property definitions which can serve as a basis for individual property definitions. There are currently several generic properties defined in foproperties.xml. An example is GenericColor, which defines basic properties for all ColorType properties. Since the generic specification doesn't include the inherited or default elements, these should be set in each property which is based on GenericColor. Here is an example:</p>
<p><code><property type='generic'>
<name>background-color</name>
@@ -433,23 +433,23 @@ $(document).ready(function () {
<p>When a property includes a "use-generic" element and includes no other elements (except the "name" element), then no class is generated for the property. Instead the generated mapping will associate this property directly with an instance of the generic Maker.</p>
<p>A generic class may also be hand-coded, rather than generated from the properties file. Properties based on such a generic class are indicated by the attribute <code>ispropclass='true'</code> on the <em>use-generic</em> element.</p>
<p>This is illustrated by the SVG properties, most of which use one of the Property subclasses defined in the <em>org.apache.fop.svg</em> package. Although all of these properties are now declared in svgproperties.xml, no specific classes are generated. Classes are only generated for those SVG properties which are not based on generic classes defined in svg.</p>
-<h2 id="element-specific-properties-wzxhzdk32wzxhzdk33">Element-specific properties # <a id="#element-specific"></a></h2>
+<h2 id="element-specific-properties-wzxhzdk32wzxhzdk33">Element-specific properties # <a id="element-specific"></a></h2>
<p>Properties may be defined for all flow objects or only for particular flow objects. A PropertyListBuilder object will always look first for a Property.Maker for the flow object before looking in the general list. These are specified in the <code>element-property-list</code> section of the properties.xml files. The <code>localname</code> element children of this element specify for which flow-object elements the property should be registered.</p>
<p><em>NOTE</em> : All the properties for an object or set of objects must be specified in a single element-property-list element. If the same localname appears in several element lists, the later set of properties will hide the earlier ones! Use the <em>ref</em> functionality if the same property is to be used in different sets of element-specific mappings.</p>
-<h2 id="reference-properties-wzxhzdk34wzxhzdk35">Reference properties # <a id="#reference"></a></h2>
+<h2 id="reference-properties-wzxhzdk34wzxhzdk35">Reference properties # <a id="reference"></a></h2>
<p>A property element may have a type attribute with the value <code>ref</code> . The content of the <em>name</em> child element is the name of the referenced property (not its class-name!). This indicates that the property specification has already been given, either in this same specification file or in a different one (indicated by the <code>family</code> attribute). The value of the family attribute is <em>XX</em> where the file <em>XXproperties.xml</em> defines the referenced property. For example, some SVG objects may have properties defined for FO. Rather than defining them again with a new name, the SVG properties simply reference the defined FO properties. The generating mapping for the SVG properties will use the FO Maker classes.</p>
-<h2 id="corresponding-properties-wzxhzdk36wzxhzdk37">Corresponding properties # <a id="#corresponding"></a></h2>
+<h2 id="corresponding-properties-wzxhzdk36wzxhzdk37">Corresponding properties # <a id="corresponding"></a></h2>
<p>Some properties have both <em>absolute</em> and <em>writing-mode-relative</em> forms. In general, the absolute forms are equivalent to CSS properties, and the writing-mode-relative forms are based on DSSSL. FO files may use either or both forms. In FOP code, a request for an absolute form will retrieve that value if it was specified on the FO; otherwise the corresponding relative property will be used if it was specified. However, a request for a relative form will only use the specified relative value if the corresponding absolute value was <em>not</em> specified for that FO.</p>
<p>Corresponding properties are specified in the properties.xml files using the element <code>corresponding</code> , which has at least one <code>propval</code> child and may have a <code>propexpr</code> child, if the corresponding value is calculated based on several other properties, as for <code>start-indent</code> .</p>
<p><em>NOTE</em> : most current FOP code accesses the absolute variants of these properties, notably for padding, border, height and width attributes. However it does use start-indent and end-indent, rather than the "absolute" margin properties.</p>
-<h1 id="mapping-wzxhzdk38wzxhzdk39">Mapping <a id="#mapping"></a></h1>
+<h1 id="mapping-wzxhzdk38wzxhzdk39">Mapping <a id="mapping"></a></h1>
<p>The XSL script <code>propmap.xsl</code> is used to generate property mappings based on both foproperties.xml and svgproperties.xml. The mapping classes in the main fop packages simply load these automatically generated mappings. The mapping code still uses the static "maker" function of the generated object to obtain a Maker object. However, for all generated classes, this method returns an instance of the class itself (which is a subclass of Property.Maker) and not an instance of a separate nested Maker class.</p>
<p>For most SVG properties which use the SVG Property classes directly, the generated mapper code calls the "maker" method of the SVG Property class, which returns an instance of its nested Maker class.</p>
<p>The property generation also handles element-specific property mappings as specified in the properties XML files.</p>
-<h1 id="enumerated-values-wzxhzdk40wzxhzdk41">Enumerated values <a id="#enumerated"></a></h1>
+<h1 id="enumerated-values-wzxhzdk40wzxhzdk41">Enumerated values <a id="enumerated"></a></h1>
<p>For any property whose datatype is <code>Enum</code> or which contains possible enumerated values, FOP code may need to access enumeration constants. These are defined in the interfaces whose name is the same as the generated class name for the property, for example <code>BorderBeforeStyle.NONE</code> . These interface classes are generated by the XSL script <code>enumgen.xsl</code> . A separate interface defining the enumeration constants is always generated for every property which uses the constants, even if the constants themselves are defined in a generic class, as in BorderStyle.</p>
<p>If a subproperty or component of a compound property has enumerated values, the constants are defined in a nested interface whose name is the name of the subproperty (using appropriate capitalization rules). For example, the keep properties may have values of AUTO or FORCE or an integer value. These are defined for each kind of keep property. For example, the keep-together property is a compound property with the components within-line, within-column and within-page. Since each component may have the values AUTO or FORCE, the KeepTogether interface defines three nested interfaces, one for each component, and each defines these two constants. An example of a reference in code to the constant is <code>KeepTogether.WithinPage.AUTO</code> .</p>
-<h1 id="compound-property-types-wzxhzdk42wzxhzdk43">Compound property types <a id="#compound"></a></h1>
+<h1 id="compound-property-types-wzxhzdk42wzxhzdk43">Compound property types <a id="compound"></a></h1>
<p>Some XSL FO properties are specified by compound datatypes. In the FO file, these are defined by a group of attributes, each having a name of the form <code>property.component</code> , for example <code>space-before.minimum</code> . These are several compound datatypes:</p>
<ul>
<li>
@@ -467,9 +467,9 @@ $(document).ready(function () {
</ul>
<p>These are described in the properties.xml files using the element <code>compound</code> which has <code>subproperty</code> children. A subproperty element is much like a property element, although it may not have an <code>inherited</code> child element, as only a complete property object may be inherited.</p>
<p>Specific datatype classes exist for each compound property. Each component of a compound datatype is itself stored as a Property object. Individual components may be accessed either by directly performing a get operation on the name, using the "dot" notation, eg. <code>get("space-before.optimum")</code> ; or by using an accessor on the compound property, eg. <code>get("space-before").getOptimum()</code> . In either case, the result is a Property object, and the actual value may be accessed (in this example) by using the "getLength()" accessor.</p>
-<h1 id="refinement-wzxhzdk44wzxhzdk45">Refinement <a id="#refine"></a></h1>
+<h1 id="refinement-wzxhzdk44wzxhzdk45">Refinement <a id="refine"></a></h1>
<p>The <strong>Refinement</strong> step is part of reading and using the properties which may happen immediately or during the layout process. FOP does not currently use a separate Refinement process, but tends to handle refining steps as the FO Tree is built.</p>
-<h1 id="refined-fo-tree-wzxhzdk46wzxhzdk47">Refined FO Tree <a id="#refined-fo-tree"></a></h1>
+<h1 id="refined-fo-tree-wzxhzdk46wzxhzdk47">Refined FO Tree <a id="refined-fo-tree"></a></h1>
<p>The Refined FO Tree is the result of the Refinement process.</p></div>
</div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/renderers.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/renderers.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/renderers.html Tue Oct 23 15:07:21 2012
@@ -331,25 +331,25 @@ $(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"><p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h1>
<p>A renderer is primarily designed to convert a given area tree into the output document format. It should be able to produce pages and fill the pages with the text and graphical content. Usually the output is sent to an output stream.</p>
<p>Some output formats may support extra information that is not available from the area tree or depends on the destination of the document.</p>
<p>Each renderer is given an area tree to render to its output format. The area tree is simply a representation of the pages and the placement of text and graphical objects on those pages.</p>
<p>The renderer will be given each page as it is ready and an output stream to write the data out. All pages are supplied in the order they appear in the document. In order to save memory it is possble to render the pages out of order. Any page that is not ready to be rendered is setup by the renderer first so that it can reserve a space 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>
-<h1 id="design-issues-wzxhzdk8wzxhzdk9">Design Issues <a id="#issues"></a></h1>
-<h2 id="renderers-are-responsible-wzxhzdk10wzxhzdk11">Renderers are Responsible # <a id="#issue-renderers-responsible"></a></h2>
+<h1 id="design-issues-wzxhzdk8wzxhzdk9">Design Issues <a id="issues"></a></h1>
+<h2 id="renderers-are-responsible-wzxhzdk10wzxhzdk11">Renderers are Responsible # <a id="issue-renderers-responsible"></a></h2>
<p>Each renderer is totally responsible for its output format.</p>
-<h2 id="send-output-to-a-stream-wzxhzdk12wzxhzdk13">Send Output to a Stream # <a id="#issue-output-stream"></a></h2>
-<h1 id="fonts-wzxhzdk14wzxhzdk15">Fonts <a id="#fonts"></a></h1>
+<h2 id="send-output-to-a-stream-wzxhzdk12wzxhzdk13">Send Output to a Stream # <a id="issue-output-stream"></a></h2>
+<h1 id="fonts-wzxhzdk14wzxhzdk15">Fonts <a id="fonts"></a></h1>
<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 during the layout process to determine the size of characters.</p>
-<h1 id="render-context-wzxhzdk16wzxhzdk17">Render Context <a id="#context"></a></h1>
+<h1 id="render-context-wzxhzdk16wzxhzdk17">Render Context <a id="context"></a></h1>
<p>The render context is used by handlers. It contains information about the current state of the renderer, such as the page, the position, and any other miscellanous objects that are required to draw into the page.</p>
-<h1 id="xml-handling-wzxhzdk18wzxhzdk19">XML Handling <a id="#XML+Handling"></a></h1>
+<h1 id="xml-handling-wzxhzdk18wzxhzdk19">XML Handling <a id="XML+Handling"></a></h1>
<p>A document may contain information in the form of XML for an image or instream foreign object. This XML is handled through the user agent. A standard extension for PDF is the SVG handler.</p>
<p>If there is XML in the SVG namespace it is given to the handler which renders the SVG into the pdf document at the given location. This separation means that other XML handlers can easily be added.</p>
-<h1 id="extensions-wzxhzdk20wzxhzdk21">Extensions <a id="#Extensions"></a></h1>
+<h1 id="extensions-wzxhzdk20wzxhzdk21">Extensions <a id="Extensions"></a></h1>
<p>Document level extensions are handled with an extension handler. This handles the information from the AreaTree and adds renders it to the document. An example is the pdf bookmarks. This information first needs to have all references resolved. Then the extension handler is ready to put the information into the pdf document.</p>
-<h1 id="renderer-implementations-wzxhzdk22wzxhzdk23">Renderer Implementations <a id="#implement"></a></h1>
+<h1 id="renderer-implementations-wzxhzdk22wzxhzdk23">Renderer Implementations <a id="implement"></a></h1>
<table>
<thead>
<tr>
@@ -444,7 +444,7 @@ $(document).ready(function () {
</tr>
</tbody>
</table>
-<h1 id="adding-a-renderer-wzxhzdk24wzxhzdk25">Adding a Renderer <a id="#add"></a></h1>
+<h1 id="adding-a-renderer-wzxhzdk24wzxhzdk25">Adding a Renderer <a id="add"></a></h1>
<p>You can add other renderers by implementing the Renderer interface. However, the AbstractRenderer does most of what is needed, including iterating through the tree parts, so it is probably better to extend this. This means that you only need to implement the basic functionality such as text, images, and lines. AbstractRenderer's methods can easily be overridden to handle things in a different way or do some extra processing.</p>
<p>The relevent AreaTree structures that will need to be rendered are:</p>
<ul>
@@ -485,12 +485,12 @@ $(document).ready(function () {
<p>draw various lines and rectangles</p>
</li>
</ul>
-<h1 id="multiple-renderers-wzxhzdk26wzxhzdk27">Multiple Renderers <a id="#multiple"></a></h1>
+<h1 id="multiple-renderers-wzxhzdk26wzxhzdk27">Multiple Renderers <a id="multiple"></a></h1>
<p>The layout of the document depends mainly on the font being used. If two renderers have the same font metrics then it is possible to use the same Area Tree to render both. This can be handled by the AreaTree Handler.</p>
-<h1 id="status-wzxhzdk28wzxhzdk29">Status <a id="#status"></a></h1>
-<h2 id="to-do-wzxhzdk30wzxhzdk31">To Do # <a id="#status-todo"></a></h2>
-<h2 id="work-in-progress-wzxhzdk32wzxhzdk33">Work In Progress # <a id="#status-wip"></a></h2>
-<h2 id="completed-wzxhzdk34wzxhzdk35">Completed # <a id="#status-complete"></a></h2>
+<h1 id="status-wzxhzdk28wzxhzdk29">Status <a id="status"></a></h1>
+<h2 id="to-do-wzxhzdk30wzxhzdk31">To Do # <a id="status-todo"></a></h2>
+<h2 id="work-in-progress-wzxhzdk32wzxhzdk33">Work In Progress # <a id="status-wip"></a></h2>
+<h2 id="completed-wzxhzdk34wzxhzdk35">Completed # <a id="status-complete"></a></h2>
<ul>
<li>
<p>new renderer model</p>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/startup.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/startup.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/startup.html Tue Oct 23 15:07:21 2012
@@ -331,10 +331,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"><p><version>$Revision: 1298724 $</version></p>
-<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="intro"></a></h1>
<p>Startup is the process of getting Apache™ FOP bootstrapped and creating basic objects. Environment includes acquiring user options, instantiating any frameworks, setting up logging, etc. Control includes the basic logic for tieing the various subsystems together properly.</p>
-<h1 id="status-wzxhzdk5wzxhzdk6">Status <a id="#status"></a></h1>
-<h2 id="to-do-wzxhzdk7wzxhzdk8">To Do # <a id="#status-todo"></a></h2>
+<h1 id="status-wzxhzdk5wzxhzdk6">Status <a id="status"></a></h1>
+<h2 id="to-do-wzxhzdk7wzxhzdk8">To Do # <a id="status-todo"></a></h2>
<ul>
<li>
<p>avalon integration - logging, configuration, component management, caching, uri resolver</p>
@@ -354,8 +354,8 @@ $(document).ready(function () {
<p>better commandline handling</p>
</li>
</ul>
-<h2 id="work-in-progress-wzxhzdk9wzxhzdk10">Work In Progress # <a id="#status-wip"></a></h2>
-<h2 id="completed-wzxhzdk11wzxhzdk12">Completed # <a id="#status-complete"></a></h2>
+<h2 id="work-in-progress-wzxhzdk9wzxhzdk10">Work In Progress # <a id="status-wip"></a></h2>
+<h2 id="completed-wzxhzdk11wzxhzdk12">Completed # <a id="status-complete"></a></h2>
<ul>
<li><strong>better image handling</strong> - redone so it can use a cache and synchronizes properly only on the current image while loading</li>
</ul></div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/svg.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/svg.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/svg.html Tue Oct 23 15:07:21 2012
@@ -331,27 +331,27 @@ $(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"><p><version>$Revision: 1298724 $</version></p>
-<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk2wzxhzdk3">Introduction <a id="intro"></a></h1>
<p>SVG is rendered through Apache™ 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 be rendered by the renderer.</p>
<p>SVG is rendered in the renderers via an XMLHandler in the FOUserAgent. This XML handler is used to render the SVG. The SVG is rendered by using batik. Batik converts the SVG DOM into an internal structure that can be drawn into a Graphics2D. So for PDF we use a PDFGraphics2D to draw into.</p>
<p>This creates the necessary PDF information 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>
-<h1 id="text-drawing-wzxhzdk5wzxhzdk6">Text Drawing <a id="#Text+Drawing"></a></h1>
+<h1 id="text-drawing-wzxhzdk5wzxhzdk6">Text Drawing <a id="Text+Drawing"></a></h1>
<p>Normally batik converts text into a set of curved shapes.</p>
<p>This is handled as any other shapes when rendering to the output. This is not always desirable as the shapes have very fine curves. This can cause the output to look a bit bad in PDF and PS (it can be drawn properly but is not by default). These curves also require much more data than the original text.</p>
<p>To handle this there is a PDFTextElementBridge that is set when using the bridge in batik. If the text is simple enough for the text to be drawn in the PDF as with all other text then this sets the TextPainter to use the PDFTextPainter. This inserts the text directly into the PDF using the drawString method on the PDFGraphics2D.</p>
<p>Text is considered simple if the font is available, the font size is useable and there are no tspans or other complications. This can make the resulting PDF significantly smaller.</p>
-<h1 id="pdf-links-wzxhzdk7wzxhzdk8">PDF Links <a id="#PDF+Links"></a></h1>
+<h1 id="pdf-links-wzxhzdk7wzxhzdk8">PDF Links <a id="PDF+Links"></a></h1>
<p>To support links in PDF another batik element bridge is used. The PDFAElementBridge creates a PDFANode which inserts a link into the PDF document via the PDFGraphics2D.</p>
<p>Since links are positioned on the page without any transforms then we need to transform the coordinates of the link area so that they match the current position of the a element area. This transform may also need to account for the svg being positioned on the page.</p>
-<h1 id="images-wzxhzdk9wzxhzdk10">Images <a id="#Images"></a></h1>
+<h1 id="images-wzxhzdk9wzxhzdk10">Images <a id="Images"></a></h1>
<p>Images are normally drawn into the PDFGraphics2D. This then creates a bitmap of the image data that can be inserted into the PDF document.</p>
<p>As PDF can support jpeg images then another element bridge is used so that the jpeg can be directly inserted into the PDF.</p>
-<h1 id="pdf-transcoder-wzxhzdk11wzxhzdk12">PDF Transcoder <a id="#PDF+Transcoder"></a></h1>
+<h1 id="pdf-transcoder-wzxhzdk11wzxhzdk12">PDF Transcoder <a id="PDF+Transcoder"></a></h1>
<p>Batik provides a mechanism to convert SVG into various formats. Through FOP we can convert an SVG document into a single paged PDF document. The page contains the SVG drawn as best as possible on the page. There is a PDFDocumentGraphics2D that creates a standalone PDF document with a single page. This is then drawn into by batik in the same way as with the PDFGraphics2D.</p>
-<h1 id="other-outputs-wzxhzdk13wzxhzdk14">Other Outputs <a id="#Other+Outputs"></a></h1>
+<h1 id="other-outputs-wzxhzdk13wzxhzdk14">Other Outputs <a id="Other+Outputs"></a></h1>
<p>When rendering to AWT the SVG is simply drawn onto the 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></div>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/design/useragent.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/design/useragent.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/design/useragent.html Tue Oct 23 15:07:21 2012
@@ -331,7 +331,7 @@ $(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"><p><version>$Revision: 1298724 $</version><authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors></p>
-<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="#intro"></a></h1>
+<h1 id="introduction-wzxhzdk6wzxhzdk7">Introduction <a id="intro"></a></h1>
<p>Technically the user agent is Apache™ FOP in the role of determining the output format and when resolving various attributes. The user agent is represented by a class that is available to others to specify how FOP should behave.</p>
<p>The user agent is used by the formatting process to determine certain user definable values.</p>
<p>It will enable the customisation of values for generating and rendering the document.</p>
Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/doc.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/doc.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/doc.html Tue Oct 23 15:07:21 2012
@@ -331,13 +331,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></div> -->
<div class="section-content"><p><version>$Revision: 1298724 $</version></p>
-<h1 id="general-information-wzxhzdk2wzxhzdk3">General Information <a id="#general"></a></h1>
+<h1 id="general-information-wzxhzdk2wzxhzdk3">General Information <a id="general"></a></h1>
<p>All raw documentation content is managed in the Apache™ FOP SVN repository. Updates should be committed to the repository, then the repository files are used to generate usable output. The remaining discussions on this page assume that the SVN repository is the starting place for processing. The path to the documentation is src/documentation/content/xdocs.
All documentation is maintained on the trunk.
Basic documents are stored in XML files, and use DTDs provided by Apache Forrest.</p>
-<h1 id="design-principles-wzxhzdk5wzxhzdk6">Design Principles <a id="#design"></a></h1>
+<h1 id="design-principles-wzxhzdk5wzxhzdk6">Design Principles <a id="design"></a></h1>
<p>These principles are not written in stone, but reflect the current philosophy, and are documented here primarily to help achieve consistency. These principles should be changed if better or more practical ones are found, but they should probably be discussed and changed by common consent.</p>
-<h2 id="where-wzxhzdk7wzxhzdk8">Where # <a id="#where"></a></h2>
+<h2 id="where-wzxhzdk7wzxhzdk8">Where # <a id="where"></a></h2>
<ul>
<li>
<p>To the extent possible, keep user content separate from developer content, primarily so the user doesn't have to filter out technical information.</p>
@@ -346,11 +346,11 @@ Basic documents are stored in XML files,
<p>To the extent possible, try to document a topic exactly once, in the place the user is most likely to look for it, then link to that from other locations as appropriate. This is somewhat contrary to the principle above, which should be applied as a higher priority.</p>
</li>
</ul>
-<h2 id="when-wzxhzdk9wzxhzdk10">When # <a id="#design-when"></a></h2>
+<h2 id="when-wzxhzdk9wzxhzdk10">When # <a id="design-when"></a></h2>
<p>The documentation and the product are in a constant state of change, and there is some difficulty in deciding what product state the website content should reflect. The current thinking is that the website should reflect the current state of the repository code branch from which releases are made. Features or other documentation that applies to unreleased code should be marked in such a way within the content that the user can determine whether and how it applies to the version they are using. For example, "Feature xyz is first available in Release n.nn.n".</p>
<p>Other approaches were considered, but all seemed to have significantly higher costs both to the users and the developers. From the user's standpoint, the choice is either that they potentially have to look multiple places to get the information they need (which was rejected), or they have to filter out an occasional feature that is in code available subsequent to their release (which was accepted).</p>
-<h1 id="website-wzxhzdk11wzxhzdk12">Website <a id="#web"></a></h1>
-<h2 id="background-wzxhzdk13wzxhzdk14">Background # <a id="#web-background"></a></h2>
+<h1 id="website-wzxhzdk11wzxhzdk12">Website <a id="web"></a></h1>
+<h2 id="background-wzxhzdk13wzxhzdk14">Background # <a id="web-background"></a></h2>
<p>The FOP web site and documentation are generated using <a href="http://forrest.apache.org">Apache Forrest</a> .</p>
<p>The following table summarizes the flow of data to the FOP website in chronological order:</p>
<table>
@@ -388,7 +388,7 @@ Basic documents are stored in XML files,
<td></td>
</tr>
<tr>
-<td>## ForrestBot "publish" Step-by-Step # <a id="#web-forrestbot-publish"></a></td>
+<td>## ForrestBot "publish" Step-by-Step # <a id="web-forrestbot-publish"></a></td>
<td></td>
<td></td>
<td></td>
@@ -412,7 +412,7 @@ Please make sure you use Forrest from th
</li>
</ul>
<p>The reason for putting the generated website in the SVN repository: The infrastructure people want to be able to restore the websites themselves in case of a crash.</p>
-<h2 id="using-a-local-forrest-wzxhzdk15wzxhzdk16">Using a Local Forrest # <a id="#web-local-forrest"></a></h2>
+<h2 id="using-a-local-forrest-wzxhzdk15wzxhzdk16">Using a Local Forrest # <a id="web-local-forrest"></a></h2>
<p>To use a local Forrest (during website development, not for deployment):</p>
<ul>
<li>
@@ -435,10 +435,10 @@ Please make sure you use Forrest from th
You can use "forrest run" to start a local web server. That improves development speed as you can simply refresh in the browser after a change.</p>
</li>
</ul>
-<h2 id="updating-distribution-files-wzxhzdk17wzxhzdk18">Updating Distribution Files # <a id="#distribution"></a></h2>
+<h2 id="updating-distribution-files-wzxhzdk17wzxhzdk18">Updating Distribution Files # <a id="distribution"></a></h2>
<p>The Apache distribution system mirrors distributions around the world. Since it uses <a href="http://httpd.apache.org/">Apache httpd</a> Module <a href="http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html#headername">mod_autoindex</a> you also need to manually update the HEADER.html & READER.html files on <code>people.apache.org</code> in <code>/www/www.apache.org/dist/xmlgraphics/fop/</code> .</p>
<p>Please be careful when doing stuff like that.</p>
-<h2 id="deleting-documentation-files-wzxhzdk19wzxhzdk20">Deleting Documentation Files # <a id="#delete"></a></h2>
+<h2 id="deleting-documentation-files-wzxhzdk19wzxhzdk20">Deleting Documentation Files # <a id="delete"></a></h2>
<p>ForrestBot simply uploads the whole generated site. It doesn't delete obsolete files. You can do that manually in the /www/xmlgraphics.apache.org/fop folder on cvs.apache.org. Be careful when doing stuff like that.
Please make sure you always have <strong>group rw permissions on all files</strong> under the /www directory!</p></div>
</div>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org