Re: [Understanding] FO Tree [3]

[Keiron Liddle]

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
> >  and  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 
> > Gleim Publications, Inc.

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

RE: [Understanding] FO Tree [3]

[Matthew L. Avizinis]

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:[EMAIL PROTECTED]]
> Sent: Friday, February 22, 2002 6:24 PM
> To: [EMAIL PROTECTED]
> 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
>  and  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 <mailto:[EMAIL PROTECTED]>
> Gleim Publications, Inc.
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

Re: [Understanding] FO Tree [3]

[Peter B. West]

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
 and  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 
Gleim Publications, Inc.




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

Re: [Understanding] FO Tree [3]

[Keiron Liddle]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Understanding] FO Tree [3]

[Peter B. West]

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 re