svn commit: r742949 - /xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml

[vh...@apache.org]

Author: vhennebert
Date: Tue Feb 10 12:17:46 2009
New Revision: 742949

URL: http://svn.apache.org/viewvc?rev=742949&view=rev
Log:
Fixed a few typos

Modified:
    xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml

Modified: xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml?rev=742949&r1=742948&r2=742949&view=diff
==============================================================================
--- xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml (original)
+++ xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml Tue Feb 10 12:17:46 2009
@@ -31,15 +31,16 @@
       <title>Introduction</title>
       <p>
         Apache FOP now provides two different so-called intermediate formats. The first one
-        (let's call it the area tree XML format) is basically a 1:1 XML representation of the FOP's
-        area tree generated by the layout engine. The area tree is conceptually defined in the 
+        (let's call it the area tree XML format) is basically a 1:1 XML representation of FOP's
+        area tree as generated by the layout engine. The area tree is conceptually defined in the 
         <a href="http://www.w3.org/TR/2001/REC-xsl-20011015/slice1.html#section-N742-Formatting">XSL-FO specification in chapter 1.1.2</a>.
         Even though the area tree is mentioned in the XSL-FO specification, this part is not
         standardized. Therefore, the area tree XML format is a FOP-proprietary XML file format.
         The area tree XML can be generated through the area tree XML Renderer (the XMLRenderer).
       </p>
       <p>
-        The second intermediate format (which we shall it exactly that: the intermediate format)
+        The second intermediate format (which we shall name exactly like this: the intermediate 
+        format)
         is a recent addition which tries to meet a slightly different set of goals. It is highly
         optimized for speed.
       </p>
@@ -54,8 +55,8 @@
     <section id="which-if">
       <title>Which Intermediate Format to choose?</title>
       <p>
-        There are two formats to choose from, so the question which format to choose is obvious.
-        Here's a list of strengths and use cases for both formats:
+        Both formats have their use cases, so the choice you will make will depend on your 
+        particular situation. Here is a list of strengths and use cases for both formats:
       </p>
       <section id="strengths-at">
         <title>Area Tree XML (AT XML)</title>
@@ -79,10 +80,6 @@
         </ul>
       </section>
       <p>
-        Both formats have their use cases. You will need to choose for yourself which format is
-        suitable for your use case.
-      </p>
-      <p>
         More technical information about the two formats can be found on the
         <a href="http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign">FOP Wiki</a>.
       </p>
@@ -103,7 +100,7 @@
       <p>
         However, there is an important detail to consider: The
         various Renderers don't all use the same font sources. To be able to create the right
-        area tree for the ultimate output file, you need to create the area tree XML file using
+        area tree for the ultimate output format, you need to create the area tree XML file using
         the right font setup. This is achieved by telling the XMLRenderer to mimic another
         renderer. This is done by calling the XMLRenderer's mimicRenderer() method with an
         instance of the ultimate target renderer as the single parameter. This has a consequence:
@@ -325,7 +322,7 @@
           designed to allow for maximum flexibility and optimization. So rather than just passing
           in a StreamResult to IFSerializer's setResult() method, you can also use a SAXResult
           or a DOMResult. And as you've already seen , the IFParser on the other side allows you
-          to retrieve a ContentHandler instance where you can manually send SAX events to to
+          to retrieve a ContentHandler instance where you can manually send SAX events to
           start the parsing process (see <code>getContentHandler()</code>).
         </p>
       </section>



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