[aXSL-commit] SF.net SVN: axsl: [477] trunk/axsl/doc/web/modules.html

[<vic...@us...>]

Revision: 477
Author:   victormote
Date:     2006-04-29 15:15:47 -0700 (Sat, 29 Apr 2006)
ViewCVS:  http://svn.sourceforge.net/axsl/?rev=477&view=rev

Log Message:
-----------
Clean up the module documentation.

Modified Paths:
--------------
    trunk/axsl/doc/web/modules.html
Modified: trunk/axsl/doc/web/modules.html
===================================================================
--- trunk/axsl/doc/web/modules.html	2006-04-29 21:28:50 UTC (rev 476)
+++ trunk/axsl/doc/web/modules.html	2006-04-29 22:15:47 UTC (rev 477)
@@ -51,12 +51,6 @@
     <td>None.</td>
   </tr>
   <tr>
-    <td>Logging library</td>
-    <td>lib</td>
-    <td>Pre-compiled jar for Apache Commons Logging.</td>
-    <td>None.</td>
-  </tr>
-  <tr>
     <td><a class="Menu" href="/common/">axslCommon</a></td>
     <td>axsl-common</td>
     <td>Common XSL-FO interfaces.</td>
@@ -85,10 +79,16 @@
     <td>axslCommon, axslPS.</td>
   </tr>
   <tr>
-    <td><a class="Menu" href="/pdf/">axslPDF</a></td>
+    <td><a class="Menu" href="/text/">axslText</a></td>
+    <td>axsl-text</td>
+    <td>Interfaces for hyphenation and line-breaking.</td>
+    <td>axslText.</td>
+  </tr>
+  <tr>
+    <td><a class="Menu" href="/pdf-out/">axslPDF</a></td>
     <td>axsl-pdf</td>
     <td>Interfaces for creating PDF files.</td>
-    <td>SVG Library.</td>
+    <td>SVG Library, axslGraphic, axslFont.</td>
   </tr>
   <tr class="Heading1">
     <td colspan="4">Document Processing Modules</td>
@@ -97,20 +97,13 @@
     <td><a class="Menu" href="/fotree/">axslFOTree</a></td>
     <td>axsl-fotree</td>
     <td>Interfaces for making XSL-FO content available.</td>
-    <td>axslCommon, axslGraphic, axslFont, axslText.</td>
+    <td>SVG Library, axslCommon, axslGraphic, axslFont, axslText.</td>
   </tr>
   <tr>
-    <td>axslAreaIn</td>
-    <td>axsl-area-in</td>
-    <td>Interfaces for creating an Area Tree, representing a formatted
-document.</td>
-    <td>Universals, axslGraphic, axslFont, axslText, axslFOTree.</td>
-  </tr>
-  <tr>
-    <td>axslAreaOut</td>
+    <td><a class="Menu" href="/area-out/">axslAreaOut</a></td>
     <td>axsl-area-out</td>
     <td>Interfaces for making Area Tree contents available to renderers.</td>
-    <td>Universals, axslGraphic, axslFont, axslText, axslFOTree.</td>
+    <td>SVG Library, axslCommon, axslGraphic, axslFont.</td>
   </tr>
 </table>
 
@@ -118,24 +111,22 @@
 <p>The following sections describe areas of possible additional standard
 modularity.</p>
 
-<h5><a name="text">Text</a></h5>
-<p>Text interfaces could include interfaces to line-breaking algorithms,
-glyph substitution routines, and possibly page-breaking algorithms. Again,
-this has potential usefulness for non-XSL-FO applications.</p>
-
-<h5><a name="hyphen">Hyphenation</a></h5>
-<p>This could be considered a subset of text processing.</p>
-
-<h5><a name="areatree">AreaTree</a></h5>
-<p>AreaTree may benefit from as many as three APIs because it seems at the
-moment anyway that there are at least two good ways of handling the Input side,
-one to bind the AreaTree to FOTree objects so that the AreaTree is really a
-<em>view</em> of the FOTree (AreaTree Bound Input), the other to have the AreaTree
-totally independent (AreaTree Free Input). The former is attractive because it
+<h5><a name="areatree">AreaTree "Input"</a></h5>
+<p>aXSL already has a module that models an Area Tree for purposes of output,
+i.e. the way a Renderer needs to see it.
+For purposes of <em>creating</em> an AreaTree, there may benefit in having two
+modules, as there seem to be at least two good ways of handling the data that
+an AreaTree modesl.
+The first possibility is to bind the AreaTree to FOTree objects so that the
+AreaTree is really a <em>view</em> of the FOTree (AreaTree Bound Input).
+The other possibility is to have the AreaTree totally independent (AreaTree
+Free Input).
+The former is attractive because it
 should use much less memory (approaching a savings of 50%), both in the
 AreaTree itself and in intermediate layout computations, and it seems cleaner.
 The latter is attractive because the AreaTree could be used independently of
-FO to work with other layout systems. It seems conceivable that an adapter could
+FO to work with non-XSL-FO layout systems.
+It seems conceivable that an adapter could
 be created that would take FO layout systems that were written to the AreaTree
 Bound Input API and convert them to the AreaTree Free Input API, so that layout
 systems could automatically work with AreaTrees using either Input API.</p>


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.