Keiron,

Some questions below.


Keiron Liddle wrote:

>
>
> FO Tree
> -------
>
> The FO Tree is a representation of the XSL:FO document. This represents
> the steps Objectify from the spec. The Refinement step is part of reading
> and using the properties which may happen immediately or during the 
> layout
> process.
>
> Each xml element is represented by a java object. For pagination the
> classes are in org.apache.fop.fo.pagination.*, for elements in the flow
> they are in org.apache.fop.fo.flow.* and some others are in
> org.apache.fop.fo.*.
>
> The base class for all objects in the tree is FONode. The base class for
> all FO Objects is FObj.

** What other classes (if any) extend FONode?  Where will they be 
discussed?

>
> (insert diagram here)
>
> There is a class for each element in the FO set. An object is created for
> each element in the FO Tree. This object holds the properties for the FO
> Object.
>
> When the object is created it is setup. It is given its element name, the
> FOUserAgent - for resolving properties etc., the logger and the
> attributes. The object will then be given any text data or child 
> elements.
> Then the end() method is called.
> The end method is used by a number of elements to indicate that it can do
> certain processing since all the children have been added.

** Apart from end(), what methods are common to FObjs?

>
> Some validity checking is done during these steps. The user can be 
> warned of the error and processing can continue if possible.
>
> The purpose of the FO Tree is to hold the information so that it can 
> be properly processed.

** How is the FO Tree represented?  How is it traversed?

>
> Properties
> ----------
>
> The XML attributes on each element are passed to the object. The objects
> that represent FO objects then convert the attributes into properties.
>
> Since properties can be inherited the PropertyList class handles 
> resolving
> properties for a particular element. 

** Is it a Property_List_ because it represents the set of properties 
specified as attributes on the FO element?  How are the PropertyLists 
structured in order to resolve the inheritance of individual properties 
within the list?

>
> All properties are specified in an XML file. Classes are created
> automatically during the build process.
>
> (insert diagram here)
>
> In some cases the element may be moved to have a different parent, for
> example markers, or the inheritance could be different, for example
> initial property set.

** This is a big topic.  Do you have plans to discuss it in more detail?

>
>
> Foreign XML
> -----------
>
> The base class for foreign XML is XMLObj. This class handles creating a
> DOM Element and the setting of attributes. It also can create a DOM
> Document if it is a top level element, class XMLElement.
> This class must be extended for the namespace of the XML elements. For
> unknown namespaces the class is UnknowXMLObj.
>
> (insert diagram here)
>
> If some special processing is needed then the top level element can 
> extend
> the XMLObj. For example the SVGElement makes the special DOM required for
> batik and gets the size of the svg.
>
> Foreign XML will usually be in an fo:instream-foreign-object, the XML 
> will
> be passed to the render as a DOM where the render will be able to handle
> it. Other XML from an unknwon namespace will be ignored.
>
> By using element mappings it is possible to read other XML and either
> - set information on the area tree
> - create pseudo FO Objects that create areas in the area tree
> - create FO Objects

** Mapping elements to classes?

>
>
> Unknown Elements
> ----------------
>
> If an element is in a known namespace but the element is unknown then an
> Unknown object is created. This is mainly to provide information to the
> user.
> This could happen if the fo document contains an element from a different
> version or the element is misspelt.
>
> Page Masters
> ------------
>
> The first elements in a document are the elements for the page master
> setup. This is usually only a small number and will be used throughout 
> the
> document to create new pages.
> These elements are kept as a factory to create the page and appropriate
> regions whenever a new page is requested by the layout.

fo:layout-master-set is a wrapper around all of the page *masters*.  As 
noted, all of the page master setup occurs at the beginning of the 
document, so the layout-master-set is the first element under fo:root. 
 At the bottom of the hierarchy are the fo:simple-page-masters, each 
defining the division of one type of page into regions; basically the 
body and the four possible edge regions surrounding it.  This 
"regionalisation" of a page is the "layout" implied by 
"layout-master-set."  The layout of every page is eventually defined by 
a simple-page-master.  They can be accessed directly by name, or 
indirectly by the name of a page-sequence-master.  If specified directly 
by name, a simple-page-master represents an unbounded sequence of pages 
with the same layout.

Named fo:page-sequence-masters exist so that a sequence of pages with 
different layouts can be specified.  The elements of a 
page-sequence-master are an ordered set of sub-sequences into which the 
intended sequence, represented by this page-sequence-master, is divided. 
 This sequence can include, in any order, sub-sequences comprised of
a) a single named simple-page-master (fo:single-page-master-reference)
b) a repeating sequence of one named simple-page-master, from zero to 
maximum-repeats (fo:repeatable-page-master-reference)
c) a repeating sequence of simple-page-masters, from zero to 
maximum-repeats, in which each simple-page-master is selected from an 
ordered set of alternatives (fo:repeatable-page-master-alternatives). 
 The list of alternatives is comprised of 
fo:conditional-page-master-references, each of which names a 
simple-page-master and includes a set of conditions under which that 
simple-page-master is selected.

The layout-master-set is specified in a subtree isolated from the 
content specification of the pages (see page sequences, below).

** Where are references to these factories maintained?

Declarations
------------

 From the spec (6.4.3)

The fo:declarations formatting object is used to group global 
declarations for a stylesheet.

Only fo:color-profile is defined within fo:declarations.

** "...handled by ... parent element."  fo:root?

Page Sequences
--------------

The page masters define the layout of the page containers into which the 
substance of the document will be poured.  This substance is defined in 
fo:page-sequences.  They contain an optional fo:title, zero or more 
fo:static-content elements, and a single fo:flow.  They are children of 
fo:root, and are encountered in the document tree after the 
fo:layout-master-set has been read.

** The fo:page-sequence elements determine the layout-master that will 
be used for layout of their children.  How is the association between 
page master, page-sequence (FO Tree) and area tree maintained?

>
> Flow

> ----

Flows
-----

Flows provide the content which is poured into page containers, 
specifically the regions.  fo:static-flows are content, associated with 
a particular region, which repeats on each page containing such a 
region; i.e. it does *not* flow over a page boundary.  fo:flows are the 
primary content of a page-sequence.  They overflow individual page 
containers (region-body containers, practically speaking) to continue in 
the same region of the next page.

** Which classes/methods determine how the elements of a flow are 
processed and converted into areas in the area tree?

>
>
> The elements that are in the flow of the document are a set of elements
> that is needed for the layout process. Each element is important in the
> creation of areas



>
> Other Elements
> --------------
>
> The remaing FO Objects are things like page-sequence, title and
> color-profile. These are handled by their parent element.
>
> Associated Tasks
> ----------------
>
> Create diagrams
> Setup all properties and elements for XSL:FO
> Setup user agent for property resolution
> Verify all XML is handled appropriately


Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to