FOP Implementation of Layout Formatting Objects

From eabf4ef87ee882557fb308388d27f1ca106792bc Mon Sep 17 00:00:00 2001 From: arved Date: Mon, 8 Jan 2001 02:37:24 +0000 Subject: [PATCH] New docs for discussion of refactoring of FOs git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@193954 13f79535-47bb-0310-9956-ffa450edef68 --- docs/design/fo_impl/fo_classes.xml | 368 +++++++++++++++++++++++++++++ docs/design/fo_impl/fo_classes.xsl | 100 ++++++++ 2 files changed, 468 insertions(+) create mode 100644 docs/design/fo_impl/fo_classes.xml create mode 100644 docs/design/fo_impl/fo_classes.xsl diff --git a/docs/design/fo_impl/fo_classes.xml b/docs/design/fo_impl/fo_classes.xml new file mode 100644 index 000000000..adcf04055 --- /dev/null +++ b/docs/design/fo_impl/fo_classes.xml @@ -0,0 +1,368 @@ + + + + + + + + + + + + + + + + + + + + + + + + + +]> + +FOP Implementation of Layout Formatting Objects + + +This table displays information concerning FOP implementation +of XSL formatting objects of the layout type. + + +The category classes refer to the XSL specification notation +%block; and %inline;. These +classifications are rather less useful in practical terms than +one might initially suppose. + + +The Base Class of each object is the FOP implementation +class. + + +The Spec Content is the BNF grammar describing +the content of each FO, as taken from the XSL specification. + + +The Breaks and Keeps describes what breaks and keeps apply +to each FO. All means all breaks and keeps, All Keeps +indicates that keep-together, keep-with-next, +and keep-with-previous all apply. The abbreviations +kt, kwn, and kwp specify +individual keep properties. + + +The information on generated areas describes what type of areas are +generated by a given FO, how many there are, whether or not +they are reference areas, and what FOP area class is being used for layout. +In some cases content is laid-out into the parent area; in others, the +content is laid-out in new areas that are constructed as required, then +added to the parent area - this is also noted in the table. In practise, +we should see that FOs that do not generate areas should layout into the +parent. + + +The Name, Spec Content, and Breaks & Keeps information is definite. +The type and multiplicity of generated areas is definite, as well as whether +the generated areas are reference areas or not. The BaseClass and the +layout area information is FOP-implementation dependent. + +Note: Numbers in parentheses refer to Notes. A * after +an FO name indicates that the object is not yet implemented. + + +

+ + +

+ + +not yet implemented; suggested base class +also widows & orphans +This is being generated in FOP, but an fo:table-body, or fo:table-header, +or fo:table-footer, generate no areas. +Should generate an area. + + + diff --git a/docs/design/fo_impl/fo_classes.xsl b/docs/design/fo_impl/fo_classes.xsl new file mode 100644 index 000000000..ad9e21690 --- /dev/null +++ b/docs/design/fo_impl/fo_classes.xsl @@ -0,0 +1,100 @@ + + + + + + + + + + + + + + +<xsl:value-of select="title"/> + + +

+ +

Block-Level Formatting Objects

+ +

Inline-Level Formatting Objects

+ +

Other Formatting Objects

+ + + + + + + + + + + +

+ + + + + + + + + + + + + + + + + +

Name	Base Class	Spec Content	Generated Areas	Breaks and Keeps

+ + + + + + + * + + + + + + + + + + + +

Class: + Stacking:
Multiplicity:
Layout into: + (parent)

Reference Area(s)

+ + + + + + +

Notes:

+ + + + -- 2.39.5