Re: [Understanding] FO Tree [3]
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 mailto:[EMAIL PROTECTED] Gleim Publications, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 mailto:[EMAIL PROTECTED] Gleim Publications, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Understanding] FO Tree [3]
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 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 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]
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]
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
[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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
