You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2002/02/14 09:58:33 UTC
[Understanding] FO Tree [3]
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.
(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.
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.
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.
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.
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
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.
Flow
----
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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
[Understanding] FO Tree
Posted by BRAHMA <br...@emis-intl.com>.
Hi Keiron,
Thank you very much for providing the FOP
knowledge.Unfortunately I missed some how "[Understanding] FO Tree [2]" can
you tell me where can I find it please.
thanks and regards
brahma
---------------------------------------------
Brahmaiah Kurabalakota
Software Developer
eMIS eMerging Information Systems GmbH
Am Friedrichsbrunnen
D-24782 B�delsdorf
Tel.: +49 (4331) 447 1520
Mobile: +49 (172) 5372297
mailto: brahmaiah.kurabalakota@emis-intl.com
www.emis-intl.com
Re: [Understanding] FO Tree [3]
Posted by Keiron Liddle <ke...@aftexsw.com>.
On 2002.02.23 16:33 Matthew L. Avizinis wrote:
> The question is, "How are extension element properties mapped?" I new
> element seems to be recognized by FOP just fine, but any properties I
> include are "ignored" by FOP, i.e. an exception is raised stating that
> the
> property in question is ignored and/or no maker found.
> matthew l. avizinis
In terms of what I am writing about, the extension element properties are
not mapped. The extension element classes get the xml attributes directly.
They can then get whatever attributes are required.
This is releveant information only to the development of FOP not older
versions.
You want to know how to map properties for older versions. For this you
need to do something like src/codegen/extproperties.xml and add the
appropriate processing into the build.xml.
> > Keiron Liddle wrote:
> > ...
> >
> > >>> 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?
> > >
> > >
> > > I'm not sure what the question is.
> > >
> > Keiron,
> >
> > The post below is from the fop-user list.
> >
> > Peter
> >
> > Hello all,
> > I have read the extension element writing document and examined the
> > <label> and <outline> extension elements code, but I don't see
> > precisely how
> > element properties are mapped. I have followed the pattern of
> > the examples
> > in the code and mapped the element correctly but the properties are
> > "ignored" when FOP runs.
> > Any help is appreciated. Please be as detailed as possible --
> > I am not a
> > veteran FOP developer, so what may be patently obvious to you might not
> be
> > to me.
> > Gratefully,
> > Matthew L. Avizinis <ma...@gleim.com>
> > Gleim Publications, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [Understanding] FO Tree [3]
Posted by "Matthew L. Avizinis" <ml...@gleim.com>.
The question is, "How are extension element properties mapped?" I new
element seems to be recognized by FOP just fine, but any properties I
include are "ignored" by FOP, i.e. an exception is raised stating that the
property in question is ignored and/or no maker found.
matthew l. avizinis
> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
> Sent: Friday, February 22, 2002 6:24 PM
> To: fop-dev@xml.apache.org
> Subject: Re: [Understanding] FO Tree [3]
>
>
> Keiron Liddle wrote:
> ...
>
> >>> 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?
> >
> >
> > I'm not sure what the question is.
> >
> Keiron,
>
> The post below is from the fop-user list.
>
> Peter
>
> Hello all,
> I have read the extension element writing document and examined the
> <label> and <outline> extension elements code, but I don't see
> precisely how
> element properties are mapped. I have followed the pattern of
> the examples
> in the code and mapped the element correctly but the properties are
> "ignored" when FOP runs.
> Any help is appreciated. Please be as detailed as possible --
> I am not a
> veteran FOP developer, so what may be patently obvious to you might not be
> to me.
> Gratefully,
> Matthew L. Avizinis <ma...@gleim.com>
> Gleim Publications, Inc.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [Understanding] FO Tree [3]
Posted by "Peter B. West" <pb...@powerup.com.au>.
Keiron Liddle wrote:
...
>>> 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?
>
>
> I'm not sure what the question is.
>
Keiron,
The post below is from the fop-user list.
Peter
Hello all,
I have read the extension element writing document and examined the
<label> and <outline> extension elements code, but I don't see precisely how
element properties are mapped. I have followed the pattern of the examples
in the code and mapped the element correctly but the properties are
"ignored" when FOP runs.
Any help is appreciated. Please be as detailed as possible -- I am not a
veteran FOP developer, so what may be patently obvious to you might not be
to me.
Gratefully,
Matthew L. Avizinis <ma...@gleim.com>
Gleim Publications, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [Understanding] FO Tree [3]
Posted by Keiron Liddle <ke...@aftexsw.com>.
On 2002.02.16 03:13 Peter B. West wrote:
> ** What other classes (if any) extend FONode? Where will they be
> discussed?
These classes will be displayed in the diagram. That should provide enough
information to tell people where to get more information, ie. in the
classes.
> ** Apart from end(), what methods are common to FObjs?
the handleAttributes and setUserAgent would be common to FONode. Other
than that I would say it is yet to be finalised.
> ** How is the FO Tree represented? How is it traversed?
The FO Tree is simple a heirarchy of java objects that represent the fo
elements from xml. The traversal is done by the layout or structure
process only in the flow elements.
> ** This is a big topic (Properties). Do you have plans to discuss it in
> more detail?
This is an entirely separate topic. It is mentioned here only in terms of
how it relates to the FO Tree.
>> 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?
I'm not sure what the question is.
> 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?
The objects in the FO Tree that represent these elements are themselves
the factory. The root element keeps these objects as a factory for the
page sequences.
> 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?
Yes the root looks after the declarations and the declarations maintains a
list of colour profiles.
> 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?
Why does this matter. This will be done by the class that looks after the
area tree whatever that is.
> 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?
This is for the "Layout Managers" topic.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [Understanding] FO Tree [3]
Posted by "Peter B. West" <pb...@powerup.com.au>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org