You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by ke...@apache.org on 2001/10/05 13:06:02 UTC
cvs commit: xml-fop/docs/design areas.xml build.sh layout.xml optimise.xml useragent.xml
keiron 01/10/05 04:06:02
Modified: docs/design areas.xml build.sh layout.xml optimise.xml
useragent.xml
Log:
more ideas on the design, areas
Revision Changes Path
1.3 +176 -0 xml-fop/docs/design/areas.xml
Index: areas.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/design/areas.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- areas.xml 2001/09/10 11:32:13 1.2
+++ areas.xml 2001/10/05 11:06:02 1.3
@@ -13,4 +13,180 @@
discarded once the layout is finalised.
</para>
+<section>
+ <title>The Area Tree</title>
+ <para>
+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 another class handle each page as it is added.
+ </para>
+</section>
+
+<section>
+ <title>Page</title>
+ <para>
+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.
+ </para>
+ <para>
+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.
+ </para>
+ <para>
+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 the layout of the body region
+is complete then the other regions can be done.
+ </para>
+</section>
+
+<section>
+ <title>Block Areas</title>
+ <para>
+Block areas are created and/or returned by all top level elements
+in the flow. These areas have keep and spacing information that
+needs to be retained until the page is finalised. A block area
+is stacked with other block areas in a particular direction, it
+has a size and it contains either line areas made from a group
+of inline areas or block areas.
+ </para>
+ <para>
+A block area can also be split into two block areas by splitting
+between two line areas or splitting between two block areas (or
+groups) that are stacked in the block progression direction of
+the page. The split may also be in a child block area.
+ </para>
+</section>
+
+<section>
+ <title>Line Areas</title>
+ <para>
+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
+width. It also contains information about floats and footnotes
+that are associated with the inline areas.
+ </para>
+ <para>
+A line area gets a set of inline areas added until complete then
+it is justified and vertically aligned. If the line area contains
+unresolved areas it will retain the justification information
+until all areas are resolved.
+ </para>
+</section>
+
+<section>
+ <title>Inline Areas</title>
+ <para>
+There are a few different types of inline areas. All inline areas
+have a height. Their width may be variable until the line is
+finalised.
+ </para>
+ <para>
+Unresolved areas can reserve some space to allow for possible
+sizes once it is resolved. Then the line can be re-justified
+and finalised.
+ </para>
+</section>
+
+<section>
+ <title>Cloning</title>
+ <para>
+Any subtree of the area tree should be cloneable so that for
+areas that are repeated the area tree can simply be copied rather
+than going through the layout again. This will only work if the
+width is the same.
+ </para>
+ <para>
+Resolveable areas may be converted into an unresolved form.
+ </para>
+</section>
+
+<section>
+ <title>Classes</title>
+ <para>
+The following class structure will be used to represent the area
+tree.
+ </para>
+ <para>
+
+ </para>
+<section>
+ <title>Page Area Classes</title>
+ <para>
+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.
+ </para>
+</section>
+<section>
+ <title>Block Area Classes</title>
+ <para>
+The block areas typically hold either a set of line areas or a set of
+block areas. The child areas are usually stacked in a particular
+direction.
+ </para>
+ <para>
+Areas for tables and lists have their child block areas stacked
+in different ways. Lists also can have spacing between the block
+areas.
+ </para>
+</section>
+<section>
+ <title>Inline Area Classes</title>
+ <para>
+The inline areas are used to make up a line area. An inline area
+typically has a height, width and some content. The alignment is
+used for block progression direction displacement and to determine
+the height of a line.
+ </para>
+</section>
+
+</section>
+
+<section>
+ <title>Rendering Area Tree</title>
+ <para>
+The rendering of an area tree is done by rendering each page
+to a suitable output. The regions are rendered in order and each
+region is contained by a viewport.
+ </para>
+ <para>
+The relevent structures that will need to be rendered are:
+Page
+Viewport
+Region
+Span
+Block
+Line
+Inline
+ </para>
+ <para>
+The renderer will need to be able to:
+ <itemizedlist>
+ <listitem><para>
+render each individual page
+ </para></listitem>
+ <listitem><para>
+clip and align child areas to a viewport
+ </para></listitem>
+ <listitem><para>
+handle all types of inline area, text, image etc.
+ </para></listitem>
+ <listitem><para>
+draw various lines and rectangles
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ <para>
+An abstract renderer will be able to handle the generic positioning
+of child areas, iterating through areas that have child areas.
+ </para>
+</section>
+
</section>
1.3 +2 -3 xml-fop/docs/design/build.sh
Index: build.sh
===================================================================
RCS file: /home/cvs/xml-fop/docs/design/build.sh,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.sh 2001/09/10 11:32:13 1.2
+++ build.sh 2001/10/05 11:06:02 1.3
@@ -1,18 +1,17 @@
#! /bin/sh
-# $Id: build.sh,v 1.2 2001/09/10 11:32:13 keiron Exp $
+# $Id: build.sh,v 1.3 2001/10/05 11:06:02 keiron Exp $
LIBDIR=../../lib
TARGET_CLASSPATH=$LIBDIR/ant.jar:\
$LIBDIR/buildtools.jar:\
$LIBDIR/xalan-2.0.0.jar:\
-$LIBDIR/xalan-1.2.2.jar:\
$LIBDIR/xerces-1.2.3.jar:\
$LIBDIR/bsf.jar:\
../../build/fop.jar:\
$LIBDIR/logkit-1.0b4.jar:\
$LIBDIR/avalon-framework-4.0.jar:\
$LIBDIR/batik.jar:\
-$LIBDIR/jimi-1.0.jar:
+$LIBDIR/jimi-1.0.jar
if [ "$JAVA_HOME" != "" ] ; then
TARGET_CLASSPATH=$TARGET_CLASSPATH:$JAVA_HOME/lib/tools.jar
1.2 +10 -0 xml-fop/docs/design/layout.xml
Index: layout.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/design/layout.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- layout.xml 2001/09/07 11:33:47 1.1
+++ layout.xml 2001/10/05 11:06:02 1.2
@@ -123,6 +123,16 @@
page properly.
</para>
<para>
+This should handle the situation where there are keeps on some
+block areas that go over the end of the page better. It is possible that
+fitting the blocks on the page using a spacing between min and optimum
+would give a closer value to the optimum than putting the blocks on the
+next page and the spacing being between optimum and max. So if the objects
+are placed first at optimum then you will need to keep going to see if
+there is a lower keep further on that has a spacing that is closer to the
+optimum.
+ </para>
+ <para>
The spacing and keep information is stored so that the area positions
and sizes can be adjusted.
</para>
1.3 +6 -0 xml-fop/docs/design/optimise.xml
Index: optimise.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/design/optimise.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- optimise.xml 2001/09/10 11:32:13 1.2
+++ optimise.xml 2001/10/05 11:06:02 1.3
@@ -33,5 +33,11 @@
can be combined into a "word" to hold the information with
limited overhead.
</para>
+ <para>
+If there are a large number of pages where forward references
+cannot be resolved the a method of writing a page onto disk
+could be used to save memory. The easiest way to achieve this
+is to make the page and all children serializable.
+ </para>
</section>
1.3 +6 -0 xml-fop/docs/design/useragent.xml
Index: useragent.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/design/useragent.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- useragent.xml 2001/09/10 11:32:13 1.2
+++ useragent.xml 2001/10/05 11:06:02 1.3
@@ -23,6 +23,12 @@
Standard Features:
<itemizedlist>
<listitem><para>
+error handling, what to do if fo markup is invalid
+ </para></listitem>
+ <listitem><para>
+auto overflow value and handling error-if-overflow
+ </para></listitem>
+ <listitem><para>
adjusting length values (eg. for borders) to renderable values
</para></listitem>
<listitem><para>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-cvs-help@xml.apache.org