diff options
| -rw-r--r-- | docs/design/understanding/area_tree.xml | 30 | ||||
| -rw-r--r-- | docs/design/understanding/fo_tree.xml | 12 | ||||
| -rw-r--r-- | docs/design/understanding/handling_attributes.xml | 20 | ||||
| -rw-r--r-- | docs/design/understanding/images.xml | 30 | ||||
| -rw-r--r-- | docs/design/understanding/layout_managers.xml | 18 | ||||
| -rw-r--r-- | docs/design/understanding/layout_process.xml | 20 | ||||
| -rw-r--r-- | docs/design/understanding/pdf_library.xml | 26 | ||||
| -rw-r--r-- | docs/design/understanding/properties.xml | 20 | ||||
| -rw-r--r-- | docs/design/understanding/renderers.xml | 30 | ||||
| -rw-r--r-- | docs/design/understanding/status.xml | 26 | ||||
| -rw-r--r-- | docs/design/understanding/svg.xml | 108 | ||||
| -rw-r--r-- | docs/design/understanding/understanding.xml | 72 | ||||
| -rw-r--r-- | docs/design/understanding/xml_parsing.xml | 40 |
13 files changed, 226 insertions, 226 deletions
diff --git a/docs/design/understanding/area_tree.xml b/docs/design/understanding/area_tree.xml index 9013f647a..4dbe9e6e4 100644 --- a/docs/design/understanding/area_tree.xml +++ b/docs/design/understanding/area_tree.xml @@ -1,13 +1,13 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Area Tree</title> - <subtitle>All you wanted to know about the Area Tree !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="Area Tree"> +<document> + <header> + <title>Area Tree</title> + <subtitle>All you wanted to know about the Area Tree !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="Area Tree"> <s2 title="Area Tree"> <p>The Area Tree is an internal representation of the result document. This is a set of java classes that can put together a set of objects that @@ -16,7 +16,7 @@ represent the pages and their contents.</p> output using a renderer.</p> <p>The Area Tree follows the description of the area tree in the XSL:FO specification.</p> -<p>The Area Tree consists of a set of pages, the actual implemenation places +<p>The Area Tree consists of a set of pages, the actual implemenation places these in a set of page sequences.</p></s2> @@ -25,7 +25,7 @@ a set of page sequences.</p></s2> <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 +<p>Inside the page is a set of RegionViewport+Region pairs for each region on the page.</p></s2> @@ -42,7 +42,7 @@ 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 +<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></s2> @@ -69,8 +69,8 @@ line area or from the block area.</p></s2> 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 +<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></s2> @@ -103,7 +103,7 @@ 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 +renderer. This is useful for setting the title and organising the groups of page sequences.</p></s2> @@ -113,5 +113,5 @@ of page sequences.</p></s2> <li>Caching implementation.</li></ul></s2> - </s1> + </s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/fo_tree.xml b/docs/design/understanding/fo_tree.xml index 83e58ef8c..cbe5e5f35 100644 --- a/docs/design/understanding/fo_tree.xml +++ b/docs/design/understanding/fo_tree.xml @@ -1,11 +1,11 @@ <?xml version="1.0"?> <document> - <header> - <title>FO Tree</title> - <subtitle>All you wanted to know about FO Tree !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> + <header> + <title>FO Tree</title> + <subtitle>All you wanted to know about FO Tree !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> <body><s1 title="FO Tree"> <p> The FO Tree is a representation of the XSL:FO document. This diff --git a/docs/design/understanding/handling_attributes.xml b/docs/design/understanding/handling_attributes.xml index 1ae043059..81af0b40f 100644 --- a/docs/design/understanding/handling_attributes.xml +++ b/docs/design/understanding/handling_attributes.xml @@ -1,13 +1,13 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Handling Attributes</title> - <subtitle>All you wanted to know about FOP Handling Attributes !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="Handling Attributes"> - <p>Yet to come :))</p> - <note>The series of notes for developers has started but it has not yet gone so far ! Keep watching</note></s1> +<document> + <header> + <title>Handling Attributes</title> + <subtitle>All you wanted to know about FOP Handling Attributes !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="Handling Attributes"> + <p>Yet to come :))</p> + <note>The series of notes for developers has started but it has not yet gone so far ! Keep watching</note></s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/images.xml b/docs/design/understanding/images.xml index 6aaa82bc8..68d71bcf2 100644 --- a/docs/design/understanding/images.xml +++ b/docs/design/understanding/images.xml @@ -1,21 +1,21 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Images</title> - <subtitle>All you wanted to know about Images in FOP !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> +<document> + <header> + <title>Images</title> + <subtitle>All you wanted to know about Images in FOP !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> <body> - - <s1 title="Images in FOP"> <note> this is still in progress, input in the code is welcome. Needs documenting formats, testing. + + <s1 title="Images in FOP"> <note> this is still in progress, input in the code is welcome. Needs documenting formats, testing. So all those people interested in images should get involved.</note> - <p>Images may only be needed to be loaded when the image is rendered to the + <p>Images may only be needed to be loaded when the image is rendered to the output or to find the dimensions.<br/> An image url may be invalid, this can be costly to find out so we need to -keep a list of invalid image urls.</p> +keep a list of invalid image urls.</p> <p>We have a number of different caching schemes that are possible.</p> <p>All images are referred to using the url given in the XSL:FO after removing "url('')" wrapping. This does @@ -25,7 +25,7 @@ have the url as a reference. The images are handled through a static interface in ImageFactory.<br/></p> -<p>(insert image)</p> +<p>(insert image)</p> <s2 title="Threading"> @@ -129,9 +129,8 @@ then load the required data depending on the image mime type. If the renderer can insert the image into the document and use that data for all future references of the same image then it can cache the reference in the renderer and the image can be released from the image cache.</p></s2> -</s1> +</s1> </body></document> - @@ -143,4 +142,5 @@ renderer and the image can be released from the image cache.</p></s2> - + + diff --git a/docs/design/understanding/layout_managers.xml b/docs/design/understanding/layout_managers.xml index 48e85c94b..297531b2d 100644 --- a/docs/design/understanding/layout_managers.xml +++ b/docs/design/understanding/layout_managers.xml @@ -1,13 +1,13 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Layout Managers</title> - <subtitle>All you wanted to know about Layout Managers !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="Layout Managers"> +<document> + <header> + <title>Layout Managers</title> + <subtitle>All you wanted to know about Layout Managers !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="Layout Managers"> @@ -63,5 +63,5 @@ the flow.</p> <note>(note: more info to follow)</note> -</s1> +</s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/layout_process.xml b/docs/design/understanding/layout_process.xml index 4c426d8eb..cc9c7fc18 100644 --- a/docs/design/understanding/layout_process.xml +++ b/docs/design/understanding/layout_process.xml @@ -1,13 +1,13 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Layout Process</title> - <subtitle>All you wanted to know about the Layout Process !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="Layout Process"> - <p>Yet to come :))</p> - <note>The series of notes for developers has started but it has not yet gone so far ! Keep watching</note></s1> +<document> + <header> + <title>Layout Process</title> + <subtitle>All you wanted to know about the Layout Process !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="Layout Process"> + <p>Yet to come :))</p> + <note>The series of notes for developers has started but it has not yet gone so far ! Keep watching</note></s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/pdf_library.xml b/docs/design/understanding/pdf_library.xml index 434cc03f8..642ca9ec3 100644 --- a/docs/design/understanding/pdf_library.xml +++ b/docs/design/understanding/pdf_library.xml @@ -1,13 +1,13 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>PDF Library</title> - <subtitle>All you wanted to know about the PDF Library !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="PDF Library"> +<document> + <header> + <title>PDF Library</title> + <subtitle>All you wanted to know about the PDF Library !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="PDF Library"> <p>The PDF Library is an independant package of classes in FOP. These class provide a simple way to construct documents and add the contents. The @@ -26,12 +26,12 @@ There are a number of methods that can be used to create/add certain PDF objects <p>The PDF Document is built by creating a page for each page in the Area Tree.</p> <p> This page then has all the contents added. The page is then added to the document and available objects can be written to the output stream.</p> -<p>The contents of the page are things such as text, lines, images etc. -The PDFRenderer inserts the text directly into a pdf stream. +<p>The contents of the page are things such as text, lines, images etc. +The PDFRenderer inserts the text directly into a pdf stream. The text consists of markup to set fonts, set text position and add text.</p> -<p>Most of the simple pdf markup is inserted directly into a pdf stream. +<p>Most of the simple pdf markup is inserted directly into a pdf stream. Other more complex objects or commonly used objects are added through java classes. -Some pdf objects such as an image consists of two parts.</p> +Some pdf objects such as an image consists of two parts.</p> <p>It has a separate object for the image data and another bit of markup to display the image in a certain position on the page. </p><p>The java objects that represent a pdf object implement a method that returns the markup for inserting into a stream. The method is: byte[] toPDF().</p> @@ -74,5 +74,5 @@ The method is: byte[] toPDF().</p> - </s1> + </s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/properties.xml b/docs/design/understanding/properties.xml index 529ec8673..442e3ed64 100644 --- a/docs/design/understanding/properties.xml +++ b/docs/design/understanding/properties.xml @@ -1,13 +1,13 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Properties</title> - <subtitle>All you wanted to know about the Properties !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="Property Handling"> +<document> + <header> + <title>Properties</title> + <subtitle>All you wanted to know about the Properties !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="Property Handling"> <p>During XML Parsing, the FO tree is constructed. For each FO object (some subclass of FObj), the tree builder then passes the list of all attributes specified on the FO element to the handleAttrs method. This @@ -115,7 +115,7 @@ but may not be completely up-to-date</dd></dl></s2> <s2 title="To Do"> <s3 title="documentation"> - + <ul><li>explain PropertyManager vs. direct access</li> <li>Explain corresponding properties</li></ul></s3> @@ -126,5 +126,5 @@ but may not be completely up-to-date</dd></dl></s2> keyword values and shorthand values (one attribute which sets several properties)</p></s3></s2> -</s1> +</s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/renderers.xml b/docs/design/understanding/renderers.xml index e597d118b..d3db3647c 100644 --- a/docs/design/understanding/renderers.xml +++ b/docs/design/understanding/renderers.xml @@ -1,13 +1,13 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Renderers</title> - <subtitle>All you wanted to know about the Renderers !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="Renderers"> +<document> + <header> + <title>Renderers</title> + <subtitle>All you wanted to know about the Renderers !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="Renderers"> <s2 title="Renderers"> @@ -18,21 +18,21 @@ in the order they appear in the document. In order to save memory it is possble to render the pages out of order. Any page that is not reeady to be rendered is setup by the renderer first so that it can reserve a space or reference for when the page is ready to be rendered.</p> -<p>The AbstractRenderer does most of the work to iterate through the area -tree parts. This means that the most renderers simply need to implement -the specific parts with inserting text, images and lines. The methods can -easily be overridden to handle things in a different way or do some extra +<p>The AbstractRenderer does most of the work to iterate through the area +tree parts. This means that the most renderers simply need to implement +the specific parts with inserting text, images and lines. The methods can +easily be overridden to handle things in a different way or do some extra processing.</p></s2> <s2 title="Fonts"> -<p>The fonts are setup by the renderer being used. The font metrics are used +<p>The fonts are setup by the renderer being used. The font metrics are used during the layout process to determine the size of characters.</p> </s2> <s2 title="Render Context"> -<p>The render context is used by handlers. It contains information about the -current state of the renderer. Such as the page, the position and any +<p>The render context is used by handlers. It contains information about the +current state of the renderer. Such as the page, the position and any other miscellanous objects that are required to draw into the page.</p></s2> diff --git a/docs/design/understanding/status.xml b/docs/design/understanding/status.xml index c1e7fb1ea..f0bbdce30 100644 --- a/docs/design/understanding/status.xml +++ b/docs/design/understanding/status.xml @@ -1,17 +1,17 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>Tutorial series Status</title> - <subtitle>Current Status of tutorial about FOP and Design</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> +<document> + <header> + <title>Tutorial series Status</title> + <subtitle>Current Status of tutorial about FOP and Design</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> <body><s1 title="Tutorial series Status"> <p>Peter said : Do we have a volunteer to track - Keiron's tutorials and turn them into web page documentation?</p> <p><strong>The answer is yes - we have, but the work is on progress !</strong></p> <note>Keiron has recently extended - the documentation generation on the CVS trunk to make this process a bit - easier. Keiron tells Peter that Apache is readying a major overhaul of its web - site and xml->html generation, but that should not deter us from proceeding - with documentation.</note></s1> + Keiron's tutorials and turn them into web page documentation?</p> <p><strong>The answer is yes + we have, but the work is on progress !</strong></p> <note>Keiron has recently extended + the documentation generation on the CVS trunk to make this process a bit + easier. Keiron tells Peter that Apache is readying a major overhaul of its web + site and xml->html generation, but that should not deter us from proceeding + with documentation.</note></s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/svg.xml b/docs/design/understanding/svg.xml index 7fd19f369..942a91358 100644 --- a/docs/design/understanding/svg.xml +++ b/docs/design/understanding/svg.xml @@ -1,57 +1,57 @@ <?xml version="1.0" standalone="no"?> <!-- Overview --> -<document> - <header> - <title>SVG</title> - <subtitle>All you wanted to know about SVG and FOP !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> - <body><s1 title="SVG"> - <p>SVG is rendered through Batik.</p><p>The XML from the XSL:FO document - is converted into an SVG DOM with batik. This DOM is then set as the Document - on the Foreign Object area in the Area Tree.</p><p>This DOM is then available to - be rendered by the renderer.</p><p>SVG is rendered in the renderers via an - XMLHandler in the FOUserAgent. This XML handler is used to render the SVG. The - SVG is rendered by using batik. Batik converts the SVG DOM into an internal - structure that can be drawn into a Graphics2D. So for PDF we use a - PDFGraphics2D to draw into.</p><p>This creates the necessary PDF information to - create the SVG image in the PDF document.</p><p>Most of the work is done in the - PDFGraphics2D class. There are also a few bridges that are plugged into batik - to provide different behaviour for some SVG elements.</p><s2 - title="Text Drawing"><p>Normally batik converts text into a set of curved - shapes. </p><p>This is handled as any other shapes when rendering to the output. This - is not always desirable as the shapes have very fine curves. This can cause the - output to look a bit bad in PDF and PS (it can be drawn properly but is not by - default). These curves also require much more data than the original - text.</p><p>To handle this there is a PDFTextElementBridge that is set when - using the bridge in batik. If the text is simple enough for the text to be - drawn in the PDF as with all other text then this sets the TextPainter to use - the PDFTextPainter. This inserts the text directly into the PDF using the - drawString method on the PDFGraphics2D.</p><p>Text is considered simple if the - font is available, the font size is useable and there are no tspans or other - complications. This can make the resulting PDF significantly - smaller.</p></s2><s2 title="PDF Links"><p>To support links in PDF another batik - element bridge is used. The PDFAElementBridge creates a PDFANode which inserts - a link into the PDF document via the PDFGraphics2D.</p><p>Since links are - positioned on the page without any transforms then we need to transform the - coordinates of the link area so that they match the current position of the a - element area. This transform may also need to account for the svg being - positioned on the page.</p></s2><s2 title="Images"><p>Images are normally drawn - into the PDFGraphics2D. This then creates a bitmap of the image data that can - be inserted into the PDF document. </p><p>As PDF can support jpeg images then another - element bridge is used so that the jpeg can be directly inserted into the - PDF.</p></s2><s2 title="PDF Transcoder"><p>Batik provides a mechanism to - convert SVG into various formats. Through FOP we can convert an SVG document - into a single paged PDF document. The page contains the SVG drawn as best as - possible on the page. There is a PDFDocumentGraphics2D that creates a - standalone PDF document with a single page. This is then drawn into by batik in - the same way as with the PDFGraphics2D.</p></s2><s2 - title="Other Outputs"><p>When rendering to AWT the SVG is simply drawn onto the - awt canvas using batik.</p><p>The PS Renderer uses a similar technique as the - PDF Renderer.</p><p>The SVG Renderer simply embeds the SVG inside an svg - element.</p></s2><s2 title="Associated Tasks"><ul><li>To get accurate drawing - pdf transparency is needed.</li><li>The drawRenderedImage methods need - implementing.</li><li>Handle colour space better.</li><li>Improve link handling - with pdf.</li><li>Improve image handling.</li></ul></s2></s1> +<document> + <header> + <title>SVG</title> + <subtitle>All you wanted to know about SVG and FOP !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> + <body><s1 title="SVG"> + <p>SVG is rendered through Batik.</p><p>The XML from the XSL:FO document + is converted into an SVG DOM with batik. This DOM is then set as the Document + on the Foreign Object area in the Area Tree.</p><p>This DOM is then available to + be rendered by the renderer.</p><p>SVG is rendered in the renderers via an + XMLHandler in the FOUserAgent. This XML handler is used to render the SVG. The + SVG is rendered by using batik. Batik converts the SVG DOM into an internal + structure that can be drawn into a Graphics2D. So for PDF we use a + PDFGraphics2D to draw into.</p><p>This creates the necessary PDF information to + create the SVG image in the PDF document.</p><p>Most of the work is done in the + PDFGraphics2D class. There are also a few bridges that are plugged into batik + to provide different behaviour for some SVG elements.</p><s2 + title="Text Drawing"><p>Normally batik converts text into a set of curved + shapes. </p><p>This is handled as any other shapes when rendering to the output. This + is not always desirable as the shapes have very fine curves. This can cause the + output to look a bit bad in PDF and PS (it can be drawn properly but is not by + default). These curves also require much more data than the original + text.</p><p>To handle this there is a PDFTextElementBridge that is set when + using the bridge in batik. If the text is simple enough for the text to be + drawn in the PDF as with all other text then this sets the TextPainter to use + the PDFTextPainter. This inserts the text directly into the PDF using the + drawString method on the PDFGraphics2D.</p><p>Text is considered simple if the + font is available, the font size is useable and there are no tspans or other + complications. This can make the resulting PDF significantly + smaller.</p></s2><s2 title="PDF Links"><p>To support links in PDF another batik + element bridge is used. The PDFAElementBridge creates a PDFANode which inserts + a link into the PDF document via the PDFGraphics2D.</p><p>Since links are + positioned on the page without any transforms then we need to transform the + coordinates of the link area so that they match the current position of the a + element area. This transform may also need to account for the svg being + positioned on the page.</p></s2><s2 title="Images"><p>Images are normally drawn + into the PDFGraphics2D. This then creates a bitmap of the image data that can + be inserted into the PDF document. </p><p>As PDF can support jpeg images then another + element bridge is used so that the jpeg can be directly inserted into the + PDF.</p></s2><s2 title="PDF Transcoder"><p>Batik provides a mechanism to + convert SVG into various formats. Through FOP we can convert an SVG document + into a single paged PDF document. The page contains the SVG drawn as best as + possible on the page. There is a PDFDocumentGraphics2D that creates a + standalone PDF document with a single page. This is then drawn into by batik in + the same way as with the PDFGraphics2D.</p></s2><s2 + title="Other Outputs"><p>When rendering to AWT the SVG is simply drawn onto the + awt canvas using batik.</p><p>The PS Renderer uses a similar technique as the + PDF Renderer.</p><p>The SVG Renderer simply embeds the SVG inside an svg + element.</p></s2><s2 title="Associated Tasks"><ul><li>To get accurate drawing + pdf transparency is needed.</li><li>The drawRenderedImage methods need + implementing.</li><li>Handle colour space better.</li><li>Improve link handling + with pdf.</li><li>Improve image handling.</li></ul></s2></s1> </body></document>
\ No newline at end of file diff --git a/docs/design/understanding/understanding.xml b/docs/design/understanding/understanding.xml index c34ec730b..b748ffca1 100644 --- a/docs/design/understanding/understanding.xml +++ b/docs/design/understanding/understanding.xml @@ -1,12 +1,12 @@ <?xml version="1.0"?> <!-- Overview --> -<document> - <header> - <title>Understanding FOP Design</title> - <subtitle>Tutorial series about Design Approach to FOP</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> +<document> + <header> + <title>Understanding FOP Design</title> + <subtitle>Tutorial series about Design Approach to FOP</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> <body> <s1 title="Understanding"> <note> @@ -35,31 +35,31 @@ complicated as we proceed. </p> </s2> - - - <s2 title="Overview"> + + + <s2 title="Overview"> <p>FOP takes an xml file does its magic and then writes a document to a - stream.</p> - <p>xml -> [FOP] -> document</p> + stream.</p> + <p>xml -> [FOP] -> document</p> <p>The document could be pdf, ps etc. or directed to a printer or the screen. The principle remains the same. The xml document must be in the XSL:FO - format.</p> + format.</p> <p>For convenience we provide a mechanism to handle XML+XSL as - input.</p> + input.</p> <p>The xml document is always handled internally as SAX. The SAX events are used to read the elements, attributes and text data of the FO document. After the manipulation of the data the renderer writes out the pages in the appropriate format. It may write as it goes, a page at a time or the whole document at once. Once finished the document should contain all the data in the - chosen format ready for whatever use.</p></s2> + chosen format ready for whatever use.</p></s2> <s2 title="Stages"><p>The fo data goes through a few stages. Each piece of data will generally go through the process in the same way but some information may be used a number of times or in a different order. To reduce - memory one stage will start before the previous is completed.</p> + memory one stage will start before the previous is completed.</p> <p>SAX Handler -> FO Tree -> Layout Managers -> Area Tree - -> Render -> document</p> + -> Render -> document</p> <p>In the case of rtf, mif etc. <br/>SAX Handler -> FO Tree -> - Structure Renderer -> document</p> + Structure Renderer -> document</p> <p>The FO Tree is constructed from the xml document. It is an internal representation of the xml document and it is like a DOM with some differences. The Layout Managers use the FO Tree do their layout stuff and create an Area @@ -69,26 +69,26 @@ convert the information into the render format. For example the PDF Renderer creates a PDF Document. For each page in the Area Tree the renderer creates a PDF Page and places the contents of the page into the PDF Page. Once a PDF Page - is complete then it can be written to the output stream.</p> + is complete then it can be written to the output stream.</p> <p>For the structure documents the Structure listener will read directly from the FO Tree and create the document. These documents do not need - the layout process or the Area Tree.</p></s2> + the layout process or the Area Tree.</p></s2> <s2 title="Associated Tasks"><p>Verify Structure Listener - concept.</p></s2> - <s2 title="Further Topics"> - <ul><li>XML parsing</li> - <li>FO Tree</li> - <li>Properties</li> - <li>Layout Managers</li> - <li>Layout Process</li> - <li>Handling Attributes</li> - <li>Area Tree</li> - <li>Renderers</li> - <li>Images</li> - <li>PDF Library</li> - <li>SVG</li> - </ul> - </s2> - + concept.</p></s2> + <s2 title="Further Topics"> + <ul><li>XML parsing</li> + <li>FO Tree</li> + <li>Properties</li> + <li>Layout Managers</li> + <li>Layout Process</li> + <li>Handling Attributes</li> + <li>Area Tree</li> + <li>Renderers</li> + <li>Images</li> + <li>PDF Library</li> + <li>SVG</li> + </ul> + </s2> + </s1> </body></document> diff --git a/docs/design/understanding/xml_parsing.xml b/docs/design/understanding/xml_parsing.xml index a7c8d4a85..f249cbce9 100644 --- a/docs/design/understanding/xml_parsing.xml +++ b/docs/design/understanding/xml_parsing.xml @@ -1,15 +1,15 @@ <?xml version="1.0"?> -<document> - <header> - <title>XML Parsing</title> - <subtitle>All you wanted to know about XML Parsing !</subtitle> - <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> - </authors> - </header> +<document> + <header> + <title>XML Parsing</title> + <subtitle>All you wanted to know about XML Parsing !</subtitle> + <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/> + </authors> + </header> <body> - + <s1 title="XML Parsing"><p>Since everyone knows the basics we can get - into the various stages starting with the XML handling.</p> + into the various stages starting with the XML handling.</p> <s2 title="XML Input"><p>FOP can take the input XML in a number of ways: </p> <ul> @@ -31,7 +31,7 @@ <code>Driver</code>. </li> </ul> - </li> + </li> <li> data source which is parsed and converted into SAX Events <ul> @@ -41,7 +41,7 @@ <code>Stream</code>, <code>String</code> etc. </li> </ul> - </li> + </li> <li> XML+XSLT which is transformed using an XSLT Processor and the result is fired as SAX Events @@ -56,10 +56,10 @@ </ul> </li> </ul> - + <p>The SAX Events which are fired on the SAX Handler, class <code>FOTreeBuilder</code>, must represent an XSL:FO document. If not there will be an - error. Any problems with the XML being well formed are handled here.</p></s2> + error. Any problems with the XML being well formed are handled here.</p></s2> <s2 title="Element Mappings"><p> The element mapping is a hashmap of all the elements in a particular namespace. This makes it easy to create a different object for each element. Element mappings are static to save on @@ -68,14 +68,14 @@ This must contain a line with the fully qualified name of a class that implements the <em>org.apache.fop.fo.ElementMapping</em> interface. This will then be loaded automatically at the start. Internal mappings are: FO, SVG and Extension - (pdf bookmarks)</p></s2> + (pdf bookmarks)</p></s2> <s2 title="Tree Building"><p>The SAX Events will fire all the information for the document with start element, end element, text data etc. This information is used to build up a representation of the FO document. To do this for a namespace there is a set of element mappings. When an element + namepsace mapping is found then it can create an object for that element. If the element is not found then it creates a dummy object or a generic DOM for unknown - namespaces.</p> + namespaces.</p> <p>The object is then setup and then given attributes for the element. For the FO Tree the attributes are converted into properties. The FO objects use a property list mapping to convert the attributes into a list of properties @@ -83,7 +83,7 @@ constructed. This DOM can then be passed through to the renderer. Other element mappings can be used in different ways, for example to create elements that create areas during the layout process or setup information for the renderer - etc.</p> + etc.</p> <p> While the tree building is mainly about creating the FO Tree there are some stages that can propagate to the renderer. At @@ -98,9 +98,9 @@ sequence. The page may not yet be complete, however, containing forward page number references, for example.) </p> - </s2> - <s2 title="Associated Tasks"> - <ul><li>Error handling for xml not well formed.</li> + </s2> + <s2 title="Associated Tasks"> + <ul><li>Error handling for xml not well formed.</li> <li>Error handling for other XML parsing errors.</li><li>Developer - info for adding namespace handlers.</li></ul></s2></s1> + info for adding namespace handlers.</li></ul></s2></s1> </body></document>
\ No newline at end of file |