xmlgraphics-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vhenneb...@apache.org
Subject svn commit: r569118 [27/49] - in /xmlgraphics/site/deploy/fop: ./ 0.93/ 0.94/ 0.94/images/ dev/ dev/design/ skin/ trunk/
Date Thu, 23 Aug 2007 19:00:51 GMT
Modified: xmlgraphics/site/deploy/fop/dev/api-doc.html
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/api-doc.html?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/api-doc.html (original)
+++ xmlgraphics/site/deploy/fop/dev/api-doc.html Thu Aug 23 12:00:37 2007
@@ -58,10 +58,10 @@
 <a class="base-not-selected" href="../index.html">Home</a>
 </li>
 <li>
-<a class="base-not-selected" href="../0.20.5/index.html">Version 0.20.5</a>
+<a class="base-not-selected" href="../0.93/index.html">Version 0.93</a>
 </li>
 <li>
-<a class="base-not-selected" href="../0.93/index.html">Version 0.93</a>
+<a class="base-not-selected" href="../0.94/index.html">Version 0.94</a>
 </li>
 <li>
 <a class="base-not-selected" href="../trunk/index.html">FOP Trunk</a>
@@ -244,10 +244,20 @@
     |start content
     +-->
 <div id="content">
+<div title="raw XML" class="xmllink">
+<a class="dida" href="api-doc.xml"><img alt="XML - icon" src="../skin/images/xmldoc.gif" class="skin"><br>
+        XML</a>
+</div>
 <div title="Portable Document Format" class="pdflink">
 <a class="dida" href="api-doc.pdf"><img alt="PDF -icon" src="../skin/images/pdfdoc.gif" class="skin"><br>
         PDF</a>
 </div>
+<div class="trail">
+<text>Font size:</text> 
+	          &nbsp;<input value="Reset" class="resetfont" title="Reset text" onclick="ndeSetTextSize('reset'); return false;" type="button">      
+	          &nbsp;<input value="-a" class="smallerfont" title="Shrink text" onclick="ndeSetTextSize('decr'); return false;" type="button">
+	          &nbsp;<input value="+a" class="biggerfont" title="Enlarge text" onclick="ndeSetTextSize('incr'); return false;" type="button">
+</div>
 <h1>FOP Development: API Documentation (javadocs)</h1>
 <div id="minitoc-area">
 <ul class="minitoc">
@@ -263,7 +273,7 @@
 <a name="N10011"></a><a name="gump"></a>
 <h2 class="underlined_10">On-line Access (through Gump)</h2>
 <div class="section">
-<p>FOP (and many other Apache projects) use <a href="http://gump.apache.org/">Apache Gump</a> to do a test build several times each day. One of the useful byproducts of this process is that javadocs can be created and made available.</p>
+<p>FOP (and many other Apache projects) use <a class="external" href="http://gump.apache.org/">Apache Gump</a> to do a test build several times each day. One of the useful byproducts of this process is that javadocs can be created and made available.</p>
 <p>First, determine which line of development code you wish to see. If you don't know, you probably want the "Maintenance Branch", which is the line that currently produces FOP releases. See <a href="index.html#lines">Development Lines</a> for more details.</p>
 <div class="warning">
 <div class="label">Warning</div>
@@ -272,11 +282,11 @@
 <ul>
         
 <li>
-<a href="http://gump.apache.org/javadoc/xml-fop-maintenance/build/javadocs/index.html">Javadocs for Maintenance Branch</a>
+<a class="external" href="http://gump.apache.org/javadoc/xml-fop-maintenance/build/javadocs/index.html">Javadocs for Maintenance Branch</a>
 </li>
         
 <li>
-<a href="http://gump.apache.org/javadoc/xml-fop/build/javadocs/index.html">Javadocs for Trunk (Redesign)</a>
+<a class="external" href="http://gump.apache.org/javadoc/xml-fop/build/javadocs/index.html">Javadocs for Trunk (Redesign)</a>
 </li>
       
 </ul>

Modified: xmlgraphics/site/deploy/fop/dev/api-doc.pdf
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/api-doc.pdf?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/api-doc.pdf (original)
+++ xmlgraphics/site/deploy/fop/dev/api-doc.pdf Thu Aug 23 12:00:37 2007
@@ -226,8 +226,8 @@
 30 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F3
-/BaseFont /Helvetica-Bold
+/Name /F1
+/BaseFont /Helvetica
 /Encoding /WinAnsiEncoding >>
 endobj
 31 0 obj
@@ -240,8 +240,8 @@
 32 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F1
-/BaseFont /Helvetica
+/Name /F3
+/BaseFont /Helvetica-Bold
 /Encoding /WinAnsiEncoding >>
 endobj
 33 0 obj
@@ -272,7 +272,7 @@
 endobj
 3 0 obj
 << 
-/Font << /F3 30 0 R /F5 31 0 R /F1 32 0 R /F2 33 0 R /F7 34 0 R >> 
+/Font << /F1 30 0 R /F5 31 0 R /F3 32 0 R /F2 33 0 R /F7 34 0 R >> 
 /ProcSet [ /PDF /ImageC /Text ] >> 
 endobj
 9 0 obj
@@ -325,8 +325,8 @@
 0000006430 00000 n 
 0000006689 00000 n 
 0000006911 00000 n 
-0000007024 00000 n 
-0000007134 00000 n 
+0000007019 00000 n 
+0000007129 00000 n 
 0000007242 00000 n 
 0000007358 00000 n 
 trailer

Added: xmlgraphics/site/deploy/fop/dev/api-doc.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/api-doc.xml?rev=569118&view=auto
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/api-doc.xml (added)
+++ xmlgraphics/site/deploy/fop/dev/api-doc.xml Thu Aug 23 12:00:37 2007
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+--><!-- $Id$ --><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.3//EN" "http://forrest.apache.org/dtd/document-v13.dtd">
+<document>
+  <header>
+    <title>FOP Development: API Documentation (javadocs)</title>
+    <version>$Revision: 426576 $</version>
+  </header>
+  <body>
+    <section id="gump">
+      <title>On-line Access (through Gump)</title>
+      <p>FOP (and many other Apache projects) use <link href="http://gump.apache.org/">Apache Gump</link> to do a test build several times each day. One of the useful byproducts of this process is that javadocs can be created and made available.</p>
+      <p>First, determine which line of development code you wish to see. If you don't know, you probably want the "Maintenance Branch", which is the line that currently produces FOP releases. See <link href="index.html#lines">Development Lines</link> for more details.</p>
+      <warning>Javadocs for both development lines are made from current SVN code, and are not tied to any particular release. Both the documentation and the API may be different, even if you are working with the correct branch. Currently, the only way to obtain API documentation for a specific release is to <link href="#self-built">build it yourself</link>.</warning>
+      <ul>
+        <li><link href="http://gump.apache.org/javadoc/xml-fop-maintenance/build/javadocs/index.html">Javadocs for Maintenance Branch</link></li>
+        <li><link href="http://gump.apache.org/javadoc/xml-fop/build/javadocs/index.html">Javadocs for Trunk (Redesign)</link></li>
+      </ul>
+      <note>If the links return an "Object not found!" message or otherwise do not work properly, it is probably because of a build error. Please raise a question on the <link href="../maillist.html#fop-user">FOP User Mailing List</link> so that any problems can be fixed before the next build.</note>
+    </section>
+    <section id="self-built">
+      <title>Building them Yourself</title>
+      <p>See <link href="../download.html#source">Source Download</link> for instructions on obtaining the source code. Then see <link href="../trunk/compiling.html">Building FOP</link> for instructions on running the build process. The Ant build target that you will use to generate the API documentation is "javadocs", and the results will be stored in xml-fop/build/javadocs.</p>
+    </section>
+  </body>
+</document>
\ No newline at end of file

Propchange: xmlgraphics/site/deploy/fop/dev/api-doc.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: xmlgraphics/site/deploy/fop/dev/api-doc.xml
------------------------------------------------------------------------------
    svn:keywords = Id

Modified: xmlgraphics/site/deploy/fop/dev/conventions.html
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/conventions.html?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/conventions.html (original)
+++ xmlgraphics/site/deploy/fop/dev/conventions.html Thu Aug 23 12:00:37 2007
@@ -58,10 +58,10 @@
 <a class="base-not-selected" href="../index.html">Home</a>
 </li>
 <li>
-<a class="base-not-selected" href="../0.20.5/index.html">Version 0.20.5</a>
+<a class="base-not-selected" href="../0.93/index.html">Version 0.93</a>
 </li>
 <li>
-<a class="base-not-selected" href="../0.93/index.html">Version 0.93</a>
+<a class="base-not-selected" href="../0.94/index.html">Version 0.94</a>
 </li>
 <li>
 <a class="base-not-selected" href="../trunk/index.html">FOP Trunk</a>
@@ -244,10 +244,20 @@
     |start content
     +-->
 <div id="content">
+<div title="raw XML" class="xmllink">
+<a class="dida" href="conventions.xml"><img alt="XML - icon" src="../skin/images/xmldoc.gif" class="skin"><br>
+        XML</a>
+</div>
 <div title="Portable Document Format" class="pdflink">
 <a class="dida" href="conventions.pdf"><img alt="PDF -icon" src="../skin/images/pdfdoc.gif" class="skin"><br>
         PDF</a>
 </div>
+<div class="trail">
+<text>Font size:</text> 
+	          &nbsp;<input value="Reset" class="resetfont" title="Reset text" onclick="ndeSetTextSize('reset'); return false;" type="button">      
+	          &nbsp;<input value="-a" class="smallerfont" title="Shrink text" onclick="ndeSetTextSize('decr'); return false;" type="button">
+	          &nbsp;<input value="+a" class="biggerfont" title="Enlarge text" onclick="ndeSetTextSize('incr'); return false;" type="button">
+</div>
 <h1>FOP Development: Coding Conventions</h1>
 <div id="minitoc-area">
 <ul class="minitoc">
@@ -307,10 +317,10 @@
           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>, 
+          <a class="external" 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>.
+          <a class="external" 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 class="ForrestTable" cellspacing="1" cellpadding="4">
@@ -409,15 +419,15 @@
 </tr>
         
 </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>
+<p>For developers that dislike these conventions, one workaround is to develop using their own style, then use a formatting tool like <a class="external" href="http://astyle.sourceforge.net/">astyle</a> (Artistic Style) before committing.</p>
 <a name="N10118"></a><a name="java-checkstyle"></a>
 <h3 class="underlined_5">Checkstyle</h3>
-<p>The java syntax checker "<a target="_top" href="http://checkstyle.sourceforge.net">Checkstyle</a>" is used to enforce many of the FOP coding standards.
+<p>The java syntax checker "<a class="external" href="http://checkstyle.sourceforge.net">Checkstyle</a>" 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 <a target="_top" href="http://checkstyle.sourceforge.net">Checkstyle web site</a>, 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>To use the "checkstyle" target in FOP's build process, download the source from the <a class="external" href="http://checkstyle.sourceforge.net">Checkstyle web site</a>, 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>
 <a name="N10133"></a><a name="java-best-practices"></a>
 <h3 class="underlined_5">Java Best Practices</h3>
@@ -442,7 +452,7 @@
 <li>Try to catch exceptions as much as possible and rethrow higher level exceptions (meaning hiding the low level detailed and putting a message that is more related to the function of your code).</li> 
           
 <li>It is important not to lose the stack trace which contains important information.
-Use chained exception for that. Avalon Framework provides <a target="_top" href="http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/CascadingException.htm">CascadingException</a> (and similar) for this.
+Use chained exception for that. Avalon Framework provides <a class="external" href="http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/CascadingException.htm">CascadingException</a> (and similar) for this.
 Exception class names and stack traces must be treated like gold.
 Do whatever is required so that this information is not lost.
 Printing error messages to System.err or System.out is useless in a server-side environment where this info is usually lost.</li>
@@ -458,7 +468,7 @@
           
 <li>[book on code style] Code Complete by Steve McConnell.</li>
           
-<li>[code formatting software] <a target="_top" href="http://jrefactory.sourceforge.net">JRefactory</a>.</li>
+<li>[code formatting software] <a class="external" href="http://jrefactory.sourceforge.net">JRefactory</a>.</li>
         
 </ul>
 <a name="N10176"></a><a name="java-links"></a>
@@ -470,7 +480,7 @@
 </li>
           
 <li>
-<a target="_top" href="http://jakarta.apache.org/site/faqs.html#Coding%20Conventions%20and%20Standards">Jakarta Code Conventions and Standards</a> (see Coding Conventions and Standards section)</li>
+<a class="external" href="http://jakarta.apache.org/site/faqs.html#Coding%20Conventions%20and%20Standards">Jakarta Code Conventions and Standards</a> (see Coding Conventions and Standards section)</li>
         
 </ul>
 </div>

Modified: xmlgraphics/site/deploy/fop/dev/conventions.pdf
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/conventions.pdf?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/conventions.pdf (original)
+++ xmlgraphics/site/deploy/fop/dev/conventions.pdf Thu Aug 23 12:00:37 2007
@@ -498,8 +498,8 @@
 65 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F3
-/BaseFont /Helvetica-Bold
+/Name /F1
+/BaseFont /Helvetica
 /Encoding /WinAnsiEncoding >>
 endobj
 66 0 obj
@@ -512,22 +512,22 @@
 67 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F6
-/BaseFont /Times-Italic
+/Name /F3
+/BaseFont /Helvetica-Bold
 /Encoding /WinAnsiEncoding >>
 endobj
 68 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F1
-/BaseFont /Helvetica
+/Name /F2
+/BaseFont /Helvetica-Oblique
 /Encoding /WinAnsiEncoding >>
 endobj
 69 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F2
-/BaseFont /Helvetica-Oblique
+/Name /F6
+/BaseFont /Times-Italic
 /Encoding /WinAnsiEncoding >>
 endobj
 70 0 obj
@@ -551,7 +551,7 @@
 endobj
 3 0 obj
 << 
-/Font << /F3 65 0 R /F5 66 0 R /F1 68 0 R /F6 67 0 R /F2 69 0 R /F7 70 0 R >> 
+/Font << /F1 65 0 R /F5 66 0 R /F3 67 0 R /F2 68 0 R /F6 69 0 R /F7 70 0 R >> 
 /ProcSet [ /PDF /ImageC /Text ] >> 
 endobj
 9 0 obj
@@ -675,10 +675,10 @@
 0000019520 00000 n 
 0000019699 00000 n 
 0000019809 00000 n 
-0000019922 00000 n 
-0000020032 00000 n 
-0000020143 00000 n 
-0000020251 00000 n 
+0000019917 00000 n 
+0000020027 00000 n 
+0000020140 00000 n 
+0000020256 00000 n 
 0000020367 00000 n 
 trailer
 <<

Added: xmlgraphics/site/deploy/fop/dev/conventions.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/conventions.xml?rev=569118&view=auto
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/conventions.xml (added)
+++ xmlgraphics/site/deploy/fop/dev/conventions.xml Thu Aug 23 12:00:37 2007
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+--><!-- $Id$ --><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.3//EN" "http://forrest.apache.org/dtd/document-v13.dtd">
+<document>
+  <header>
+    <title>FOP Development: Coding Conventions</title>
+    <version>$Revision: 426576 $</version>
+  </header>
+  <body>
+    <p>Acknowledgement: Some content in this guide was adapted from other Apache projects such as Avalon, Cactus, Turbine and Velocity.</p>
+    <section id="svn">
+      <title>Subversion Repository</title>
+      <p>Conventions in this section apply to Repository content, regardless of type:</p>
+      <ul>
+        <li>Files checked in must conform to the code conventions for that type of file (java files must conform to java requirements, xml to xml requirements, etc.). If a submitted patch does not conform, it is the responsibility of the committer to bring it into conformance before checking it in. Developers submitting patches are encouraged to follow the code conventions to reduce the work load on the committers.</li>
+        <li>To reduce the amount of spurious deltas, all text (non-binary) files checked into SVN must have Unix-style line endings (LF only). Many IDEs and editors (even on non-Unix platforms) have settings that can facilitate this convention.</li>
+        <li>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.</li>
+      </ul>
+    </section>
+    <section id="java">
+      <title>Java</title>
+      <section id="java-style">
+        <title>Java Style</title>
+        <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 
+          <link href="http://xml.apache.org/source.html">Apache XML Project Guidelines</link>, 
+          which requires that <strong>all Java Language source code in the repository 
+          must be written in conformance to Sun's</strong> 
+          <link href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Code Conventions for the Java Programming Language</link>.
+          In addition, the FOP developers have agreed to other conventions, 
+          which are summarized in the following table:</p>
+        <table>
+          <tr>
+            <th colspan="1" rowspan="1">Convention</th>
+            <th colspan="1" rowspan="1">Rationale</th>
+            <th colspan="1" rowspan="1">Enforced By</th>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">Every Java source file starts with the Apache licence header.</td>
+            <td colspan="1" rowspan="1">Required by Apache.</td>
+            <td colspan="1" rowspan="1">checkstyle</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">No tabs in content.</td>
+            <td colspan="1" rowspan="1">Programmers should not have to adjust the tab settings in their editor to be able to read the source code.</td>
+            <td colspan="1" rowspan="1">checkstyle</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">Indentation of 4 spaces per level.</td>
+            <td colspan="1" rowspan="1">Maximize readability.</td>
+            <td colspan="1" rowspan="1">Not enforced</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">Comments, identifiers, and project documentation must be in English.
+In general, other languages must not be used, except in translated documentation and language-specific i10n files.
+            </td>
+            <td colspan="1" rowspan="1">To avoid the need for everyone to learn all languages, English has become the standard language for many technology projects, and is the only human language that all FOP developers are expected to know.</td>
+            <td colspan="1" rowspan="1">Not enforced</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">American English spelling should be used. Alternative spelling and idioms are tolerated, but may be changed by anyone to American.</td>
+            <td colspan="1" rowspan="1">Some standard is useful, and American English is widely used and accepted for technology standards and projects.</td>
+            <td colspan="1" rowspan="1">Not enforced.</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">Fully qualify all import statements (no "import java.util.*")</td>
+            <td colspan="1" rowspan="1">Clarity</td>
+            <td colspan="1" rowspan="1">checkstyle</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">No underscores in variable names except for static finals.</td>
+            <td colspan="1" rowspan="1">Upper/lower case distinctions can be made in all other variable names, eliminating the need for artificial word boundaries.</td>
+            <td colspan="1" rowspan="1">checkstyle</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">Opening brace for a block should be on the same line as its control statement (if, while, etc.).</td>
+            <td colspan="1" rowspan="1">Standardization, general preference.</td>
+            <td colspan="1" rowspan="1">checkstyle</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">Write appropriate javadoc entries for all public and protected classes, methods, and variables.</td>
+            <td colspan="1" rowspan="1">Basic API documentation is needed.</td>
+            <td colspan="1" rowspan="1">checkstyle</td>
+          </tr>
+          <tr>
+            <td colspan="1" rowspan="1">Personal attribution in the source code, such as @author tags and attribution comments should not be used.
+Excepted from this general rule are potentially confusing or wide-ranging changes.
+If such changes prove useful over time, the related comments should be removed.</td>
+            <td colspan="1" rowspan="1">Personal attribution tends to clutter the code.
+The relevant historical information that might be useful for problem-solving is tracked in the code repository.</td>
+            <td colspan="1" rowspan="1">Not enforced. Anyone is free to remove such comments.</td>
+          </tr>
+        </table>
+        <p>For developers that dislike these conventions, one workaround is to develop using their own style, then use a formatting tool like <link href="http://astyle.sourceforge.net/">astyle</link> (Artistic Style) before committing.</p>
+      </section>
+      <section id="java-checkstyle">
+        <title>Checkstyle</title>
+        <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>
+      </section>
+      <section id="java-best-practices">
+        <title>Java Best Practices</title>
+        <p>The following general principles are a distillation of best practice expectations on the FOP project.</p>
+        <ul>
+          <li>Apply common sense when coding. When coding keep in mind that others will read your code and have to understand it.</li>
+          <li>Readability comes before performance, at least initially.</li>
+          <li>If you can refactor some code to make it more understandable, please do so.</li>
+          <li>Properly document code, especially where it's important.</li>
+          <li>Use interfaces instead of implementations where possible.
+This favors a clearer design and makes switching between implementations easier (Examples: List instead of ArrayList/Vector, Map instead of HashMap/Hashtable).</li>
+
+
+          <li>Avoid using exceptions for flow control.</li>
+          <li>Try to catch exceptions as much as possible and rethrow higher level exceptions (meaning hiding the low level detailed and putting a message that is more related to the function of your code).</li> 
+          <li>It is important not to lose the stack trace which contains important information.
+Use chained exception for that. Avalon Framework provides <jump href="http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/CascadingException.htm">CascadingException</jump> (and similar) for this.
+Exception class names and stack traces must be treated like gold.
+Do whatever is required so that this information is not lost.
+Printing error messages to System.err or System.out is useless in a server-side environment where this info is usually lost.</li>
+          <li>Always log the exception at the higher level (i.e. where it is handled and not rethrown).</li> 
+          <li>Try to avoid catching Throwable or Exception and catch specific exceptions instead.</li>
+        </ul>
+      </section>
+      <section id="java-resources">
+        <title>Resources</title>
+        <ul>
+          <li>[book on code style] Code Complete by Steve McConnell.</li>
+          <li>[code formatting software] <jump href="http://jrefactory.sourceforge.net">JRefactory</jump>.</li>
+        </ul>
+      </section>
+      <section id="java-links">
+        <title>Related Links</title>
+        <ul>
+          <li><jump href="http://xmlgraphics.apache.org/repo.html">Apache XML Graphics Code Repositories</jump></li>
+          <li><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)</li>
+        </ul>
+      </section>
+    </section>
+    <section id="xml">
+      <title>XML</title>
+      <table>
+        <tr>
+          <th colspan="1" rowspan="1">Convention</th>
+          <th colspan="1" rowspan="1">Rationale</th>
+          <th colspan="1" rowspan="1">Enforced By</th>
+        </tr>
+        <tr>
+          <td colspan="1" rowspan="1">XML files must always be well-formed. Validation is optional.</td>
+          <td colspan="1" rowspan="1">Document integrity</td>
+          <td colspan="1" rowspan="1">Not enforced</td>
+        </tr>
+        <tr>
+          <td colspan="1" rowspan="1">No tabs in content.</td>
+          <td colspan="1" rowspan="1">Users should not have to adjust tab settings in their editor to be able to read the content.</td>
+          <td colspan="1" rowspan="1">Not enforced</td>
+        </tr>
+        <tr>
+          <td colspan="1" rowspan="1">Indentation of 2 spaces per level</td>
+          <td colspan="1" rowspan="1">Maximize readability</td>
+          <td colspan="1" rowspan="1">Not enforced</td>
+        </tr>
+      </table>
+    </section>
+  </body>
+</document>
\ No newline at end of file

Propchange: xmlgraphics/site/deploy/fop/dev/conventions.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: xmlgraphics/site/deploy/fop/dev/conventions.xml
------------------------------------------------------------------------------
    svn:keywords = Id

Modified: xmlgraphics/site/deploy/fop/dev/design/areas.html
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/areas.html?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/areas.html (original)
+++ xmlgraphics/site/deploy/fop/dev/design/areas.html Thu Aug 23 12:00:37 2007
@@ -58,10 +58,10 @@
 <a class="base-not-selected" href="../../index.html">Home</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.20.5/index.html">Version 0.20.5</a>
+<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
+<a class="base-not-selected" href="../../0.94/index.html">Version 0.94</a>
 </li>
 <li>
 <a class="base-not-selected" href="../../trunk/index.html">FOP Trunk</a>
@@ -244,9 +244,19 @@
     |start content
     +-->
 <div id="content">
+<div title="raw XML" class="xmllink">
+<a class="dida" href="areas.xml"><img alt="XML - icon" src="../../skin/images/xmldoc.gif" class="skin"><br>
+        XML</a>
+</div>
 <div title="Portable Document Format" class="pdflink">
 <a class="dida" href="areas.pdf"><img alt="PDF -icon" src="../../skin/images/pdfdoc.gif" class="skin"><br>
         PDF</a>
+</div>
+<div class="trail">
+<text>Font size:</text> 
+	          &nbsp;<input value="Reset" class="resetfont" title="Reset text" onclick="ndeSetTextSize('reset'); return false;" type="button">      
+	          &nbsp;<input value="-a" class="smallerfont" title="Shrink text" onclick="ndeSetTextSize('decr'); return false;" type="button">
+	          &nbsp;<input value="+a" class="biggerfont" title="Enlarge text" onclick="ndeSetTextSize('incr'); return false;" type="button">
 </div>
 <h1>FOP Design: Area Tree</h1>
 <div id="minitoc-area">

Modified: xmlgraphics/site/deploy/fop/dev/design/areas.pdf
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/areas.pdf?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/areas.pdf (original)
+++ xmlgraphics/site/deploy/fop/dev/design/areas.pdf Thu Aug 23 12:00:37 2007
@@ -651,8 +651,8 @@
 96 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F3
-/BaseFont /Helvetica-Bold
+/Name /F1
+/BaseFont /Helvetica
 /Encoding /WinAnsiEncoding >>
 endobj
 97 0 obj
@@ -665,8 +665,8 @@
 98 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F1
-/BaseFont /Helvetica
+/Name /F3
+/BaseFont /Helvetica-Bold
 /Encoding /WinAnsiEncoding >>
 endobj
 99 0 obj
@@ -697,7 +697,7 @@
 endobj
 3 0 obj
 << 
-/Font << /F3 96 0 R /F5 97 0 R /F1 98 0 R /F2 99 0 R /F7 100 0 R >> 
+/Font << /F1 96 0 R /F5 97 0 R /F3 98 0 R /F2 99 0 R /F7 100 0 R >> 
 /ProcSet [ /PDF /ImageC /Text ] >> 
 endobj
 9 0 obj
@@ -924,8 +924,8 @@
 0000019774 00000 n 
 0000019989 00000 n 
 0000020150 00000 n 
-0000020263 00000 n 
-0000020373 00000 n 
+0000020258 00000 n 
+0000020368 00000 n 
 0000020481 00000 n 
 0000020597 00000 n 
 trailer

Added: xmlgraphics/site/deploy/fop/dev/design/areas.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/areas.xml?rev=569118&view=auto
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/areas.xml (added)
+++ xmlgraphics/site/deploy/fop/dev/design/areas.xml Thu Aug 23 12:00:37 2007
@@ -0,0 +1,188 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+--><!-- $Id$ --><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd">
+<document>
+  <header>
+    <title>FOP Design: Area Tree</title>
+    <version>$Revision: 426576 $</version>
+    <authors>
+      <person name="Keiron Liddle" email="keiron@aftexsw.com"/>
+    </authors>
+  </header>
+  <body>
+    <section id="intro">
+    <title>Introduction</title>
+    <p>The Area Tree is an internal representation of the result document, representing pages and their contents.
+To make the concepts clearer and easier to understand, the code to implement the area tree matches the areas defined in the XSL-FO specification.</p>
+    <p>The area tree is created by the layout managers once the layout is decided for a page.
+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>
+    </section>
+    <section id="structure">
+      <title>Structure</title>
+      <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>
+    </section>
+    <section id="page">
+      <title>Page</title>
+      <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>
+    </section>
+    <section id="block">
+      <title>Block Areas</title>
+      <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>
+    </section>
+    <section id="line-area">
+      <title>Line Areas</title>
+      <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>
+    </section>
+    <section id="inline">
+      <title>Inline Areas</title>
+      <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>
+    </section>
+    <section id="repeated-area">
+      <title>Repeated Areas</title>
+      <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>
+    </section>
+    <section id="traits">
+      <title>Traits</title>
+      <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>
+    </section>
+    <section id="classes">
+      <title>Classes</title>
+      <p>The following class structure will be used to represent the area tree.</p>
+      <section id="classes-page">
+        <title>Page Area Classes</title>
+        <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>
+      </section>
+      <section id="classes-block">
+        <title>Block Area Classes</title>
+        <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>
+      </section>
+      <section id="classes-inline">
+        <title>Inline Area Classes</title>
+        <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>
+      </section>
+    </section>
+    <section id="forward-references">
+      <title>Forward References</title>
+      <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>
+    </section>
+    <section id="caching">
+      <title>Caching</title>
+      <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>
+    </section>
+    <section id="extensions">
+      <title>Extensions</title>
+      <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>
+    </section>
+    <section id="handlers">
+      <title>Area Tree Handlers</title>
+      <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>
+    </section>
+    <section id="status">
+      <title>Status</title>
+      <section id="status-todo">
+        <title>To Do</title>
+      </section>
+      <section id="status-wip">
+        <title>Work in Progress</title>
+      </section>
+      <section id="status-complete">
+        <title>Completed</title>
+        <ul>
+          <li>new area tree model</li>
+          <li>changed area tree xml format to match the area tree hierarchy</li>
+        </ul>
+      </section>
+    </section>
+  </body>
+</document>
\ No newline at end of file

Propchange: xmlgraphics/site/deploy/fop/dev/design/areas.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: xmlgraphics/site/deploy/fop/dev/design/areas.xml
------------------------------------------------------------------------------
    svn:keywords = Id

Modified: xmlgraphics/site/deploy/fop/dev/design/breakpos.html
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/breakpos.html?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/breakpos.html (original)
+++ xmlgraphics/site/deploy/fop/dev/design/breakpos.html Thu Aug 23 12:00:37 2007
@@ -58,10 +58,10 @@
 <a class="base-not-selected" href="../../index.html">Home</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.20.5/index.html">Version 0.20.5</a>
+<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
+<a class="base-not-selected" href="../../0.94/index.html">Version 0.94</a>
 </li>
 <li>
 <a class="base-not-selected" href="../../trunk/index.html">FOP Trunk</a>
@@ -244,9 +244,19 @@
     |start content
     +-->
 <div id="content">
+<div title="raw XML" class="xmllink">
+<a class="dida" href="breakpos.xml"><img alt="XML - icon" src="../../skin/images/xmldoc.gif" class="skin"><br>
+        XML</a>
+</div>
 <div title="Portable Document Format" class="pdflink">
 <a class="dida" href="breakpos.pdf"><img alt="PDF -icon" src="../../skin/images/pdfdoc.gif" class="skin"><br>
         PDF</a>
+</div>
+<div class="trail">
+<text>Font size:</text> 
+	          &nbsp;<input value="Reset" class="resetfont" title="Reset text" onclick="ndeSetTextSize('reset'); return false;" type="button">      
+	          &nbsp;<input value="-a" class="smallerfont" title="Shrink text" onclick="ndeSetTextSize('decr'); return false;" type="button">
+	          &nbsp;<input value="+a" class="biggerfont" title="Enlarge text" onclick="ndeSetTextSize('incr'); return false;" type="button">
 </div>
 <h1>FOP Design: Layout Managers</h1>
 <h3>Break Possibility Proposal</h3>

Modified: xmlgraphics/site/deploy/fop/dev/design/breakpos.pdf
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/breakpos.pdf?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/breakpos.pdf (original)
+++ xmlgraphics/site/deploy/fop/dev/design/breakpos.pdf Thu Aug 23 12:00:37 2007
@@ -508,8 +508,8 @@
 70 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F3
-/BaseFont /Helvetica-Bold
+/Name /F1
+/BaseFont /Helvetica
 /Encoding /WinAnsiEncoding >>
 endobj
 71 0 obj
@@ -522,22 +522,22 @@
 72 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F6
-/BaseFont /Times-Italic
+/Name /F3
+/BaseFont /Helvetica-Bold
 /Encoding /WinAnsiEncoding >>
 endobj
 73 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F1
-/BaseFont /Helvetica
+/Name /F2
+/BaseFont /Helvetica-Oblique
 /Encoding /WinAnsiEncoding >>
 endobj
 74 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F2
-/BaseFont /Helvetica-Oblique
+/Name /F6
+/BaseFont /Times-Italic
 /Encoding /WinAnsiEncoding >>
 endobj
 75 0 obj
@@ -561,7 +561,7 @@
 endobj
 3 0 obj
 << 
-/Font << /F3 70 0 R /F5 71 0 R /F1 73 0 R /F6 72 0 R /F2 74 0 R /F7 75 0 R >> 
+/Font << /F1 70 0 R /F5 71 0 R /F3 72 0 R /F2 73 0 R /F6 74 0 R /F7 75 0 R >> 
 /ProcSet [ /PDF /ImageC /Text ] >> 
 endobj
 9 0 obj
@@ -696,10 +696,10 @@
 0000023099 00000 n 
 0000023281 00000 n 
 0000023443 00000 n 
-0000023556 00000 n 
-0000023666 00000 n 
-0000023777 00000 n 
-0000023885 00000 n 
+0000023551 00000 n 
+0000023661 00000 n 
+0000023774 00000 n 
+0000023890 00000 n 
 0000024001 00000 n 
 trailer
 <<

Added: xmlgraphics/site/deploy/fop/dev/design/breakpos.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/breakpos.xml?rev=569118&view=auto
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/breakpos.xml (added)
+++ xmlgraphics/site/deploy/fop/dev/design/breakpos.xml Thu Aug 23 12:00:37 2007
@@ -0,0 +1,311 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+--><!-- $Id$ --><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd">
+<document>
+  <header>
+    <title>FOP Design: Layout Managers</title>
+    <subtitle>Break Possibility Proposal</subtitle>
+    <version>$Revision: 426576 $</version>
+    <authors>
+      <person name="Karen Lease" email="klease@club-internet.fr"/>
+    </authors>
+  </header>
+
+    <body>
+<section id="intro">
+  <title>Introduction</title>
+<p>
+As explained in <link href="layout.html">Layout</link>,
+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>
+</section>
+<section>
+  <title>Anatomy of a Break Possibility</title>
+<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>
+</section>
+<section>
+  <title>Turning Break Possibilities into Areas</title>
+<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>
+  </section>
+<section>
+  <title>A walk-through</title>
+<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>
+<p>The break possibilities are generated from the bottom up.
+All inline content must first be broken into
+lines which are then stacked into block areas. This is done by the
+LineLayoutManager, which creates line areas.
+The LineLM asks its child LM to generate a break possibility, which
+represents a place where the line can end. This
+initially means each potential line-end (primarily spaces or forced
+linefeeds and a few other potential line-end characters such as hard
+hyphens.) The text LM returns an object which stores the size in the
+stacking direction as a MinOptMax triplet
+and a <em>cost</em>, which is based on how well this break
+would satisfy the constraints. The Text LM keeps track of its position in
+the text content and returns the total size of the text area it would
+create if it were to break at a given point. The returned BP
+object also contains information about whether the break is forced
+(linefeed) or whether this is the last area which can be generated by
+the LM (ISLAST flag). If a textFO ends on a non-break character, the
+ISLAST flag is set, but the CAN_BREAK_AFTER flag isn't, since we don't
+know if there is any following text in another inline object for
+example.
+</p>
+<p>Variable size content is taken into account from
+the bottom up. Each LM returns a range of sizes in the stacking
+direction, based on property values. For text, this comes from
+variable word-space values or letter-space values. For other inline
+objects, it may include variable space-start and space-end values
+(after calculation of the entire sequence of space specifiers at a
+particular break possibility.)</p>
+<p>The main constraint for laying out
+lines is the available inline-progression-dimension (IPD) for the line
+area to be created. This
+depends on the IPD of the reference area ancestor, on the indents of the
+containing fo:block, and on any side-floats which may be intruding on
+this line.</p>
+<note>See below <link href="#getRefIPD">Getting the Reference
+IPD</link>
+for discussion of how the reference area IPD is
+transmitted to the Line LM.</note>
+<p>For now, let's assume that only the LineLM knows about the IPD
+available to it. Therefore only it can make a decision about which BP
+is the best one; the lower level inline layout managers can only
+return potential break points.</p>
+<note>There are certainly optimizations to this model which can be
+examined later.</note>
+<p>So the Line LM will ask its child LM(s) for break possibilities until
+it gets back a BP whose stacking dimension <em>could</em> fill the
+line. This means that the BP.stackdim.max &gt;= LineIPD.min. It can look
+for further BP, perhaps one whose stackdim.opt is closer to the
+LineIPD.opt. If it isn't happy with the choice of break possibilities,
+it can go past the end of the line to the next one, and then try to
+find a hyphenation point between the last one which fits and the first
+one which doesn't. If no possibility is found whose min/max values
+enclose the available IPD, some constraint will be violated (and
+reported in the log.) The actual strategy is up to the Line LM and
+should be able to be easily replaced without changing the architecture
+(Strategy pattern).
+</p>
+<p>The definition of a good break possibility depends on the
+properties at the block and inline level which govern things such as
+wrapping behavior and justification mode. For example, if lines are
+not to be wrapped, only an explicit linefeed can serve as a BP. If
+lines are wrapped but not justified then there is no requirement to
+completely fill the IPD on each line, but a sophisticated layout
+manager will try to achieve "aesthetic rag".
+</p>
+<p>Note that no areas have actually been created yet. Once the LineLM
+has found a potential break point for the inline content, it can
+calculate the total size of the line area which would be created. The
+size in the IPD is determined by the Line LM based on the chosen BP.
+The size of the line area in the the block-progression-dimension
+depends on the size of the text (or other inline content). These
+values are set by the inline-level LM
+in their returned BP (in terms of ascender and descender heights with
+respect to the baseline). The LineLM adds spacing implied by the
+current line-stacking strategy and line-height property values. It
+stores a reference to the chosen inline BP and "wraps" that in its own
+Position object which it stores in the BP it returns to its parent LM
+(the block layout manager).
+</p><p>The block LM now has a potential break position after its
+first line. It assigns that possibility a cost, based on widow, orphan
+and keep properties. It can also calculate the total size of the block
+area it would create, were it to end the area after this line. It does
+this by adding any padding and border (taking into account
+conditionality). It also calculates space-before and space-after
+values, or contributes to building up a sequence of such values.
+With this information, the block LM creates a new BP (or
+updates the existing one). It stores a Position object in this
+BP which wraps the returned BP from its child Line LM.
+It returns the new BP to its parent and so on, back up to the
+FlowLM.</p>
+<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>
+</section>
+<section>
+  <title>Some issues</title>
+<p>Following are a few remarks on specific issues.</p>
+<section>
+  <title>Where Line Layout Managers are created</title>
+<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>
+</section>
+<section id="getRefIPD">
+  <title>Getting the reference IPD</title>
+<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
+will 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>
+</section>
+<section>
+  <title>Hyphenation</title>
+<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>
+</section>
+<section>
+  <title>Optimizing</title>
+<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>
+</section>
+</section>
+    </body>
+</document>
\ No newline at end of file

Propchange: xmlgraphics/site/deploy/fop/dev/design/breakpos.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: xmlgraphics/site/deploy/fop/dev/design/breakpos.xml
------------------------------------------------------------------------------
    svn:keywords = Id

Modified: xmlgraphics/site/deploy/fop/dev/design/embedding.html
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/embedding.html?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/embedding.html (original)
+++ xmlgraphics/site/deploy/fop/dev/design/embedding.html Thu Aug 23 12:00:37 2007
@@ -58,10 +58,10 @@
 <a class="base-not-selected" href="../../index.html">Home</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.20.5/index.html">Version 0.20.5</a>
+<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
+<a class="base-not-selected" href="../../0.94/index.html">Version 0.94</a>
 </li>
 <li>
 <a class="base-not-selected" href="../../trunk/index.html">FOP Trunk</a>
@@ -244,10 +244,20 @@
     |start content
     +-->
 <div id="content">
+<div title="raw XML" class="xmllink">
+<a class="dida" href="embedding.xml"><img alt="XML - icon" src="../../skin/images/xmldoc.gif" class="skin"><br>
+        XML</a>
+</div>
 <div title="Portable Document Format" class="pdflink">
 <a class="dida" href="embedding.pdf"><img alt="PDF -icon" src="../../skin/images/pdfdoc.gif" class="skin"><br>
         PDF</a>
 </div>
+<div class="trail">
+<text>Font size:</text> 
+	          &nbsp;<input value="Reset" class="resetfont" title="Reset text" onclick="ndeSetTextSize('reset'); return false;" type="button">      
+	          &nbsp;<input value="-a" class="smallerfont" title="Shrink text" onclick="ndeSetTextSize('decr'); return false;" type="button">
+	          &nbsp;<input value="+a" class="biggerfont" title="Enlarge text" onclick="ndeSetTextSize('incr'); return false;" type="button">
+</div>
 <h1>FOP Design: Embedding FOP in Other Applications</h1>
 <div id="minitoc-area">
 <ul class="minitoc">
@@ -295,7 +305,7 @@
   </p>
 <p>
 Common places where FOP is embedded is in a report production application
-of a server side application such as <a target="_top" href="http://xml.apache.org/cocoon/index.html">Cocoon</a>.
+of a server side application such as <a class="external" href="http://xml.apache.org/cocoon/index.html">Cocoon</a>.
    </p>
 </div>
 

Modified: xmlgraphics/site/deploy/fop/dev/design/embedding.pdf
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/embedding.pdf?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/embedding.pdf (original)
+++ xmlgraphics/site/deploy/fop/dev/design/embedding.pdf Thu Aug 23 12:00:37 2007
@@ -396,8 +396,8 @@
 58 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F3
-/BaseFont /Helvetica-Bold
+/Name /F1
+/BaseFont /Helvetica
 /Encoding /WinAnsiEncoding >>
 endobj
 59 0 obj
@@ -410,8 +410,8 @@
 60 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F1
-/BaseFont /Helvetica
+/Name /F3
+/BaseFont /Helvetica-Bold
 /Encoding /WinAnsiEncoding >>
 endobj
 61 0 obj
@@ -442,7 +442,7 @@
 endobj
 3 0 obj
 << 
-/Font << /F3 58 0 R /F5 59 0 R /F1 60 0 R /F2 61 0 R /F7 62 0 R >> 
+/Font << /F1 58 0 R /F5 59 0 R /F3 60 0 R /F2 61 0 R /F7 62 0 R >> 
 /ProcSet [ /PDF /ImageC /Text ] >> 
 endobj
 9 0 obj
@@ -571,8 +571,8 @@
 0000010662 00000 n 
 0000010837 00000 n 
 0000010975 00000 n 
-0000011088 00000 n 
-0000011198 00000 n 
+0000011083 00000 n 
+0000011193 00000 n 
 0000011306 00000 n 
 0000011422 00000 n 
 trailer

Added: xmlgraphics/site/deploy/fop/dev/design/embedding.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/embedding.xml?rev=569118&view=auto
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/embedding.xml (added)
+++ xmlgraphics/site/deploy/fop/dev/design/embedding.xml Thu Aug 23 12:00:37 2007
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+--><!-- $Id$ --><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd">
+<document>
+  <header>
+    <title>FOP Design: Embedding FOP in Other Applications</title>
+    <version>$Revision: 426576 $</version>
+    <authors>
+      <person name="Keiron Liddle" email="keiron@aftexsw.com"/>
+    </authors>
+  </header>
+
+    <body>
+<section id="intro">
+  <title>Introduction</title>
+<p>
+This is the design for the external interface when 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>
+  </section>
+<section>
+  <title>Settings</title>
+<section>
+  <title>User Agent</title>
+<p>
+Possible meanings for a user agent:
+</p>
+<ul>
+<li>something that makes decisions where the specifiction indicates
+that the user agent should decide</li>
+<li>FOP as the user agent, represented by a class that handles
+various setup and decision values</li>
+<li>an class that handles context for a particular FOP conversion
+that can be configured/overridden when embedding</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>
+  </section>
+<section>
+  <title>Logging</title>
+<ul>
+<li>logging level</li>
+<li>logging messages of various levels</li>
+<li>error handling</li>
+<li>Logging setup (LogKit, Log4J, JDK14Logging)</li>
+</ul>
+  </section>
+<section>
+  <title>XML input</title>
+<ul>
+<li>various ways to supply FOP with the xsl:fo file, fo, xml+xsl</li>
+<li>sax handler</li>
+</ul>
+  </section>
+<section>
+  <title>general options</title>
+<ul>
+<li>base url</li>
+<li>uri resolvers</li>
+<li>which implementation of a particular LayoutManager to use</li>
+</ul>
+  </section>
+<section>
+  <title>Rendering Options</title>
+<ul>
+<li>embedding fonts</li>
+<li>compression in pdf</li>
+<li>image embedding</li>
+</ul>
+<p>
+for the PS renderer (eventually):
+</p>
+<ul>
+<li>PostScript Level</li>
+<li>PPD to use</li>
+<li>binary/ascii switch</li>
+</ul>
+  </section>
+<section>
+  <title>Render Results</title>
+<p>
+Generate Output statistics from FOP:
+   </p>
+<ul>
+<li>Number of pages total</li>
+<li>Number of pages of each page-sequence</li>
+<li>page-master used for each page (could be used to control
+the paper bin to get paper from, important for me in conjunction
+with PS Renderer)</li>
+<li>recoverable errors such as overflow</li>
+</ul>
+  </section>
+<section>
+  <title>Setting Up</title>
+<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>
+  </section>
+<section>
+  <title>Others</title>
+<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>
+  </section>
+</section>
+
+    </body>
+</document>
\ No newline at end of file

Propchange: xmlgraphics/site/deploy/fop/dev/design/embedding.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: xmlgraphics/site/deploy/fop/dev/design/embedding.xml
------------------------------------------------------------------------------
    svn:keywords = Id

Modified: xmlgraphics/site/deploy/fop/dev/design/extending.html
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/extending.html?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/extending.html (original)
+++ xmlgraphics/site/deploy/fop/dev/design/extending.html Thu Aug 23 12:00:37 2007
@@ -58,10 +58,10 @@
 <a class="base-not-selected" href="../../index.html">Home</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.20.5/index.html">Version 0.20.5</a>
+<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
+<a class="base-not-selected" href="../../0.94/index.html">Version 0.94</a>
 </li>
 <li>
 <a class="base-not-selected" href="../../trunk/index.html">FOP Trunk</a>
@@ -244,9 +244,19 @@
     |start content
     +-->
 <div id="content">
+<div title="raw XML" class="xmllink">
+<a class="dida" href="extending.xml"><img alt="XML - icon" src="../../skin/images/xmldoc.gif" class="skin"><br>
+        XML</a>
+</div>
 <div title="Portable Document Format" class="pdflink">
 <a class="dida" href="extending.pdf"><img alt="PDF -icon" src="../../skin/images/pdfdoc.gif" class="skin"><br>
         PDF</a>
+</div>
+<div class="trail">
+<text>Font size:</text> 
+	          &nbsp;<input value="Reset" class="resetfont" title="Reset text" onclick="ndeSetTextSize('reset'); return false;" type="button">      
+	          &nbsp;<input value="-a" class="smallerfont" title="Shrink text" onclick="ndeSetTextSize('decr'); return false;" type="button">
+	          &nbsp;<input value="+a" class="biggerfont" title="Enlarge text" onclick="ndeSetTextSize('incr'); return false;" type="button">
 </div>
 <h1>FOP Design: Extensions</h1>
 <div id="minitoc-area">

Modified: xmlgraphics/site/deploy/fop/dev/design/extending.pdf
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/extending.pdf?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/extending.pdf (original)
+++ xmlgraphics/site/deploy/fop/dev/design/extending.pdf Thu Aug 23 12:00:37 2007
@@ -271,8 +271,8 @@
 42 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F3
-/BaseFont /Helvetica-Bold
+/Name /F1
+/BaseFont /Helvetica
 /Encoding /WinAnsiEncoding >>
 endobj
 43 0 obj
@@ -285,22 +285,22 @@
 44 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F1
-/BaseFont /Helvetica
+/Name /F3
+/BaseFont /Helvetica-Bold
 /Encoding /WinAnsiEncoding >>
 endobj
 45 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F9
-/BaseFont /Courier
+/Name /F2
+/BaseFont /Helvetica-Oblique
 /Encoding /WinAnsiEncoding >>
 endobj
 46 0 obj
 << /Type /Font
 /Subtype /Type1
-/Name /F2
-/BaseFont /Helvetica-Oblique
+/Name /F9
+/BaseFont /Courier
 /Encoding /WinAnsiEncoding >>
 endobj
 47 0 obj
@@ -324,7 +324,7 @@
 endobj
 3 0 obj
 << 
-/Font << /F3 42 0 R /F5 43 0 R /F1 44 0 R /F9 45 0 R /F2 46 0 R /F7 47 0 R >> 
+/Font << /F1 42 0 R /F5 43 0 R /F3 44 0 R /F2 45 0 R /F9 46 0 R /F7 47 0 R >> 
 /ProcSet [ /PDF /ImageC /Text ] >> 
 endobj
 9 0 obj
@@ -419,10 +419,10 @@
 0000008101 00000 n 
 0000008311 00000 n 
 0000008467 00000 n 
-0000008580 00000 n 
-0000008690 00000 n 
+0000008575 00000 n 
+0000008685 00000 n 
 0000008798 00000 n 
-0000008904 00000 n 
+0000008914 00000 n 
 0000009020 00000 n 
 trailer
 <<

Added: xmlgraphics/site/deploy/fop/dev/design/extending.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/extending.xml?rev=569118&view=auto
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/extending.xml (added)
+++ xmlgraphics/site/deploy/fop/dev/design/extending.xml Thu Aug 23 12:00:37 2007
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+--><!-- $Id$ --><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd">
+<document>
+  <header>
+    <title>FOP Design: Extensions</title>
+    <version>$Revision: 426576 $</version>
+    <authors>
+      <person name="Keiron Liddle" email="keiron@aftexsw.com"/>
+    </authors>
+  </header>
+
+    <body>
+<section id="intro">
+  <title>Introduction</title>
+<p>
+FOP provides an extension mechanism to add extra functionality. There
+are a number of different types of extensions that apply to different
+steps when converting FO into the rendered output.
+  </p>
+  </section>
+<section>
+  <title>Extensions</title>
+  <p>
+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>
+  <p>
+FO Area - This is where an extension creates an normal or extended
+area in the Area Tree. This is useful when the normal FO objects
+cannot create the area in the way that is needed.
+  </p>
+  <p>
+Resolveable - In some cases it may require information to be
+resolved for information such as page numbers. This can apply
+to the XML Document, FO Area or output document extensions.
+   </p>
+  <ul>
+<li>Add a string ['(Continued)'] to a table header if the table spans
+multiple pages. These tables are part of the content and can start
+anywhere in the page.</li>
+  <li>Separate page number display for a subsection. ie. - master document
+is page 4 of 7, but subsection is page 2 of 3.</li>
+   </ul>
+</section>
+<section>
+  <title>Examples</title>
+  <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>
+  <p>
+For example:</p>
+<source xml:space="preserve"><![CDATA[<my:script-link script="app.execMenuItem('AcroSrch:Query');">
+Search
+</my:script-link>]]></source>
+<p>
+to result in a text box referencing the following PDF action:</p>
+<source xml:space="preserve"><![CDATA[<<
+/S /JavaScript
+/JS (app.execMenuItem("AcroSrch:Query");)
+>>]]></source>
+
+</section>
+    <section id="status">
+      <title>Status</title>
+      <section id="status-todo">
+        <title>To Do</title>
+      </section>
+      <section id="status-wip">
+        <title>Work In Progress</title>
+        <ul>
+          <li>mathml extension</li>
+          <li>another xml -&gt; svg extension</li>
+          <li>svg text normal text if that can be handled otherwise stroked this is done automatically</li>
+        </ul>
+      </section>
+      <section id="status-complete">
+        <title>Completed</title>
+        <ul>
+          <li>svg now in an xml handler, FOP can be used without batik</li>
+          <li>bookmark extension improved a bit - changed bookmark extension, now requires a wrapping element bookmark</li>
+        </ul>
+      </section>
+    </section>
+    </body>
+</document>
\ No newline at end of file

Propchange: xmlgraphics/site/deploy/fop/dev/design/extending.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: xmlgraphics/site/deploy/fop/dev/design/extending.xml
------------------------------------------------------------------------------
    svn:keywords = Id

Modified: xmlgraphics/site/deploy/fop/dev/design/fotree.html
URL: http://svn.apache.org/viewvc/xmlgraphics/site/deploy/fop/dev/design/fotree.html?rev=569118&r1=569117&r2=569118&view=diff
==============================================================================
--- xmlgraphics/site/deploy/fop/dev/design/fotree.html (original)
+++ xmlgraphics/site/deploy/fop/dev/design/fotree.html Thu Aug 23 12:00:37 2007
@@ -58,10 +58,10 @@
 <a class="base-not-selected" href="../../index.html">Home</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.20.5/index.html">Version 0.20.5</a>
+<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
 </li>
 <li>
-<a class="base-not-selected" href="../../0.93/index.html">Version 0.93</a>
+<a class="base-not-selected" href="../../0.94/index.html">Version 0.94</a>
 </li>
 <li>
 <a class="base-not-selected" href="../../trunk/index.html">FOP Trunk</a>
@@ -244,9 +244,19 @@
     |start content
     +-->
 <div id="content">
+<div title="raw XML" class="xmllink">
+<a class="dida" href="fotree.xml"><img alt="XML - icon" src="../../skin/images/xmldoc.gif" class="skin"><br>
+        XML</a>
+</div>
 <div title="Portable Document Format" class="pdflink">
 <a class="dida" href="fotree.pdf"><img alt="PDF -icon" src="../../skin/images/pdfdoc.gif" class="skin"><br>
         PDF</a>
+</div>
+<div class="trail">
+<text>Font size:</text> 
+	          &nbsp;<input value="Reset" class="resetfont" title="Reset text" onclick="ndeSetTextSize('reset'); return false;" type="button">      
+	          &nbsp;<input value="-a" class="smallerfont" title="Shrink text" onclick="ndeSetTextSize('decr'); return false;" type="button">
+	          &nbsp;<input value="+a" class="biggerfont" title="Enlarge text" onclick="ndeSetTextSize('incr'); return false;" type="button">
 </div>
 <h1>FOP Design: FO Tree</h1>
 <div id="minitoc-area">



---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org


Mime
View raw message