xmlgraphics-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r835960 [11/18] - 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/
Date Wed, 24 Oct 2012 04:04:05 GMT
Modified: websites/staging/xmlgraphics/trunk/content/fop/changes.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/changes.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/changes.html Wed Oct 24 04:04:00 2012
@@ -330,11 +330,12 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a></div> -->
-      	<div class="section-content"><p><a href="changes.rss"></a> </p>
-<h1 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols  <a id="introduction"></a></h1>
+      	<div class="section-content"><h1 id="history-of-changes">History of Changes</h1>
+<p><a href="changes.rss"></a> </p>
+<h2 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols  <a id="introduction"></a></h2>
 <p>Changes are sorted by "type" and then chronologically with the most recent at the top. These symbols denote the various action types:<icon alt="add" src="images/add.jpg"></icon>=add,<icon alt="fix" src="images/fix.jpg"></icon>=fix,<icon alt="remove" src="images/remove.jpg"></icon>=remove,<icon alt="update" src="images/update.jpg"></icon>=update</p>
-<h1 id="version-fop-trunk-tbd-wzxhzdk10wzxhzdk11">Version FOP Trunk (TBD)  <a id="version_FOP Trunk"></a></h1>
-<h2 id="changes-to-the-code-base-wzxhzdk12wzxhzdk13">Changes to the Code Base # <a id="Code_FOP Trunk"></a></h2>
+<h2 id="version-fop-trunk-tbd-wzxhzdk10wzxhzdk11">Version FOP Trunk (TBD)  <a id="version_FOP Trunk"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk12wzxhzdk13">Changes to the Code Base # <a id="Code_FOP Trunk"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>A global setting to wrap F11 images in page segments. Committed by PH. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=49893">49893</a> .</p>
@@ -496,11 +497,11 @@ $(document).ready(function () {
 <p><icon alt="update" src="images/update.jpg"></icon>Add run target for embedded examples. Add increased JVM memory heap flag for example8 in case font cache is rebuilt. Committed by GA. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=51617">51617</a> .</p>
 </li>
 </ul>
-<h2 id="changes-to-the-user-configuration-wzxhzdk14wzxhzdk15">Changes to the User Configuration # <a id="Config_FOP Trunk"></a></h2>
+<h3 id="changes-to-the-user-configuration-wzxhzdk14wzxhzdk15">Changes to the User Configuration # <a id="Config_FOP Trunk"></a></h3>
 <ul>
 <li><icon alt="fix" src="images/fix.jpg"></icon>Bugfix: relative URIs in the configuration file (base, font-base, hyphenation-base) are evaluated relative to the base URI of the configuration file. Committed by SP.</li>
 </ul>
-<h2 id="changes-to-the-font-subsystem-wzxhzdk16wzxhzdk17">Changes to the Font Subsystem # <a id="Fonts_FOP Trunk"></a></h2>
+<h3 id="changes-to-the-font-subsystem-wzxhzdk16wzxhzdk17">Changes to the Font Subsystem # <a id="Fonts_FOP Trunk"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Add support for OpenType advanced typographic tables (GDEF, GSUB, GPOS). Committed by GA.</p>
@@ -539,7 +540,7 @@ $(document).ready(function () {
 <p><icon alt="fix" src="images/fix.jpg"></icon>Reinstated support for being able to specify a font cache filepath in the fop user configuration. Committed by AC.</p>
 </li>
 </ul>
-<h2 id="changes-to-the-layout-engine-wzxhzdk18wzxhzdk19">Changes to the Layout Engine # <a id="Layout_FOP Trunk"></a></h2>
+<h3 id="changes-to-the-layout-engine-wzxhzdk18wzxhzdk19">Changes to the Layout Engine # <a id="Layout_FOP Trunk"></a></h3>
 <ul>
 <li>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Bugzilla 50965: Fixed a regression in BlockContainerLayoutManager where margins were no longer reset after forced breaks. Committed by AD. Thanks to Martin Koegler. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=50965">50965</a> .</p>
@@ -575,7 +576,7 @@ $(document).ready(function () {
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fixed retrieval of available BPD for cases spanning columns and multiple pages with differing page masters. Committed by JM. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=49885">49885</a> .</p>
 </li>
 </ul>
-<h2 id="changes-to-renderers-output-formats-wzxhzdk20wzxhzdk21">Changes to Renderers (Output Formats) # <a id="Renderers_FOP Trunk"></a></h2>
+<h3 id="changes-to-renderers-output-formats-wzxhzdk20wzxhzdk21">Changes to Renderers (Output Formats) # <a id="Renderers_FOP Trunk"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Various bugfixes to make PDFDocumentGraphics2D operational again. Committed by JM.</p>
@@ -677,16 +678,16 @@ $(document).ready(function () {
 <p><icon alt="remove" src="images/remove.jpg"></icon>Removed old Renderer implementations for those output formats that have a version based on the new DocumentHandler architecture available (AFP, PCL, PDF, PS). Committed by VH.</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk22wzxhzdk23">Contributors to this release # <a id="contributors_FOP Trunk"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk22wzxhzdk23">Contributors to this release # <a id="contributors_FOP Trunk"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Adrian Cumiskey (AC), Andreas Delmelle (AD), Chris Bowditch (CB), Glenn Adams (GA), Jeremias Märki (JM), Mehdi Houshmand (MH), Peter Hancock (PH), (PH,VH), Simon Pepping (SP), Vincent Hennebert (VH).</p>
 <p>This is a list of other contributors:<br></br>Adrian Buza, Alberto Simões, Alexandros Papadakis, Alexios Giotis, Alexis Giotis, Andrejus Chaliapinas, Armin Haaf, Carsten Pfeiffer, Georg Datterl, Glenn Adams, JM, Mehdi Houshmand, Joshua Marquart, Julien Aymé, Luis Bernardo, Martin Koegler, Matthias Reischenbacher, Max Aster, Maximilian Aster, Mehdi Houshmand, Melanie Drake, mkoegler.AT.auto.tuwien.ac.at, Pascal Sancho, Patrick Jaromin, Paul Huemer, Peter Hancock, Sergey Vladimirov, Simon Pepping, VH and PH.</p>
-<h1 id="version-10-21-july-2010-wzxhzdk28wzxhzdk29">Version 1.0 (21 July 2010)  <a id="version_1.0"></a></h1>
-<h2 id="changes-to-the-end-user-api-wzxhzdk30wzxhzdk31">Changes to the End-User API # <a id="API_1.0"></a></h2>
+<h2 id="version-10-21-july-2010-wzxhzdk28wzxhzdk29">Version 1.0 (21 July 2010)  <a id="version_1.0"></a></h2>
+<h3 id="changes-to-the-end-user-api-wzxhzdk30wzxhzdk31">Changes to the End-User API # <a id="API_1.0"></a></h3>
 <ul>
 <li><icon alt="add" src="images/add.jpg"></icon>Added a command-line option '-catalog' to use a catalog resolver for the XML and XSLT files Committed by SP.</li>
 </ul>
-<h2 id="changes-to-the-code-base-wzxhzdk32wzxhzdk33">Changes to the Code Base # <a id="Code_1.0"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk32wzxhzdk33">Changes to the Code Base # <a id="Code_1.0"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added support for xmlfile and xsltfile parameters in FOP's Ant Task. Committed by AC.</p>
@@ -755,11 +756,11 @@ Committed by AD. Thanks to rogov.AT.deve
 <p><icon alt="update" src="images/update.jpg"></icon>Changed FONode.addCharacters() parameter to closer match the signature of the standard SAX characters() event (reduces confusion and computations). <em>!! Implementors of extensions that subclass FONode directly, and offer an implementation for addCharacters() should take care to make similar modifications in their code !!</em> Committed by AD.</p>
 </li>
 </ul>
-<h2 id="changes-to-the-bundled-extensions-wzxhzdk34wzxhzdk35">Changes to the Bundled Extensions # <a id="Extensions_1.0"></a></h2>
+<h3 id="changes-to-the-bundled-extensions-wzxhzdk34wzxhzdk35">Changes to the Bundled Extensions # <a id="Extensions_1.0"></a></h3>
 <ul>
 <li><icon alt="add" src="images/add.jpg"></icon>Added support for the #CMYK pseudo-profile supported by some commercial XSL implementations on the rgb-icc() function. Committed by JM.</li>
 </ul>
-<h2 id="changes-to-the-font-subsystem-wzxhzdk36wzxhzdk37">Changes to the Font Subsystem # <a id="Fonts_1.0"></a></h2>
+<h3 id="changes-to-the-font-subsystem-wzxhzdk36wzxhzdk37">Changes to the Font Subsystem # <a id="Fonts_1.0"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added support for TrueType fonts with symbol character maps (like "Wingdings" and "Symbol"). Character for these fonts are usually found in the 0xF020 to 0xF0FF range (a Unicode private use area). Committed by JM.</p>
@@ -813,7 +814,7 @@ Committed by AD. Thanks to rogov.AT.deve
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fix for PFMReader after bug #43089 changed the behavior of PFMFile. Fixes baseline problems when Type 1 fonts are used in conjunction with XML font metric files. Committed by JM. Thanks to J. Frantzius. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=45734">45734</a> .</p>
 </li>
 </ul>
-<h2 id="changes-to-the-image-support-wzxhzdk38wzxhzdk39">Changes to the Image Support # <a id="Images_1.0"></a></h2>
+<h3 id="changes-to-the-image-support-wzxhzdk38wzxhzdk39">Changes to the Image Support # <a id="Images_1.0"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added customization ability for the image loading framework from FOP's configuration file. Committed by JM.</p>
@@ -825,7 +826,7 @@ Committed by AD. Thanks to rogov.AT.deve
 <p><icon alt="fix" src="images/fix.jpg"></icon>Bugfix: use the effective color profile supplied by the ImageEncodingHelper, instead of the original one. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="changes-to-the-layout-engine-wzxhzdk40wzxhzdk41">Changes to the Layout Engine # <a id="Layout_1.0"></a></h2>
+<h3 id="changes-to-the-layout-engine-wzxhzdk40wzxhzdk41">Changes to the Layout Engine # <a id="Layout_1.0"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Implement internal character classes if the hyphenation pattern file does not contain them Committed by SP.</p>
@@ -921,7 +922,7 @@ Committed by AD. Thanks to rogov.AT.deve
 <p><icon alt="fix" src="images/fix.jpg"></icon>Activated min-height/max-height and min-width/max-width properties. Committed by AD. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=43591">43591</a> .</p>
 </li>
 </ul>
-<h2 id="changes-to-renderers-output-formats-wzxhzdk42wzxhzdk43">Changes to Renderers (Output Formats) # <a id="Renderers_1.0"></a></h2>
+<h3 id="changes-to-renderers-output-formats-wzxhzdk42wzxhzdk43">Changes to Renderers (Output Formats) # <a id="Renderers_1.0"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>AFP Output: Added enhanced dithering functionality for images that are converted to bi-level images. Committed by JM.</p>
@@ -1125,20 +1126,20 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>When a JPEG image is embedded, an optionally embedded color profile is filtered out as it's already embedded separately in the PDF file. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk44wzxhzdk45">Contributors to this release # <a id="contributors_1.0"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk44wzxhzdk45">Contributors to this release # <a id="contributors_1.0"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Adrian Cumiskey (AC), Andreas Delmelle (AD), Chris Bowditch (CB), Jeremias Märki (JM), (JM,VH), Luca Furini (LF), Max Berger (MB), Simon Pepping (SP), Vincent Hennebert (VH).</p>
 <p>This is a list of other contributors:<br></br>Alexander Stamenov, Alok Singh, Antti Karanta, Bharat Attaluri, Carsten Siedentop, D.W. Harks, Dario Laera, Emil Maskovsky, Francois Fernandes, Georg Datterl, Harald G. Henne, J. Frantzius, Jason Harrop, Jonathan Levinson, Jost Klopfstein, Martin Edge, Maxim Wirt, Nicolas Peninguy, Pavel Kysilka, Peter Coppens, Peter Hancock, Richard Wheeldon, rogov.AT.devexperts.com, Thomas Stieler, Tow Browder, Venkat Reddy, Yegor Kozlov.</p>
-<h1 id="version-095-05-august-2008-wzxhzdk50wzxhzdk51">Version 0.95 (05 August 2008)  <a id="version_0.95"></a></h1>
-<h2 id="changes-to-the-end-user-api-wzxhzdk52wzxhzdk53">Changes to the End-User API # <a id="API_0.95"></a></h2>
+<h2 id="version-095-05-august-2008-wzxhzdk50wzxhzdk51">Version 0.95 (05 August 2008)  <a id="version_0.95"></a></h2>
+<h3 id="changes-to-the-end-user-api-wzxhzdk52wzxhzdk53">Changes to the End-User API # <a id="API_0.95"></a></h3>
 <ul>
 <li><icon alt="fix" src="images/fix.jpg"></icon>Fixed the -imagein command-line option. Committed by JM.</li>
 </ul>
-<h2 id="changes-to-the-code-base-wzxhzdk54wzxhzdk55">Changes to the Code Base # <a id="Code_0.95"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk54wzxhzdk55">Changes to the Code Base # <a id="Code_0.95"></a></h3>
 <ul>
 <li><icon alt="fix" src="images/fix.jpg"></icon>Fixed potential multi-threading problem concerning the use of DecimalFormat. Committed by JM. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=44887">44887</a> .</li>
 </ul>
-<h2 id="changes-to-the-font-subsystem-wzxhzdk56wzxhzdk57">Changes to the Font Subsystem # <a id="Fonts_0.95"></a></h2>
+<h3 id="changes-to-the-font-subsystem-wzxhzdk56wzxhzdk57">Changes to the Font Subsystem # <a id="Fonts_0.95"></a></h3>
 <ul>
 <li>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fixed text extraction problem with ZapfDingbats and Symbol font in PDF output. Committed by JM.</p>
@@ -1147,7 +1148,7 @@ Committed by AD.</p>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fixed NullPointerException when loading a TrueType font using XML font metric files. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="changes-to-the-image-support-wzxhzdk58wzxhzdk59">Changes to the Image Support # <a id="Images_0.95"></a></h2>
+<h3 id="changes-to-the-image-support-wzxhzdk58wzxhzdk59">Changes to the Image Support # <a id="Images_0.95"></a></h3>
 <ul>
 <li>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fixed two bugs concerning resolution handling with SVG images and their conversion to bitmaps for RTF output. Committed by JM.</p>
@@ -1156,7 +1157,7 @@ Committed by AD.</p>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fixed a performance problem concerning image serialization. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="changes-to-the-layout-engine-wzxhzdk60wzxhzdk61">Changes to the Layout Engine # <a id="Layout_0.95"></a></h2>
+<h3 id="changes-to-the-layout-engine-wzxhzdk60wzxhzdk61">Changes to the Layout Engine # <a id="Layout_0.95"></a></h3>
 <ul>
 <li>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fixed NullPointerException when page-number-citations are used inside a marker. Committed by AD. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=45295">45295</a> .</p>
@@ -1168,7 +1169,7 @@ Committed by AD.</p>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Various bugfixes for table layout. Committed by VH. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=44621">44621</a> .</p>
 </li>
 </ul>
-<h2 id="changes-to-renderers-output-formats-wzxhzdk62wzxhzdk63">Changes to Renderers (Output Formats) # <a id="Renderers_0.95"></a></h2>
+<h3 id="changes-to-renderers-output-formats-wzxhzdk62wzxhzdk63">Changes to Renderers (Output Formats) # <a id="Renderers_0.95"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added support for fo:leader for RTF output (no full support!). Fixes problems with empty leaders being used to force empty lines among other issues. Committed by JM. Thanks to Maximilian Aster. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=43825">43825</a> .</p>
@@ -1201,16 +1202,16 @@ Committed by AD.</p>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Fixed regression causing bad positioning of block-containers if used as descendant of a table-cell. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk64wzxhzdk65">Contributors to this release # <a id="contributors_0.95"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk64wzxhzdk65">Contributors to this release # <a id="contributors_0.95"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Andreas Delmelle (AD), Jeremias Märki (JM), Vincent Hennebert (VH).</p>
 <p>This is a list of other contributors:<br></br>Maximilian Aster.</p>
-<h1 id="version-095beta-26-march-2008-wzxhzdk70wzxhzdk71">Version 0.95beta (26 March 2008)  <a id="version_0.95beta"></a></h1>
-<h2 id="changes-to-the-end-user-api-wzxhzdk72wzxhzdk73">Changes to the End-User API # <a id="API_0.95beta"></a></h2>
+<h2 id="version-095beta-26-march-2008-wzxhzdk70wzxhzdk71">Version 0.95beta (26 March 2008)  <a id="version_0.95beta"></a></h2>
+<h3 id="changes-to-the-end-user-api-wzxhzdk72wzxhzdk73">Changes to the End-User API # <a id="API_0.95beta"></a></h3>
 <ul>
 <li><icon alt="remove" src="images/remove.jpg"></icon>Removed deprecated methods in the "apps" package that were left-overs from the API discussions. Committed by JM.</li>
 </ul>
-<h2 id="changes-to-the-code-base-wzxhzdk74wzxhzdk75">Changes to the Code Base # <a id="Code_0.95beta"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk74wzxhzdk75">Changes to the Code Base # <a id="Code_0.95beta"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Turned on XInclude processing for the main source given on the command line. Committed by MB.</p>
@@ -1240,7 +1241,7 @@ Committed by AD.</p>
 <p><icon alt="fix" src="images/fix.jpg"></icon>Avoid a NullPointerException in AreaTreeHandler.endDocument(). Committed by JM. Thanks to David Delbecq. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=43910">43910</a> .</p>
 </li>
 </ul>
-<h2 id="changes-to-the-bundled-extensions-wzxhzdk76wzxhzdk77">Changes to the Bundled Extensions # <a id="Extensions_0.95beta"></a></h2>
+<h3 id="changes-to-the-bundled-extensions-wzxhzdk76wzxhzdk77">Changes to the Bundled Extensions # <a id="Extensions_0.95beta"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>New extension attribute fox:transform on fo:block-container allows free-form transformation (rotation, scaling etc.) of absolute and fixed block-containers. Supported only for PDF, PS and Java2D-based renderers. Committed by JM.</p>
@@ -1249,7 +1250,7 @@ Committed by AD.</p>
 <p><icon alt="add" src="images/add.jpg"></icon>Added new extension element: fox:external-document. It allows to add whole documents such as multi-page TIFF images to be inserted as peers to a page-sequence. Each image will make up an entire page. See the documentation for details. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="changes-to-the-font-subsystem-wzxhzdk78wzxhzdk79">Changes to the Font Subsystem # <a id="Fonts_0.95beta"></a></h2>
+<h3 id="changes-to-the-font-subsystem-wzxhzdk78wzxhzdk79">Changes to the Font Subsystem # <a id="Fonts_0.95beta"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added support for unusual font encodings (like for Symbol or Cyrillic fonts) of Type 1 fonts in PDF and PostScript output. Committed by JM.</p>
@@ -1282,11 +1283,11 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>Improved font auto-detection and handling of AWT-supplied fonts in order to achieve better results when using multiple output formats. Whenever possible, the font names appearing in the operating system can also be used in XSL-FO. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="changes-to-the-image-support-wzxhzdk80wzxhzdk81">Changes to the Image Support # <a id="Images_0.95beta"></a></h2>
+<h3 id="changes-to-the-image-support-wzxhzdk80wzxhzdk81">Changes to the Image Support # <a id="Images_0.95beta"></a></h3>
 <ul>
 <li><icon alt="fix" src="images/fix.jpg"></icon>A new image loading framework has been introduced to fix various problems with external graphics and improve performance. Committed by JM.</li>
 </ul>
-<h2 id="changes-to-the-layout-engine-wzxhzdk82wzxhzdk83">Changes to the Layout Engine # <a id="Layout_0.95beta"></a></h2>
+<h3 id="changes-to-the-layout-engine-wzxhzdk82wzxhzdk83">Changes to the Layout Engine # <a id="Layout_0.95beta"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added support for background on fo:table-column and fo:table-header/footer/body elements. Committed by VH.</p>
@@ -1403,7 +1404,7 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>PropertyCache phase 2:<br></br>• improvement of the PropertyCache itself should now guarantee acceptable performance of the static caches in multi-session environments, which is a possible problem with synchronizedMap.<br></br>• changed CommonFont to use the cache: added CachedCommonFont to contain the properties that are always cacheable CommonFont itself is only cached if the remaining properties are absolutes.<br></br>• changed CommonHyphenation, KeepProperty, ColorProperty and FontFamilyProperty to use the cache.<br></br>Committed by AD.</p>
 </li>
 </ul>
-<h2 id="changes-to-renderers-output-formats-wzxhzdk84wzxhzdk85">Changes to Renderers (Output Formats) # <a id="Renderers_0.95beta"></a></h2>
+<h3 id="changes-to-renderers-output-formats-wzxhzdk84wzxhzdk85">Changes to Renderers (Output Formats) # <a id="Renderers_0.95beta"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added an option to disable the default sRGB profile in PDF output for those who don't care about color fidelity, but care about PDF file size. Committed by JM.</p>
@@ -1463,12 +1464,12 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>PDF Transcoder (SVG) text painting has been completely rewritten. Except for some special cases (with filters for example), all text (including flow text) is now painted using PDF text operators. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk86wzxhzdk87">Contributors to this release # <a id="contributors_0.95beta"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk86wzxhzdk87">Contributors to this release # <a id="contributors_0.95beta"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Adrian Cumiskey (AC), Andreas Delmelle (AD), Jeremias Märki (JM), Max Berger (MB), Vincent Hennebert (VH).</p>
 <p>This is a list of other contributors:<br></br>Adrian Cumiskey, Andrejus Chaliapinas, Bruno Feurer, ckohrn.at.tng.de, David Churavy, David Delbecq, Gordon Cooke, Justus Piater, Max Berger, Patrick Jaromin, Stefan Ziel, V. Schappert.</p>
-<h1 id="version-094-24th-august-2007-wzxhzdk92wzxhzdk93">Version 0.94 (24th August 2007)  <a id="version_0.94"></a></h1>
-<h2 id="changes-to-the-code-base-wzxhzdk94wzxhzdk95">Changes to the Code Base # <a id="Code_0.94"></a></h2>
+<h2 id="version-094-24th-august-2007-wzxhzdk92wzxhzdk93">Version 0.94 (24th August 2007)  <a id="version_0.94"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk94wzxhzdk95">Changes to the Code Base # <a id="Code_0.94"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Support for keep-together.within-line="always". Committed by MM.</p>
@@ -1591,12 +1592,12 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>Use source resolution setting for bitmap images which don't provide their own resolution. Committed by JM. Thanks to Hussein Shafie. See Issue <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=42406">42406</a> .</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk96wzxhzdk97">Contributors to this release # <a id="contributors_0.94"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk96wzxhzdk97">Contributors to this release # <a id="contributors_0.94"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Andreas Delmelle (AD), Jay Bryant (JB), Jeremias Märki (JM), Luca Furini (LF), Manuel Mall (MM), Simon Pepping (SP), Vincent Hennebert (VH), (VH, JM).</p>
 <p>This is a list of other contributors:<br></br>Adrian Cumiskey, Erwin Tratar, Hussein Shafie, Martin Kögler, Max Berger, Paul Vinkenoog, Richard Wheeldon.</p>
-<h1 id="version-093-9-january-2007-wzxhzdk102wzxhzdk103">Version 0.93 (9 January 2007)  <a id="version_0.93"></a></h1>
-<h2 id="changes-to-the-code-base-wzxhzdk104wzxhzdk105">Changes to the Code Base # <a id="Code_0.93"></a></h2>
+<h2 id="version-093-9-january-2007-wzxhzdk102wzxhzdk103">Version 0.93 (9 January 2007)  <a id="version_0.93"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk104wzxhzdk105">Changes to the Code Base # <a id="Code_0.93"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added support for the use of Open Type fonts Committed by BD.</p>
@@ -1776,12 +1777,12 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>Content in block-containers makes better use of shrink to fit content vertically into the available area. This can be used indirectly to justify content vertically in a block-container. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk106wzxhzdk107">Contributors to this release # <a id="contributors_0.93"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk106wzxhzdk107">Contributors to this release # <a id="contributors_0.93"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Andreas Delmelle (AD), Bertrand Delacrétaz (BD), Jeremias Märki (JM), Manuel Mall (MM), Simon Pepping (SP).</p>
 <p>This is a list of other contributors:<br></br>Adam Strzelecki, Victor Mote, Dominic Brügger, Gary Reed, Gerhard Oettl, Gilles Beaugeais, Igor Istomin, Jeroen Meijer, Julien Aymé, Max Berger, Oliver Hernàndez Valls, Peter Coppens, Pierre-Henri Kraus, Richard Wheeldon.</p>
-<h1 id="version-092beta-18-apr-2006-wzxhzdk112wzxhzdk113">Version 0.92beta (18 Apr 2006)  <a id="version_0.92beta"></a></h1>
-<h2 id="changes-to-the-code-base-wzxhzdk114wzxhzdk115">Changes to the Code Base # <a id="Code_0.92beta"></a></h2>
+<h2 id="version-092beta-18-apr-2006-wzxhzdk112wzxhzdk113">Version 0.92beta (18 Apr 2006)  <a id="version_0.92beta"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk114wzxhzdk115">Changes to the Code Base # <a id="Code_0.92beta"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Initial support for page-position="last" added. Committed by JM.</p>
@@ -1937,12 +1938,12 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>Revision of refinement white-space handling. Committed by AD.</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk116wzxhzdk117">Contributors to this release # <a id="contributors_0.92beta"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk116wzxhzdk117">Contributors to this release # <a id="contributors_0.92beta"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Andreas Delmelle (AD), Jeremias Märki (JM), Luca Furini (LF), Manuel Mall (MM), Simon Pepping (SP).</p>
 <p>This is a list of other contributors:<br></br>Gerhard Oettl, Gerhard Oettl (gerhard.oettl.at.oesoft.at), Jirí Mareš, Max Berger, Richard Wheeldon.</p>
-<h1 id="version-091beta-23-dec-2005-wzxhzdk122wzxhzdk123">Version 0.91beta (23 Dec 2005)  <a id="version_0.91beta"></a></h1>
-<h2 id="changes-to-the-code-base-wzxhzdk124wzxhzdk125">Changes to the Code Base # <a id="Code_0.91beta"></a></h2>
+<h2 id="version-091beta-23-dec-2005-wzxhzdk122wzxhzdk123">Version 0.91beta (23 Dec 2005)  <a id="version_0.91beta"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk124wzxhzdk125">Changes to the Code Base # <a id="Code_0.91beta"></a></h3>
 <ul>
 <li>
 <p><icon alt="add" src="images/add.jpg"></icon>Added checks that warn about tables and block-containers that are wider than the available content area. Committed by JM.</p>
@@ -2053,27 +2054,27 @@ Committed by AD.</p>
 <p><icon alt="update" src="images/update.jpg"></icon>Improvements on leader painting in PDF output. Committed by JM.</p>
 </li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk126wzxhzdk127">Contributors to this release # <a id="contributors_0.91beta"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk126wzxhzdk127">Contributors to this release # <a id="contributors_0.91beta"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>Jeremias Märki (JM), (LF, MM), Manuel Mall (MM).</p>
 <p>This is a list of other contributors:<br></br>Tom Craddock.</p>
-<h1 id="version-090alpha1-22-nov-2005-wzxhzdk132wzxhzdk133">Version 0.90alpha1 (22 Nov 2005)  <a id="version_0.90alpha1"></a></h1>
-<h2 id="changes-to-the-code-base-wzxhzdk134wzxhzdk135">Changes to the Code Base # <a id="Code_0.90alpha1"></a></h2>
+<h2 id="version-090alpha1-22-nov-2005-wzxhzdk132wzxhzdk133">Version 0.90alpha1 (22 Nov 2005)  <a id="version_0.90alpha1"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk134wzxhzdk135">Changes to the Code Base # <a id="Code_0.90alpha1"></a></h3>
 <ul>
 <li><icon alt="update" src="images/update.jpg"></icon> <strong>Complete redesign of the FOP codebase</strong> in the period between Dec 2001 and Nov 2005. There are just too many changes to list here. If you like to know details, run <code>"svn log --verbose http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/"</code> . Committed by all.</li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk136wzxhzdk137">Contributors to this release # <a id="contributors_0.90alpha1"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk136wzxhzdk137">Contributors to this release # <a id="contributors_0.90alpha1"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>the FOP committers (all).</p>
-<h1 id="version-0205-18-july-2003-wzxhzdk140wzxhzdk141">Version 0.20.5 (18 July 2003)  <a id="version_0.20.5"></a></h1>
-<h2 id="changes-to-the-code-base-wzxhzdk142wzxhzdk143">Changes to the Code Base # <a id="Code_0.20.5"></a></h2>
+<h2 id="version-0205-18-july-2003-wzxhzdk140wzxhzdk141">Version 0.20.5 (18 July 2003)  <a id="version_0.20.5"></a></h2>
+<h3 id="changes-to-the-code-base-wzxhzdk142wzxhzdk143">Changes to the Code Base # <a id="Code_0.20.5"></a></h3>
 <ul>
 <li><icon alt="update" src="images/update.jpg"></icon>For the change log for the maintenance branch (where FOP 0.20.5 came from), please see the "CHANGES" file in the distribution, or <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/branches/fop-0_20_2-maintain/CHANGES?view=markup">the CHANGES file in the SVN repository</a> . Committed by all.</li>
 </ul>
-<h2 id="contributors-to-this-release-wzxhzdk144wzxhzdk145">Contributors to this release # <a id="contributors_0.20.5"></a></h2>
+<h3 id="contributors-to-this-release-wzxhzdk144wzxhzdk145">Contributors to this release # <a id="contributors_0.20.5"></a></h3>
 <p>We thank the following people for their contributions to this release.</p>
 <p>This is a list of all people who participated as committers:<br></br>the FOP committers (all).</p>
-<h1 id="all-committers-wzxhzdk148wzxhzdk149">All Committers  <a id="all-committers"></a></h1>
+<h2 id="all-committers-wzxhzdk148wzxhzdk149">All Committers  <a id="all-committers"></a></h2>
 <p>This is a list of all people who have ever participated as committers on this project.</p>
 <ul>
 <li>

Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/conventions.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/conventions.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/conventions.html Wed Oct 24 04:04:00 2012
@@ -330,9 +330,10 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/">Dev</a></div> -->
-      	<div class="section-content"><p><version>$Revision: 1298724 $</version></p>
+      	<div class="section-content"><h1 id="apachetm-fop-development-coding-conventions">Apache(tm) FOP Development: Coding Conventions</h1>
+<p><version>$Revision: 1298724 $</version></p>
 <p>Acknowledgement: Some content in this guide was adapted from other Apache&trade; projects such as Avalon, Cactus, Turbine and Velocity.</p>
-<h1 id="subversion-repository-wzxhzdk3wzxhzdk4">Subversion Repository  <a id="svn"></a></h1>
+<h2 id="subversion-repository-wzxhzdk3wzxhzdk4">Subversion Repository  <a id="svn"></a></h2>
 <p>Conventions in this section apply to Repository content, regardless of type:</p>
 <ul>
 <li>
@@ -345,8 +346,8 @@ $(document).ready(function () {
 <p>In order to be able to discern commits from a committer from those where a committer applied a patch from a contributor, the commit message must contain a separate line following this pattern: <strong>"Submitted by: [contributor's name] &lt;[contributor's obfuscated e-mail address]&gt;"</strong> . This also helps doing audits on the repository.</p>
 </li>
 </ul>
-<h1 id="java-wzxhzdk5wzxhzdk6">Java  <a id="java"></a></h1>
-<h2 id="java-style-wzxhzdk7wzxhzdk8">Java Style # <a id="java-style"></a></h2>
+<h2 id="java-wzxhzdk5wzxhzdk6">Java  <a id="java"></a></h2>
+<h3 id="java-style-wzxhzdk7wzxhzdk8">Java Style # <a id="java-style"></a></h3>
 <p>In order to facilitate the human reading of FOP source code, reduce churning in code, and prevent disputes, the FOP developers have agreed on a set of coding conventions. The basis of these coding conventions is documented in the <a href="http://xml.apache.org/source.html">Apache XML Project Guidelines</a> , which requires that <strong>all Java Language source code in the repository must be written in conformance to Sun's</strong>  <a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Code Conventions for the Java Programming Language</a> . In addition, the FOP developers have agreed to other conventions, which are summarized in the following table:</p>
 <table>
 <thead>
@@ -410,11 +411,11 @@ $(document).ready(function () {
 </tbody>
 </table>
 <p>For developers that dislike these conventions, one workaround is to develop using their own style, then use a formatting tool like <a href="http://astyle.sourceforge.net/">astyle</a> (Artistic Style) before committing.</p>
-<h2 id="checkstyle-wzxhzdk9wzxhzdk10">Checkstyle # <a id="java-checkstyle"></a></h2>
+<h3 id="checkstyle-wzxhzdk9wzxhzdk10">Checkstyle # <a id="java-checkstyle"></a></h3>
 <p>The java syntax checker "<jump href="http://checkstyle.sourceforge.net">Checkstyle</jump>" is used to enforce many of the FOP coding standards. The standards enforced through Checkstyle are documented in its configuration file (xml-fop/checkstyle.cfg). The conventions defined in the configuration file are an integral part of FOP's coding conventions, and should not be changed without common consent. In other words, the configuration file contains additional conventions that are not documented on this page, but are generally accepted as good style within the java community (i.e. they are the default behavior of checkstyle, which the FOP developers have decided to adopt <em>de facto</em> ). Any apparent contradiction between the configuration file and this document should be raised on the fop-dev mailing list so that it can be clarified.</p>
 <p>To use the "checkstyle" target in FOP's build process, download the source from the<jump href="http://checkstyle.sourceforge.net">Checkstyle web site</jump>, place checkstyle-all-*.jar in the lib directory and call "build checkstyle". Output (in the build directory) includes checkstyle_report.txt and checkstyle_report.xml. If you copy the file contrib/checkstyle-noframes.xsl from Checkstyle into FOP's root directory, you will also get an HTML report.</p>
 <p>Checkstyle is probably most useful when integrated into your IDE. See the Checkstyle web site for more information about IDE plugins.</p>
-<h2 id="java-best-practices-wzxhzdk15wzxhzdk16">Java Best Practices # <a id="java-best-practices"></a></h2>
+<h3 id="java-best-practices-wzxhzdk15wzxhzdk16">Java Best Practices # <a id="java-best-practices"></a></h3>
 <p>The following general principles are a distillation of best practice expectations on the FOP project.</p>
 <ul>
 <li>
@@ -448,7 +449,7 @@ $(document).ready(function () {
 <p>Try to avoid catching Throwable or Exception and catch specific exceptions instead.</p>
 </li>
 </ul>
-<h2 id="resources-wzxhzdk17wzxhzdk18">Resources # <a id="java-resources"></a></h2>
+<h3 id="resources-wzxhzdk17wzxhzdk18">Resources # <a id="java-resources"></a></h3>
 <ul>
 <li>
 <p>[book on code style] Code Complete by Steve McConnell.</p>
@@ -457,7 +458,7 @@ $(document).ready(function () {
 <p>[code formatting software]<jump href="http://jrefactory.sourceforge.net">JRefactory</jump>.</p>
 </li>
 </ul>
-<h2 id="related-links-wzxhzdk19wzxhzdk20">Related Links # <a id="java-links"></a></h2>
+<h3 id="related-links-wzxhzdk19wzxhzdk20">Related Links # <a id="java-links"></a></h3>
 <ul>
 <li>
 <p><jump href="http://xmlgraphics.apache.org/repo.html">Apache XML Graphics Code Repositories</jump></p>
@@ -466,7 +467,7 @@ $(document).ready(function () {
 <p><jump href="http://jakarta.apache.org/site/faqs.html#Coding%20Conventions%20and%20Standards">Jakarta Code Conventions and Standards</jump>(see Coding Conventions and Standards section)</p>
 </li>
 </ul>
-<h1 id="xml-wzxhzdk21wzxhzdk22">XML  <a id="xml"></a></h1>
+<h2 id="xml-wzxhzdk21wzxhzdk22">XML  <a id="xml"></a></h2>
 <table>
 <thead>
 <tr>

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:04:00 2012
@@ -330,67 +330,68 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/">Dev</a>&nbsp;&raquo&nbsp;<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>
+      	<div class="section-content"><h1 id="apachetm-fop-design-area-tree">Apache(tm) 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>
 <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>
-<h1 id="structure-wzxhzdk8wzxhzdk9">Structure  <a id="structure"></a></h1>
+<h2 id="structure-wzxhzdk8wzxhzdk9">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>
-<h1 id="page-wzxhzdk10wzxhzdk11">Page  <a id="page"></a></h1>
+<h2 id="page-wzxhzdk10wzxhzdk11">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>
-<h1 id="block-areas-wzxhzdk12wzxhzdk13">Block Areas  <a id="block"></a></h1>
+<h2 id="block-areas-wzxhzdk12wzxhzdk13">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>
-<h1 id="line-areas-wzxhzdk14wzxhzdk15">Line Areas  <a id="line-area"></a></h1>
+<h2 id="line-areas-wzxhzdk14wzxhzdk15">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>
-<h1 id="inline-areas-wzxhzdk16wzxhzdk17">Inline Areas  <a id="inline"></a></h1>
+<h2 id="inline-areas-wzxhzdk16wzxhzdk17">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>
-<h1 id="repeated-areas-wzxhzdk18wzxhzdk19">Repeated Areas  <a id="repeated-area"></a></h1>
+<h2 id="repeated-areas-wzxhzdk18wzxhzdk19">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>
-<h1 id="traits-wzxhzdk20wzxhzdk21">Traits  <a id="traits"></a></h1>
+<h2 id="traits-wzxhzdk20wzxhzdk21">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>
-<h1 id="classes-wzxhzdk22wzxhzdk23">Classes  <a id="classes"></a></h1>
+<h2 id="classes-wzxhzdk22wzxhzdk23">Classes  <a id="classes"></a></h2>
 <p>The following class structure will be used to represent the area tree.</p>
-<h2 id="page-area-classes-wzxhzdk24wzxhzdk25">Page Area Classes # <a id="classes-page"></a></h2>
+<h3 id="page-area-classes-wzxhzdk24wzxhzdk25">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>
-<h2 id="block-area-classes-wzxhzdk26wzxhzdk27">Block Area Classes # <a id="classes-block"></a></h2>
+<h3 id="block-area-classes-wzxhzdk26wzxhzdk27">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>
-<h2 id="inline-area-classes-wzxhzdk28wzxhzdk29">Inline Area Classes # <a id="classes-inline"></a></h2>
+<h3 id="inline-area-classes-wzxhzdk28wzxhzdk29">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>
-<h1 id="forward-references-wzxhzdk30wzxhzdk31">Forward References  <a id="forward-references"></a></h1>
+<h2 id="forward-references-wzxhzdk30wzxhzdk31">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>
-<h1 id="caching-wzxhzdk32wzxhzdk33">Caching  <a id="caching"></a></h1>
+<h2 id="caching-wzxhzdk32wzxhzdk33">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>
-<h1 id="extensions-wzxhzdk34wzxhzdk35">Extensions  <a id="extensions"></a></h1>
+<h2 id="extensions-wzxhzdk34wzxhzdk35">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>
-<h1 id="area-tree-handlers-wzxhzdk36wzxhzdk37">Area Tree Handlers  <a id="handlers"></a></h1>
+<h2 id="area-tree-handlers-wzxhzdk36wzxhzdk37">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>
-<h1 id="status-wzxhzdk38wzxhzdk39">Status  <a id="status"></a></h1>
-<h2 id="to-do-wzxhzdk40wzxhzdk41">To Do # <a id="status-todo"></a></h2>
-<h2 id="work-in-progress-wzxhzdk42wzxhzdk43">Work in Progress # <a id="status-wip"></a></h2>
-<h2 id="completed-wzxhzdk44wzxhzdk45">Completed # <a id="status-complete"></a></h2>
+<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>
 <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:04:00 2012
@@ -330,15 +330,16 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/">Dev</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/design/">Design</a></div> -->
-      	<div class="section-content"><p><subtitle>Break Possibility Proposal</subtitle><version>$Revision: 1298724 $</version><authors><person email="klease@club-internet.fr" name="Karen Lease"></person></authors></p>
-<h1 id="introduction-wzxhzdk8wzxhzdk9">Introduction  <a id="intro"></a></h1>
+      	<div class="section-content"><h1 id="apachetm-fop-design-layout-managers">Apache(tm) 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>
 <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>
-<h1 id="anatomy-of-a-break-possibility-wzxhzdk10wzxhzdk11">Anatomy of a Break Possibility  <a id="Anatomy+of+a+Break+Possibility"></a></h1>
+<h2 id="anatomy-of-a-break-possibility-wzxhzdk10wzxhzdk11">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>
-<h1 id="turning-break-possibilities-into-areas-wzxhzdk12wzxhzdk13">Turning Break Possibilities into Areas  <a id="Turning+Break+Possibilities+into+Areas"></a></h1>
+<h2 id="turning-break-possibilities-into-areas-wzxhzdk12wzxhzdk13">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>
-<h1 id="a-walk-through-wzxhzdk14wzxhzdk15">A walk-through  <a id="A+walk-through"></a></h1>
+<h2 id="a-walk-through-wzxhzdk14wzxhzdk15">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>
@@ -355,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>
-<h1 id="some-issues-wzxhzdk16wzxhzdk17">Some issues  <a id="Some+issues"></a></h1>
+<h2 id="some-issues-wzxhzdk16wzxhzdk17">Some issues  <a id="Some+issues"></a></h2>
 <p>Following are a few remarks on specific issues.</p>
-<h2 id="where-line-layout-managers-are-created-wzxhzdk18wzxhzdk19">Where Line Layout Managers are created # <a id="Where+Line+Layout+Managers+are+created"></a></h2>
+<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>
 <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>
-<h2 id="getting-the-reference-ipd-wzxhzdk20wzxhzdk21">Getting the reference IPD # <a id="getRefIPD"></a></h2>
+<h3 id="getting-the-reference-ipd-wzxhzdk20wzxhzdk21">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>
-<h2 id="hyphenation-wzxhzdk22wzxhzdk23">Hyphenation # <a id="Hyphenation"></a></h2>
+<h3 id="hyphenation-wzxhzdk22wzxhzdk23">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>
-<h2 id="optimizing-wzxhzdk24wzxhzdk25">Optimizing # <a id="Optimizing"></a></h2>
+<h3 id="optimizing-wzxhzdk24wzxhzdk25">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:04:00 2012
@@ -330,12 +330,13 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/">Dev</a>&nbsp;&raquo&nbsp;<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>
+      	<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>
+<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>
 <p>This is the design for the external interface when Apache&trade; 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>
-<h1 id="settings-wzxhzdk11wzxhzdk12">Settings  <a id="Settings"></a></h1>
-<h2 id="user-agent-wzxhzdk13wzxhzdk14">User Agent # <a id="User+Agent"></a></h2>
+<h2 id="settings-wzxhzdk11wzxhzdk12">Settings  <a id="Settings"></a></h2>
+<h3 id="user-agent-wzxhzdk13wzxhzdk14">User Agent # <a id="User+Agent"></a></h3>
 <p>Possible meanings for a user agent:</p>
 <ul>
 <li>
@@ -349,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>
-<h2 id="logging-wzxhzdk17wzxhzdk18">Logging # <a id="Logging"></a></h2>
+<h3 id="logging-wzxhzdk17wzxhzdk18">Logging # <a id="Logging"></a></h3>
 <ul>
 <li>
 <p>logging level</p>
@@ -364,7 +365,7 @@ $(document).ready(function () {
 <p>Logging setup (LogKit, Log4J, JDK14Logging)</p>
 </li>
 </ul>
-<h2 id="xml-input-wzxhzdk19wzxhzdk20">XML input # <a id="XML+input"></a></h2>
+<h3 id="xml-input-wzxhzdk19wzxhzdk20">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>
@@ -373,7 +374,7 @@ $(document).ready(function () {
 <p>sax handler</p>
 </li>
 </ul>
-<h2 id="general-options-wzxhzdk21wzxhzdk22">general options # <a id="general+options"></a></h2>
+<h3 id="general-options-wzxhzdk21wzxhzdk22">general options # <a id="general+options"></a></h3>
 <ul>
 <li>
 <p>base url</p>
@@ -385,7 +386,7 @@ $(document).ready(function () {
 <p>which implementation of a particular LayoutManager to use</p>
 </li>
 </ul>
-<h2 id="rendering-options-wzxhzdk23wzxhzdk24">Rendering Options # <a id="Rendering+Options"></a></h2>
+<h3 id="rendering-options-wzxhzdk23wzxhzdk24">Rendering Options # <a id="Rendering+Options"></a></h3>
 <ul>
 <li>
 <p>embedding fonts</p>
@@ -409,7 +410,7 @@ $(document).ready(function () {
 <p>binary/ascii switch</p>
 </li>
 </ul>
-<h2 id="render-results-wzxhzdk25wzxhzdk26">Render Results # <a id="Render+Results"></a></h2>
+<h3 id="render-results-wzxhzdk25wzxhzdk26">Render Results # <a id="Render+Results"></a></h3>
 <p>Generate Output statistics from FOP:</p>
 <ul>
 <li>
@@ -425,9 +426,9 @@ $(document).ready(function () {
 <p>recoverable errors such as overflow</p>
 </li>
 </ul>
-<h2 id="setting-up-wzxhzdk27wzxhzdk28">Setting Up # <a id="Setting+Up"></a></h2>
+<h3 id="setting-up-wzxhzdk27wzxhzdk28">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>
-<h2 id="others-wzxhzdk29wzxhzdk30">Others # <a id="Others"></a></h2>
+<h3 id="others-wzxhzdk29wzxhzdk30">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:04:00 2012
@@ -330,10 +330,11 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/">Dev</a>&nbsp;&raquo&nbsp;<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>
+      	<div class="section-content"><h1 id="apachetm-fop-design-extensions">Apache(tm) 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>
 <p>Apache&trade; 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>
-<h1 id="extensions-wzxhzdk9wzxhzdk10">Extensions  <a id="Extensions"></a></h1>
+<h2 id="extensions-wzxhzdk9wzxhzdk10">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>
@@ -347,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>
-<h1 id="examples-wzxhzdk11wzxhzdk12">Examples  <a id="Examples"></a></h1>
+<h2 id="examples-wzxhzdk11wzxhzdk12">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,8 +364,8 @@ to result in a text box referencing the 
 <blockquote></blockquote>
 </blockquote>
 <h1 id="status-wzxhzdk15wzxhzdk16">Status  <a id="status"></a></h1>
-<h2 id="to-do-wzxhzdk17wzxhzdk18">To Do # <a id="status-todo"></a></h2>
-<h2 id="work-in-progress-wzxhzdk19wzxhzdk20">Work In Progress # <a id="status-wip"></a></h2>
+<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>
 <ul>
 <li>
 <p>mathml extension</p>
@@ -376,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>
-<h2 id="completed-wzxhzdk21wzxhzdk22">Completed # <a id="status-complete"></a></h2>
+<h3 id="completed-wzxhzdk21wzxhzdk22">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:04:00 2012
@@ -330,10 +330,11 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/">Dev</a>&nbsp;&raquo&nbsp;<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>
+      	<div class="section-content"><h1 id="apachetm-fop-design-fo-tree">Apache(tm) 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>
 <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>
-<h1 id="processing-wzxhzdk8wzxhzdk9">Processing  <a id="process"></a></h1>
+<h2 id="processing-wzxhzdk8wzxhzdk9">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>
@@ -348,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>
-<h1 id="recycling-fo-tree-memory-wzxhzdk10wzxhzdk11">Recycling FO Tree Memory  <a id="recycle"></a></h1>
+<h2 id="recycling-fo-tree-memory-wzxhzdk10wzxhzdk11">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>
@@ -361,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>
-<h1 id="fo-tree-serialization-wzxhzdk12wzxhzdk13">FO Tree Serialization  <a id="serialize"></a></h1>
+<h2 id="fo-tree-serialization-wzxhzdk12wzxhzdk13">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>
-<h1 id="notes-about-specific-elements-wzxhzdk14wzxhzdk15">Notes About Specific Elements  <a id="specific-elements"></a></h1>
-<h2 id="page-master-wzxhzdk16wzxhzdk17">page-master # <a id="page-master"></a></h2>
+<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>
 <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>
-<h2 id="flow-wzxhzdk18wzxhzdk19">flow # <a id="flow"></a></h2>
+<h3 id="flow-wzxhzdk18wzxhzdk19">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>
-<h2 id="other-elements-wzxhzdk20wzxhzdk21">Other Elements # <a id="other-elements"></a></h2>
+<h3 id="other-elements-wzxhzdk20wzxhzdk21">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>
-<h1 id="implementation-notes-wzxhzdk22wzxhzdk23">Implementation Notes  <a id="implement"></a></h1>
-<h2 id="fonode-wzxhzdk24wzxhzdk25">FONode # <a id="fonode"></a></h2>
+<h2 id="implementation-notes-wzxhzdk22wzxhzdk23">Implementation Notes  <a id="implement"></a></h2>
+<h3 id="fonode-wzxhzdk24wzxhzdk25">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>
@@ -387,7 +388,7 @@ $(document).ready(function () {
 <p>other: <code>org.apache.fop.fo.*.</code> </p>
 </li>
 </ul>
-<h2 id="creating-fo-objects-wzxhzdk26wzxhzdk27">Creating FO Objects # <a id="create-fo"></a></h2>
+<h3 id="creating-fo-objects-wzxhzdk26wzxhzdk27">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>
@@ -406,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>
-<h2 id="foreign-xml-wzxhzdk28wzxhzdk29">Foreign XML # <a id="foreign"></a></h2>
+<h3 id="foreign-xml-wzxhzdk28wzxhzdk29">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>
-<h2 id="unknown-elements-wzxhzdk30wzxhzdk31">Unknown Elements # <a id="unknown"></a></h2>
+<h3 id="unknown-elements-wzxhzdk30wzxhzdk31">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:04:00 2012
@@ -330,30 +330,31 @@ $(document).ready(function () {
       
       <div id="content" class="grid_16">
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/dev/">Dev</a>&nbsp;&raquo&nbsp;<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>
+      	<div class="section-content"><h1 id="apachetm-fop-design-images">Apache(tm) FOP Design: Images</h1>
+<p><version>$Revision: 1298724 $</version></p>
+<h2 id="introduction-wzxhzdk2wzxhzdk3">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 -&gt; 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>
+<h2 id="threading-wzxhzdk6wzxhzdk7">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>
-<h1 id="caches-wzxhzdk8wzxhzdk9">Caches  <a id="Caches"></a></h1>
-<h2 id="lru-wzxhzdk10wzxhzdk11">LRU # <a id="LRU"></a></h2>
+<h2 id="caches-wzxhzdk8wzxhzdk9">Caches  <a id="Caches"></a></h2>
+<h3 id="lru-wzxhzdk10wzxhzdk11">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>
-<h2 id="context-wzxhzdk12wzxhzdk13">Context # <a id="Context"></a></h2>
+<h3 id="context-wzxhzdk12wzxhzdk13">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>
-<h1 id="invalid-images-wzxhzdk14wzxhzdk15">Invalid Images  <a id="Invalid+Images"></a></h1>
+<h2 id="invalid-images-wzxhzdk14wzxhzdk15">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>
-<h1 id="reading-wzxhzdk18wzxhzdk19">Reading  <a id="Reading"></a></h1>
+<h2 id="reading-wzxhzdk18wzxhzdk19">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>
-<h1 id="data-wzxhzdk20wzxhzdk21">Data  <a id="Data"></a></h1>
+<h2 id="data-wzxhzdk20wzxhzdk21">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>
-<h1 id="rendering-wzxhzdk22wzxhzdk23">Rendering  <a id="Rendering"></a></h1>
+<h2 id="rendering-wzxhzdk22wzxhzdk23">Rendering  <a id="Rendering"></a></h2>
 <p>Different renderers need to have the information in different forms.</p>
-<h2 id="pdf-wzxhzdk24wzxhzdk25">PDF # <a id="PDF"></a></h2>
+<h3 id="pdf-wzxhzdk24wzxhzdk25">PDF # <a id="PDF"></a></h3>
 <dl>
 <dt>original data</dt>
 <dd>JPG, EPS</dd>



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org


Mime
View raw message