Tree transformation constructs the result tree. In XSL, this tree is called the element and attribute tree, with objects primarily in the "formatting object" namespace. In this tree, a formatting object is represented as an XML element, with the properties represented by a set of XML attribute-value pairs. The content of the formatting object is the content of the XML element. Tree transformation is defined in the XSLT Recommendation . A diagram depicting this conceptual process is shown below.

The XSL stylesheet is used in tree transformation. A stylesheet contains a set of tree construction rules. The tree construction rules have two parts: a pattern that is matched against elements in the source tree and a template that constructs a portion of the result tree. This allows a stylesheet to be applicable to a wide class of documents that have similar source tree structures.

In some implementations of XSL/XSLT, the result of tree construction can be output as an XML document. This would allow an XML document which contains formatting objects and formatting properties to be output. This capability is neither necessary for an XSL processor nor is it encouraged. There are, however, cases where this is important, such as a server preparing input for a known client; for example, the way that a WAP (http://www.wapforum.org/faqs/index.htm) server prepares specialized input for a WAP capable hand held device. To preserve accessibility, designers of Web systems should not develop architectures that require (or use) the transmission of documents containing formatting objects and properties unless either the transmitter knows that the client can accept formatting objects and properties or the transmitted document contains a reference to the source document(s) used in the construction of the document with the formatting objects and properties.

Formatting interprets the result tree in its formatting object tree form to produce the presentation intended by the designer of the stylesheet from which the XML element and attribute tree in the "fo" namespace was constructed.

The vocabulary of formatting objects supported by XSL - the set of fo: element types - represents the set of typographic abstractions available to the designer. Semantically, each formatting object represents a specification for a part of the pagination, layout, and styling information that will be applied to the content of that formatting object as a result of formatting the whole result tree. Each formatting object class represents a particular kind of formatting behavior. For example, the block formatting object class represents the breaking of the content of a paragraph into lines. Other parts of the specification may come from other formatting objects; for example, the formatting of a paragraph (block formatting object) depends on both the specification of properties on the block formatting object and the specification of the layout structure into which the block is placed by the formatter.

The properties associated with an instance of a formatting object control the formatting of that object. Some of the properties, for example "color", directly specify the formatted result. Other properties, for example 'space-before', only constrain the set of possible formatted results without specifying any particular formatted result. The formatter may make choices among other possible considerations such as esthetics.

Formatting consists of the generation of a tree of geometric areas, called the area tree. The geometric areas are positioned on a sequence of one or more pages (a browser typically uses a single page). Each geometric area has a position on the page, a specification of what to display in that area and may have a background, padding, and borders. For example, formatting a single character generates an area sufficiently large enough to hold the glyph that is used to present the character visually and the glyph is what is displayed in this area. These areas may be nested. For example, the glyph may be positioned within a line, within a block, within a page.

Rendering takes the area tree, the abstract model of the presentation (in terms of pages and their collections of areas), and causes a presentation to appear on the relevant medium, such as a browser window on a computer display screen or sheets of paper. The semantics of rendering are not described in detail in this specification.

The first step in formatting is to "objectify" the element and attribute tree obtained via an XSLT transformation. Objectifying the tree basically consists of turning the elements in the tree into formatting object nodes and the attributes into property specifications. The result of this step is the formatting object tree.

As part of the step of objectifying, the characters that occur in the result tree are replaced by fo:character nodes. Characters in text nodes which consist solely of white space characters and which are children of elements whose corresponding formatting objects do not permit fo:character nodes as children are ignored. Other characters within elements whose corresponding formatting objects do not permit fo:character nodes as children are errors.

The content of the fo:instream-foreign-object is not objectified; instead the object representing the fo:instream-foreign-object element points to the appropriate node in the element and attribute tree. Similarly any non-XSL namespace child element of fo:declarations is not objectified; instead the object representing the fo:declarations element points to the appropriate node in the element and attribute tree.

The second phase in formatting is to refine the formatting object tree to produce the refined formatting object tree. The refinement process handles the mapping from properties to traits. This consists of: (1) shorthand expansion into individual properties, (2) mapping of corresponding properties, (3) determining computed values (may include expression evaluation), (4) handling white-space-treatment and linefeed-treatment property effects, and (5) inheritance. Details on refinement are found in .

The refinement step is depicted in the diagram below.

The third step in formatting is the construction of the area tree. The area tree is generated as described in the semantics of each formatting object. The traits applicable to each formatting object class control how the areas are generated. Although every formatting property may be specified on every formatting object, for each formatting object class, only a subset of the formatting properties are used to determine the traits for objects of that class.

Area generation is depicted in the diagram below.

Doing both scrollable document windows and pagination introduces new complexities to the styling (and pagination) of XML content. Because pagination introduces arbitrary boundaries (pages or regions on pages) on the content, concepts such as the control of spacing at page, region, and block boundaries become extremely important. There are also concepts related to adjusting the spaces between lines (to adjust the page vertically) and between words and letters (to justify the lines of text). These do not always arise with simple scrollable document windows, such as those found in today's browsers. However, there is a correspondence between a page with multiple regions, such as a body, header, footer, and left and right sidebars, and a Web presentation using "frames". The distribution of content into the regions is basically the same in both cases, and XSL handles both cases in an analogous fashion.

XSL was developed to give designers control over the features needed when documents are paginated as well as to provide an equivalent "frame" based structure for browsing on the Web. To achieve this control, XSL has extended the set of formatting objects and formatting properties. In addition, the selection of XML source components that can be styled (elements, attributes, text nodes, comments, and processing instructions) is based on XSLT and XPath , thus providing the user with an extremely powerful selection mechanism.

The design of the formatting objects and properties extensions was first inspired by DSSSL. The actual extensions, however, do not always look like the DSSSL constructs on which they were based. To either conform more closely with the CSS2 specification or to handle cases more simply than in DSSSL, some extensions have diverged from DSSSL.

There are several ways in which extensions were made. In some cases, it sufficed to add new values, as in the case of those added to reflect a variety of writing-modes, such as top-to-bottom and bottom-to-top, rather than just left-to-right and right-to-left.

In other cases, common properties that are expressed in CSS2 as one property with multiple simultaneous values, are split into several new properties to provide independent control over independent aspects of the property. For example, the "white-space" property was split into four properties: a "white-space-treatment" property that controls how white space is processed, a "linefeed-treatment" property that controls how line feeds are processed, a "white-space-collapse" property that controls how multiple consecutive spaces are collapsed, and a "wrap-option" property that controls whether lines are automatically wrapped when they encounter a boundary, such as the edge of a column. The effect of splitting a property into two or more (sub-)properties is to make the equivalent existing CSS2 property a "shorthand" for the set of sub-properties it subsumes.

In still other cases, it was necessary to create new properties. For example, there are a number of new properties that control how hyphenation is done. These include identifying the script and country the text is from as well as such properties as "hyphenation-character" (which varies from script to script).

Some of the formatting objects and many of the properties in XSL come from the CSS2 specification, ensuring compatibility between the two.

There are four classes of XSL properties that can be identified as:

As mentioned above, XSL uses XSLT and XPath for tree construction and pattern selection, thus providing a high degree of control over how portions of the source content are presented, and what properties are associated with those content portions, even where mixed namespaces are involved.

For example, the patterns of XPath allow the selection of a portion of a string or the Nth text node in a paragraph. This allows users to have a rule that makes all third paragraphs in procedural steps appear in bold, for instance. In addition, properties can be associated with a content portion based on the numeric value of that content portion or attributes on the containing element. This allows one to have a style rule that makes negative values appear in "red" and positive values appear in "black". Also, text can be generated depending on a particular context in the source tree, or portions of the source tree may be presented multiple times with different styles.

There is a set of formatting objects in XSL to describe both the layout structure of a page or "frame" (how big is the body; are there multiple columns; are there headers, footers, or sidebars; how big are these) and the rules by which the XML source content is placed into these "containers".

The layout structure is defined in terms of one or more instances of a "simple-page-master" formatting object. This formatting object allows one to define independently filled regions for the body (with multiple columns), a header, a footer, and sidebars on a page. These simple-page-masters can be used in page sequences that specify in which order the various simple-page-masters shall be used. The page sequence also specifies how styled content is to fill those pages. This model allows one to specify a sequence of simple-page-masters for a book chapter where the page instances are automatically generated by the formatter or an explicit sequence of pages such as used in a magazine layout. Styled content is assigned to the various regions on a page by associating the name of the region with names attached to styled content in the result tree.

In addition to these layout formatting objects and properties, there are properties designed to provide the level of control over formatting that is typical of paginated documents. This includes control over hyphenation, and expanding the control over text that is kept with other text in the same line, column, or on the same page.

The extension of the properties and formatting objects, particularly in the area on control over the spacing of blocks, lines, and page regions and within lines, necessitated an extension of the CSS2 box formatting model. This extended model is described in of this specification. The CSS2 box model is a subset of this model. See the mapping of the CSS2 box model terminology to the XSL Area Model terminology in . The area model provides a vocabulary for describing the relationships and space-adjustment between letters, words, lines, and blocks.

There are some scripts, in particular in the Far East, that are typically set with words proceeding from top-to-bottom and lines proceeding either from right-to-left (most common) or from left-to-right. Other directions are also used. Properties expressed in terms of a fixed, absolute frame of reference (using top, bottom, left, and right) and which apply only to a notion of words proceeding from left to right or right to left do not generalize well to text written in those scripts.

For this reason XSL (and before it DSSSL) uses a relative frame of reference for the formatting object and property descriptions. Just as the CSS2 frame of reference has four directions (top, bottom, left and right), so does the XSL relative frame of reference have four directions (before, after, start, and end), but these are relative to the "writing-mode". The "writing-mode" property is a way of controlling the directions needed by a formatter to correctly place glyphs, words, lines, blocks, etc. on the page or screen. The "writing-mode" expresses the basic directions noted above. There are writing-modes for "left-to-right - top-to-bottom" (denoted as "lr-tb"), "right-to-left - top-to-bottom" (denoted as "rl-tb"), "top-to-bottom - right-to-left" (denoted as "tb-rl") and more. See for the description of the "writing-mode" property. Typically, the writing-mode value specifies two directions: the first is the inline-progression-direction which determines the direction in which words will be placed and the second is the block-progression-direction which determines the direction in which blocks (and lines) are placed one after another. In addition, the inline-progression-direction for a sequence of characters may be implicitly determined using bidirectional character types for those characters from the Unicode Character Database for those characters and the Unicode bidirectional (BIDI) algorithm .

Besides the directions that are explicit in the name of the value of the "writing-mode" property, the writing-mode determines other directions needed by the formatter, such as the shift-direction (used for subscripts and superscripts), etc.

Because XML, unlike HTML, has no built-in semantics, there is no built-in notion of a hypertext link. In this context, "link" refers to "hypertext link" as defined in http://www.w3.org/TR/html401/struct/links.html#h-12.1 as well as some of the aspects of "link" as defined in http://www.w3.org/TR/xlink/#intro, where "link is a relationship between two or more resources or portions of resources, made explicit by an XLink linking element". Therefore, XSL has a formatting object that expresses the dual semantics of formatting the content of the link reference and the semantics of following the link.

XSL provides a few mechanisms for changing the presentation of a link target that is being visited. One of these mechanisms permits indicating the link target as such; another allows for control over the placement of the link target in the viewing area; still another permits some degree of control over the way the link target is displayed in relationship to the originating link anchor.

XSL also provides a general mechanism for changing the way elements are formatted depending on their active state. This is particularly useful in relation to links, to indicate whether a given link reference has already been visited, or to apply a given style depending on whether the mouse, for instance, is hovering over the link reference or not.

There are two types of areas: block-areas and inline-areas. These differ according to how they are typically stacked by the formatter. An area can have block-area children or inline-area children as determined by the generating formatting object, but a given area's children must all be of one type. Although block-areas and inline-areas are typically stacked, some areas can be explicitly positioned.

A line-area is a special kind of block-area whose children are all inline-areas. A glyph-area is a special kind of inline-area which has no child areas, and has a single glyph image as its content.

Typical examples of areas are: a paragraph rendered by using an fo:block formatting object, which generates block-areas, and a character rendered by using an fo:character formatting object, which generates an inline-area (in fact, a glyph-area).

Associated with any area are two directions, which are derived from the generating formatting object's writing-mode and reference-orientation properties: the block-progression-direction is the direction for stacking block-area descendants of the area, and the inline-progression-direction is the direction for stacking inline-area descendants of the area. Another trait, the shift-direction, is present on inline-areas and refers to the direction in which baseline shifts are applied. Also the glyph-orientation defines the orientation of glyph-images in the rendered result.

If the reference-orientation for an area is 0, then the top, bottom, left, and right edges of the content are parallel to those of the area's parent and consistent with them. Otherwise the edges are rotated from those of the area's parent as described in . The inline-progression-direction and block-progression-direction are determined by the location of these edges as described in .

The Boolean trait is-reference-area determines whether or not an area establishes a coordinate system for specifying indents. An area for which this trait is true is called a reference-area. Only a reference-area may have a block-progression-direction which is different from that of its parent. A reference-area may be either a block-area or an inline-area.

The Boolean trait is-viewport-area determines whether or not an area establishes an opening through which its descendant areas can be viewed, and can be used to present clipped or scrolled material; for example, in printing applications where bleed and trim is desired. An area for which this trait is true is called a viewport-area.

A common construct is a viewport/reference pair. This is a viewport-area V and a block-area reference-area R, where R is the sole child of V and where the start-edge and end-edge of the content-rectangle of R are parallel to the start-edge and end-edge of the content-rectangle of V.

Each area has the traits top-position, bottom-position, left-position, and right-position which represent the distance from the edges of its content-rectangle to the like-named edges of the nearest ancestor reference-area (or the page-viewport-area in the case of areas generated by descendants of formatting objects whose absolute-position is fixed); the left-offset and top-offset determine the amount by which a relatively-positioned area is shifted for rendering. These traits receive their values during the formatting process, or in the case of absolutely positioned areas, during refinement.

The block-progression-dimension and inline-progression-dimension of an area represent the extent of the content-rectangle of that area in each of the two relative dimensions.

Other traits include:

Unless otherwise specified, the traits of a formatting object are present on each of its generated areas, and with the same value. (However, see sections and .)

As described above, the content-rectangle is the rectangle bounding the inside of the padding and is used to describe the constraints on the positions of descendant areas. It is possible that marks from descendant glyphs or other areas may appear outside the content-rectangle.

Related to this is the allocation-rectangle of an area, which is used to describe the constraints on the position of the area within its parent area. For an inline-area this is either the normal-allocation-rectangle or the large-allocation-rectangle. The normal-allocation-rectangle extends to the content-rectangle in the block-progression-direction and to the border-rectangle in the inline-progression-direction. The large-allocation-rectangle is the border-rectangle. Unless otherwise specified, the allocation-rectangle for an area is the normal-allocation-rectangle.

For a block-area, the allocation-rectangle extends to the border-rectangle in the block-progression-direction and outside the content-rectangle in the inline-progression-direction by an amount equal to the end-indent, and in the opposite direction by an amount equal to the start-indent.

The edges of a rectangle are designated as follows:

For purposes of this definition, the content-rectangle of an area uses the inline-progression-direction and block-progression-direction of that area; but the border-rectangle, padding-rectangle, and allocation-rectangle use the directions of its parent area. Thus the edges designated for the content-rectangle may not correspond to the same-named edges on the padding-, border-, and allocation-rectangles. This is important in the case of nested block-areas with different writing-modes.

The following diagram shows the correspondence between the various edge names for a mixed writing-mode example:

In the area tree, the set of areas with a given parent is ordered. The terms initial, final, preceding, and following refer to this ordering.

In any ordered tree, this sibling order extends to an ordering of the entire tree in at least two ways.

"Preceding" and "following", when applied to non-siblings, will depend on the extension order used, which must be specified. However, in either of these given orders, the leaves of the tree (nodes without children) are unambiguously ordered.

This section defines the notion of block-stacking constraints and inline-stacking constraints involving areas. These are defined as ordered relations, i.e., if A and B have a stacking constraint it does not necessarily mean that B and A have a stacking constraint. These definitions are recursive in nature and some cases may depend upon simpler cases of the same definition. This is not circularity but rather a consequence of recursion. The intention of the definitions is to identify areas at any level of the tree which have only space between them.

The area-class trait is an enumerated value which is xsl-normal for an area which is stacked with other areas in sequence. A normal area is an area for which this trait is xsl-normal. A page-level-out-of-line area is an area with area-class xsl-footnote, xsl-before-float, or xsl-fixed; placement of these areas is controlled by the fo:page-sequence ancestor of its generating formatting object. A reference-level-out-of-line area is an area with area-class xsl-side-float or xsl-absolute; placement of these areas is controlled by the formatting object generating the relevant reference-area. An anchor area is an area with area-class xsl-anchor; placement of these areas is arbitrary and does not affect stacking. Areas with area-class equal to one of xsl-normal, xsl-footnote, or xsl-before-float are defined to be stackable, indicating that they are supposed to be properly stacked.

Block-stacking constraints

If P is a block-area, then there is a fence preceding P if P is a reference-area or if the border-before-width or padding-before-width of P are non-zero. Similarly, there is a fence following P if P is a reference-area or if the border-after-width or padding-after-width of P are non-zero.

If A and B are stackable areas, and S is a sequence of space-specifiers (see ), it is defined that A and B have block-stacking constraint S if any of the following conditions holds:

When A and B have a block-stacking constraint, the adjacent edges of A and B are an ordered pair recursively defined as:

Example. In this diagram each node represents a block-area. Assume that all padding and border widths are zero, and none of the areas are reference-areas. Then P and A have a block-stacking constraint, as do A and B, A and C, B and C, C and D, D and B, B and E, D and E, and E and P; these are the only pairs in the diagram having block-stacking constraints. If B had non-zero padding-after, then D and E would not have any block-stacking constraint (though B and E would continue to have a block-stacking constraint).

Inline-stacking constraints.

This section will recursively define the inline-stacking constraints between two areas (either two inline-areas or one inline-area and one line-area), together with the notion of fence preceding and fence following; these definitions are interwoven with one another. This parallels the definition for block-stacking constraints, but with the additional complication that we may have a stacking constraint between inline-areas which are stacked in opposite inline-progression-directions. (This is not an issue for block-stacking constraints because a block-area which is not a reference-area may not have a block-progression-direction different from that of its parent.)

If P and Q have an inline-stacking constraint, then P has a fence preceding Q if P is a reference-area or has non-zero border-width or padding-width at the first adjacent edge of P and Q. Similarly, Q has a fence following P if Q is a reference-area or has non-zero border-width or padding-width at the second adjacent edge of P and Q.

If A and B are normal areas, and S is a sequence of space-specifiers, it is defined that A and B have inline-stacking constraint S if any of the following conditions holds:

When A and B have an inline-stacking constraint, the adjacent edges of A and B are an ordered pair defined as:

Two areas are adjacent if they have a block-stacking constraint or an inline-stacking constraint. It follows from the definitions that areas of the same type (inline or block) can be adjacent only if all their non-common ancestors are also of the same type (up to but not including their nearest common ancestor). Thus, for example, two inline-areas which reside in different line-areas are never adjacent.

An area A begins an area P if A is a descendant of P and P and A have either a block-stacking constraint or an inline-stacking constraint. In this case the second of the adjacent edges of P and A is defined to be a leading edge in P. A space-specifier which applies to the leading edge is also defined to begin P.

Similarly, An area A ends an area P if A is a descendant of P and A and P have either a block-stacking constraint or an inline-stacking constraint. In this case the first of the adjacent edges of A and P is defined to be a trailing edge in P. A space-specifier which applies to the trailing edge is also defined to end P.

Each script has its preferred "baseline" for aligning glyphs from that script. Western scripts typically use an "alphabetic" baseline that touches at or near the bottom of capital letters. Further, for each font there is a preferred way of aligning embedded glyphs from different scripts, e.g., for a Western font there are separate baselines for aligning embedded ideographic or Indic glyphs.

Each block-area and inline-area has a dominant-baseline-identifier trait whose value is a baseline identifier corresponding to the type of alignment expected for inline-area descendants of that area, and each inline-area has an alignment-baseline which specifies how the area is aligned to its parent. These traits are interpreted as described in section .

For each font, an actual-baseline-table maps these identifiers to points on the start-edge of the area. By abuse of terminology, the line in the inline-progression-direction through the point corresponding to the dominant-baseline-identifier is called the "dominant baseline."

The resolved space-specifier of a given space-specifier S is computed as follows. Consider the maximal inline-stacking constraint or block-stacking constraint S'' containing the space-specifier S as an element of the sequence (S'' is a sequence of space-specifiers; see ). Define S' to be a subsequence of S'' as follows:

The resolved space-specifier of S is a non-conditional, forcing space-specifier computed in terms of the sequence S'.

Example. Suppose the sequence of space values occurring at the beginning of a reference-area is: first, a space with value 10 points (that is minimum, optimum, and maximum all equal to 10 points) and conditionality discard; second, a space with value 4 points and conditionality retain; and third, a space with value 5 points and conditionality discard; all three spaces having precedence zero. Then the first (10 point) space is suppressed under rule 1, and the second (4 point) space is suppressed under rule 3. The resolved value of the third space is a non-conditional 5 points, even though it originally came from a conditional space.

The padding of a block-area does not interact with any space-specifier (except that by definition, the presence of padding at the before- or after-edge prevents areas on either side of it from having a stacking constraint.)

The border or padding at the before-edge or after-edge of a block-area B may be specified as conditional. If so, then it is set to zero if its associated edge is a leading edge in a reference-area, and the is-first trait of B is false, or if its associated edge is a trailing edge in a reference-area, and the is-last trait of B is false. In either of these cases, the border or padding is taken to be zero for purposes of the stacking constraint definitions.

The border or padding at the start-edge or end-edge of an inline-area I may be specified as conditional. If so, then it is set to zero if its associated edge is a leading edge in a line-area, and the is-first trait of I is false, or if its associated edge is a trailing edge in a line-area, and the is-last trait of I is false. In either of these cases, the border or padding is taken to be zero for purposes of the stacking constraint definitions.

When an area P is generated by a formatting object whose block-progression-dimension is "auto", then the constraints involving the before-edge and after-edge of the content-rectangle of P, together with the constraints between the various descendants of P, result in a constraint on the actual value of the block-progression-dimension. If the block-progression-dimension is instead specified as a length, then this might result in an overconstrained area tree, for example an incompletely-filled fo:block with a specified size. In that case some constraints between P and its descendants should be relaxed; those that are eligible for this treatment are said to be subject to overconstrainment relaxing, and treated as in the previous section.

Block-area children of an area are typically stacked in the block-progression-direction within their parent area, and this is the default method of positioning block-areas. However, formatting objects are free to specify other methods of positioning child areas of areas which they generate, for example list-items or tables.

For a parent area P whose children are block-areas, P is defined to be properly stacked if all of the following conditions hold:

Intrusion adjustments (both start- and end-) are defined to account for the indentation that occurs as the result of side floats.

If A and B are areas which have the same nearest reference area ancestor, then A and B are defined to be inline-overlapping if there is some line parallel to the inline-progression-direction, which intersects both the allocation-rectangle of A and the allocation-rectangle of B.

If A is an area of class xsl-side-float with float="start", and B is a block-area, and A and B have the same nearest reference area ancestor, then A is defined to encroach upon B if A and B are inline-overlapping and the start-indent of B is less than the sum of the start-indent of A and the inline-progression-dimension of A. The start-encroachment of A on B is then defined to be amount by which the start-indent of B is less than the sum of the start-indent of A and the inline-progression-dimension of A.

If A is an area of class xsl-side-float with float="end", and B is a block-area, and A and B have the same nearest reference area ancestor, then A is defined to encroach upon B if A and B are inline-overlapping and the end-indent of B is less than the sum of the end-indent of A and the inline-progression-dimension of A. The end-encroachment of A on B is then defined to be amount by which the end-indent of B is less than the sum of the end-indent of A and the inline-progression-dimension of A.

If B is a block-area which is not a line-area, then its local-start-intrusion-adjustment is computed as the maximum of the following lengths:

The start-intrusion-adjustment of a block-area B is then defined to be the maximum of the local-start-intrusion-adjustments of the normal block-areas generated and returned by the generating formatting object of B.

If L is a line-area, then its start-intrusion-adjustment is computed as the maximum of the following lengths:

The end-intrusion-adjustment for a block-area is computed in a precisely analogous manner. That is:

If B is a block-area which is not a line-area, then its local-end-intrusion-adjustment is computed as the maximum of the following lengths:

The end-intrusion-adjustment of a block-area B is then defined to be the maximum of the local-end-intrusion-adjustments of the normal block-areas generated and returned by the generating formatting object of B.

If L is a line-area, then its end-intrusion-adjustment is computed as the maximum of the following lengths:

Inline-area children of an area are typically stacked in the inline-progression-direction within their parent area, and this is the default method of positioning inline-areas.

Inline-areas are stacked relative to the dominant baseline, as defined above ().

For a parent area P whose children are inline-areas, P is defined to be properly stacked if all of the following conditions hold:

The most common inline-area is a glyph-area, which contains the representation for a character (or characters) in a particular font.

A glyph-area has an associated nominal-font, determined by the area's typographic traits, which apply to its character data, and a glyph-orientation determined by its writing-mode and reference-orientation, which determine the orientation of the glyph when it is rendered.

The alignment-point and dominant-baseline-identifier of a glyph-area are assigned according to the writing-system in use (e.g., the glyph baseline in Western languages), and are used to control placement of inline-areas descendants of a line-area. The formatter may generate inline-areas with different inline-progression-directions from their parent to accommodate correct inline-area stacking in the case of mixed writing systems.

A glyph-area has no children. Its block-progression-dimension and actual-baseline-table are the same for all glyphs in a font. Conforming implementations may choose to compute the block-progression-dimension for a glyph area based on the actual glyph size rather than using a common size for all glyphs in a font.

A subset S of the areas returned to a formatting object is called properly ordered if the areas in that subset have the same order as their generating formatting objects. Specifically, if A₁ and A₂ are areas in S, returned by child formatting objects F₁ and F₂ where F₁ precedes F₂, then A₁ must precede A₂ in the pre-order traversal order of the area tree. If F₁ equals F₂ and A₁ is returned prior to A₂, then A₁ must precede A₂ in the pre-order-traversal of the area tree.

For each formatting object F and each area-class C, the subset consisting of the areas returned to F with area-class C must be properly ordered, except where otherwise specified.

This section describes the ordering constraints that apply to formatting an fo:block or similar block-level object.

A block-level formatting object F which constructs lines does so by constructing block-areas which it returns to its parent formatting object, and placing normal areas and/or anchor areas returned to F by its child formatting objects as children of those block-areas or of line-areas which it constructs as children of those block-areas.

For each such formatting object F, it must be possible to form an ordered partition P consisting of ordered subsets S₁, S₂, ..., S_n of the normal areas and anchor areas returned by the child formatting objects, such that the following are all satisfied:

Substitutions that replace a sequence of glyph-areas with a single glyph-area should only occur when the margin, border, and padding in the inline-progression-direction (start- and end-), baseline-shift, and letter-spacing values are zero, treat-as-word-space is false, and the values of all other relevant traits match (i.e., alignment-adjust, alignment-baseline, color trait, background traits, dominant-baseline-identifier, font traits, text-depth, text-altitude, glyph-orientation-horizontal, glyph-orientation-vertical, line-height, line-height-shift-adjustment, text-decoration, text-shadow).

This section describes the ordering constraints that apply to formatting an fo:inline or similar inline-level object.

An inline-level formatting object F which constructs one or more inline-areas does so by placing normal inline-areas and/or anchor inline-areas returned to F by its child formatting objects as children of inline-areas which it generates.

For each such formatting object F, it must be possible to form an ordered partition P consisting of ordered subsets S₁, S₂, ..., S_n of the normal and/or anchor inline-areas returned by the child formatting objects, such that the following are all satisfied:

Each area is rendered in a particular location. Formatting object semantics describe the location of intrinsic marks relative to the object's location, i.e., the left, right, top, and bottom edges of its content-rectangle. This section describes how the area's location is determined, which determines the location of its intrinsic marks.

For each page, the page-viewport-area corresponds isometrically to the output medium.

The page-reference-area is offset from the page-viewport-area as described below in section .

All areas in the tree with an area-class of xsl-fixed are positioned such that the left-, right-, top-, and bottom-edges of its content-rectangle are offset inward from the content-rectangle of its ancestor page-viewport-area by distances specified by the left-position, right-position, top-position, and bottom-position traits, respectively.

Any area in the tree which is the child of a viewport-area is rendered as described in section .

All other areas in the tree are positioned such that the left-, right-, top-, and bottom-edges of its content-rectangle are offset inward from the content-rectangle of its nearest ancestor reference-area by distances specified by the left-position, right-position, top-position, and bottom-position traits, respectively. These are shifted down and left by the values of the top-offset and left-offset traits, respectively, if the area has a relative-position of relative.

A reference-area which is the child of a viewport-area is positioned such that the start-edge and end-edge of its content-rectangle are parallel to the start-edge and end-edge of the content-rectangle of its parent viewport-area. The start-edge of its content-rectangle is offset from the start-edge of the content-rectangle of its parent viewport-area by an inline-scroll-amount, and the before-edge of its content-rectangle is offset from the before-edge of the content-rectangle of its parent viewport-area by a block-scroll-amount.

If the block-progression-dimension of the reference-area is larger than that of the viewport-area and the overflow trait for the reference-area is scroll, then the inline-scroll-amount and block-scroll-amount are determined by a scrolling mechanism, if any, provided by the user agent. Otherwise, both are zero.

The visibility of marks depends upon the location of the marks, the visibility of the area, and the overflow of any ancestor viewport-areas.

If an area has visibility hidden it generates no marks.

If an area has an overflow of hidden, or when the environment is non-dynamic and the overflow is scroll then the area determines a clipping rectangle, which is defined to be the rectangle determined by the value of the clip trait of the area, and for any mark generated by one of its descendant areas, portions of the mark lying outside the clipping rectangle do not appear.

The border- and padding-rectangles are determined relative to the content-rectangle by the values of the common padding and border width traits (border-before-width, etc.).

For any area, which is not a child of a viewport-area, the border is rendered between the border-rectangle and the padding-rectangle in accordance with the common border color and style traits. For a child of a viewport-area, the border is not rendered.

For an area, which is not part of a viewport/reference pair, the background is rendered. For an area that is either a viewport-area or a reference-area in a viewport/reference pair, if the refined value of background-attachment is scroll and the block-progression-dimension of the reference-area is larger than that of the viewport-area, then the background is rendered on the reference-area and not the viewport-area, and otherwise it is rendered on the viewport-area and not the reference-area.

The background, if any, is rendered in the padding-rectangle, in accordance with the background-image, background-color, background-repeat, background-position-vertical, and background-position-horizontal traits.

For each class of formatting objects, the marks intrinsic to its generated areas are specified in the formatting object description. For example, an fo:character object generates a glyph-area, and this is rendered by drawing a glyph within that area's content-rectangle in accordance with the area's font traits and glyph-orientation and blink traits.

In addition, other traits (for example the various score and score-color traits) specify other intrinsic marks. In the case of score traits (underline-score, overline-score and through-score), the score thickness and position are specified by the nominal-font in effect; where the font fails to specify these quantities, they are implementation-dependent.

Marks are layered as described below, which defines a partial ordering of which marks are beneath which other marks.

Two marks are defined to conflict if they apply to the same point in the output medium. When two marks conflict, the one which is beneath the other does not affect points in the output medium where they both apply.

Marks generated by the same area are layered as follows: the area background is beneath the area's intrinsic marks, and the intrinsic marks are beneath the border. Layering among the area's intrinsic marks is defined by the semantics of the area's generating formatting object and its properties. For example, a glyph-area's glyph drawing comes beneath the marks generated for text-decoration.

The stacking layer of an area is defined by its stacking context and its z-index value. The stacking layer of an area A is defined to be less than that of an area B if some ancestor-or-self A' of A and B' of B have the same stacking context and the z-index of A' is less than the z-index of B'. If neither stacking layer is less than the other then they are defined to have the same stacking layer.

If A and B are areas, and the stacking layer of A is less than the stacking layer of B, then all marks generated by A are beneath all marks generated by B.

If A and B are areas with the same stacking layer, the backgrounds of A and B come beneath all other marks generated by A and B. Further, if A is an ancestor of B (still with the same stacking layer), then the background of A is beneath all the areas of B, and all the areas of B are beneath the intrinsic areas (and border) of A.

If A and B have the same stacking layer and neither is an ancestor of the other, then it is an error if either their backgrounds conflict or if a non-background mark of A conflicts with a non-background mark of B. An implementation may recover by proceeding as if the marks from the first area in the pre-order traversal order are beneath those of the other area.

The specified value of a property is determined using the following mechanisms (in order of precedence):

Since it has no parent, the root of the result tree cannot use values from its parent formatting object; in this case, the initial value is used if necessary.

Specified values may be absolute (i.e., they are not specified relative to another value, as in "red" or "2mm") or relative (i.e., they are specified relative to another value, as in "auto", "2em", and "12%"), or they may be expressions. For most absolute values, no computation is needed to find the computed value. Relative values, on the other hand, must be transformed into computed values: percentages must be multiplied by a reference value (each property defines which value that is), values with a relative unit (em) must be made absolute by multiplying with the appropriate font size, "auto" values must be computed by the formulas given with each property, certain property values ("smaller", "bolder") must be replaced according to their definitions. The computed value of any property that controls a border width where the style of the border is "none" is forced to be "0pt".

Some properties have more than one way in which the property value can be specified. The simplest example of such properties are those which can be specified either in terms of a direction relative to the writing-mode (e.g., padding-before) or a direction in terms of the absolute geometric orientation of the viewport (e.g., padding-top). These two properties are called the relative property and the absolute property, respectively. Collectively, they are called "corresponding properties".

Specifying a value for one property determines both a computed value for the specified property and a computed value for the corresponding property. Which relative property corresponds to which absolute property depends on the writing-mode. For example, if the "writing-mode" at the top level of a document is "lr-tb", then "padding-start" corresponds to "padding-left", but if the "writing-mode" is "rl-tb", then "padding-start" corresponds to "padding-right". The exact specification of how to compute the values of corresponding properties is given in .

In most cases, elements inherit computed values. However, there are some properties whose specified value may be inherited (e.g., some values for the "line-height" property). In the cases where child elements do not inherit the computed value, this is described in the property definition.

A computed value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may, therefore, have to adjust the computed width to an integral number of media pixels. The actual value is the computed value after any such adjustments have been applied.

Some of the properties applicable to formatting objects are "inheritable." Such properties are so identified in the property description. The inheritable properties can be placed on any formatting object. The inheritable properties are propagated down the formatting object tree from a parent to each child. (These properties are given their initial value at the root of the result tree.) For a given inheritable property, if that property is present on a child, then that value of the property is used for that child (and its descendants until explicitly re-set in a lower descendant); otherwise, the specified value of that property on the child is the computed value of that property on the parent formatting object. Hence there is always a specified value defined for every inheritable property for every formatting object.

The simplest class of corresponding properties are those for which there are only two variants in the correspondence, an absolute property and a relative property, and the property names differ only in the choice of absolute or relative designation; for example, "border-left-color" and "border-start-color".

For this class, the computed values of the corresponding properties are determined as follows. If the corresponding absolute variant of the property is specified on the formatting object, its computed value is used to set the computed value of the corresponding relative property. If the corresponding absolute property is not explicitly specified, then the computed value of the absolute property is set to the computed value of the corresponding relative property. If the corresponding relative property is specified on the formatting object and the absolute property only specified by the expansion of a shorthand, then the computed value of the absolute property is set to the computed value of the corresponding relative property.

Note that if both the absolute and the relative properties are not explicitly specified, then the rules for determining the specified value will use either inheritance if that is defined for the property or the initial value. The initial value must be the same for all possible corresponding properties. If both an absolute and a corresponding relative property are explicitly specified, then the above rule gives precedence to the absolute property, and the specified value of the corresponding relative property is ignored in determining the computed value of the corresponding properties.

The (corresponding) properties that use the above rule to determine their computed value are:

The "space-before", and "space-after" properties (block-level formatting objects), "space-start", and "space-end" properties (inline-level formatting objects) are handled in the same way as the properties immediately above, but the corresponding absolute properties are in the set: "margin-top", "margin-bottom", "margin-left", and "margin-right". The .conditionality component of any space-before or space-after determined from a margin property is set to "retain".

There are two more properties, "end-indent" and "start-indent" (block-level formatting objects) which correspond to the various absolute "margin" properties. For these properties, the correspondence is more complex and involves the corresponding "border-X-width" and "padding-X" properties, where X is one of "left", "right", "top" or "bottom". The computed values of these corresponding properties are determined as follows:

If the corresponding absolute "margin" property is specified on the formatting object and the formatting object generates a reference area the computed value of the margin is used to calculate the computed value of the corresponding "Y-indent" property, where Y is either "start" or "end". The formulae for "start-indent" and "end-indent" are":

start-indent = margin-corresponding + padding-corresponding + border-corresponding-width

end-indent = margin-corresponding + padding-corresponding + border-corresponding-width

If the corresponding absolute "margin" property is specified on the formatting object and the formatting object does not generate a reference area, the computed value of the margin and the computed values of the corresponding "border-X-width" and "padding-X" properties are used to calculate the computed value of the corresponding "Y-indent" property. The formulae for "start-indent" and "end-indent" are:

start-indent = inherited_value_of(start-indent) + margin-corresponding + padding-corresponding + border-corresponding-width

end-indent = inherited_value_of(end-indent) + margin-corresponding + padding-corresponding + border-corresponding-width

If the corresponding absolute margin property is not explicitly specified, or if the corresponding relative property is specified on the formatting object and the absolute property only specified by the expansion of a shorthand, the corresponding absolute margin property is calculated according to the following formulae:

margin-corresponding = start-indent - inherited_value_of(start-indent) - padding-corresponding - border-corresponding-width

margin-corresponding = end-indent - inherited_value_of(end-indent) - padding-corresponding - border-corresponding-width

Based on the writing-mode in effect for the formatting object, either the "height", "min-height", and "max-height" properties, or the "width", "min-width", and "max-width" properties are converted to the corresponding block-progression-dimension, or inline-progression-dimension.

The "height" properties are absolute and indicate the dimension from "top" to "bottom"; the width properties the dimension from "left" to "right".

If the "writing-mode" specifies a block-progression-direction of "top-to-bottom" or "bottom-to-top" the conversion is as follows:

If the "writing-mode" specifies a block-progression-direction of "left-to-right" or "right-to-left" the conversion is as follows:

The sum of the start-indent, end-indent, and inline-progression-dimension of the content-rectangle of an area should be equal to the inline-progression-dimension of the content-rectangle of the closest ancestor reference-area. In the case where a specification would lead to them being different the end-indent (and thus the corresponding margin) is adjusted such that the equality is true.

A value of "top", "bottom", "left", "right", or "center" is converted to a length as specified in the property definition.

If a value has not been specified on a formatting object to which this property applies the initial value is computed as specified in the property definition.

A value of "left", or "right" is converted to the writing-mode relative value as specified in the property definition.

A value of "left", or "right" is converted to the writing-mode relative value as specified in the property definition.

The value is converted to one that is absolute; i.e., the refined value is the specified value plus the refined value of z-index of its parent formatting object, if any.

The reference-orientation trait is copied from the reference-orientation property during refinement. During composition an absolute orientation is determined (see ).

The writing-mode, direction, and unicode-bidi traits are copied from the properties of the same name during refinement. During composition these are used in the determination of absolute orientations for the block-progression-direction, inline-progression-direction, and shift-direction traits in accordance with .

If absolute-position = "absolute" or "fixed", the values of the left-position, top-position, etc. traits are copied directly from the values of the "left", "top", etc. properties. Otherwise these traits' values are left undefined during refinement and determined during composition.

If relative-position = "relative" then the values of the left-offset and top-offset traits are copied directly from the "left" and "top" properties. If the "right" property is specified but "left" is not, then left-offset is set to the negative of the value of "right". If neither "left" nor "right" is specified the left-offset is 0. If the "bottom" property is specified but "top" is not, then top-offset is set to the negative of the value of "bottom". If neither "top" nor "bottom" is specified the top-offset is 0.

The "text-decoration" property value provides values for the blink trait and a set of score and score-color traits. The specified color has the value of the color trait of the formatting object for which the "text-decoration" property is being refined.

A property value containing the token "underline" sets a value of "true" to the underline-score trait, and a value of specified color to the underline-score-color trait.

A property value containing the token "overline" sets a value of "true" to the overline-score trait, and a value of specified color to the overline-score-color trait.

A property value containing the token "line-through" sets a value of "true" to the through-score trait, and a value of specified color to the through-score-color trait.

A property value containing the token "blink" sets a value of "true" to the blink trait.

A property value containing the token "no-underline" sets a value of "false" to the underline-score trait, and a value of specified color to the underline-score-color trait.

A property value containing the token "no-overline" sets a value of "false" to the overline-score trait, and a value of specified color to the overline-score-color trait.

A property value containing the token "no-line-through" sets a value of "false" to the through-score trait, and a value of specified color to the through-score-color trait.

A property value containing the token "no-blink" sets a value of "false" to the blink trait.

The font traits on an area are indirectly derived from the combination of the font properties, which are used to select a font, and the font tables from that font.

The abstract model that XSL assumes for a font is described in .

There is no XSL mechanism to specify a particular font; instead, a selected font is chosen from the fonts available to the User Agent based on a set of selection criteria. The selection criteria are the following font properties: "font-family", "font-style", "font-variant", "font-weight", "font-stretch", and "font-size", plus, for some formatting objects, one or more characters. The details of how the selection criteria are used is specified in the "font-selection-strategy" property (see ).

The nominal-font trait is set to the selected font. In the case where there is no selected font and the 'missing character' glyph is displayed, the nominal-font trait is set to the font containing that glyph, otherwise (i.e., some other mechanism was used to indicate that a character is not being displayed) the nominal-font is a system font.

The dominant-baseline-identifier and actual-baseline-table traits are derived from the value of the "dominant-baseline" property. The value of this property is a compound value with three components: a baseline-identifier for the dominant-baseline, a baseline-table and a baseline-table font-size. The dominant-baseline-identifier is set from the first component. The baseline-table font-size is used to scale the the positions of the baselines from the baseline table and, then, the position of the dominant-baseline is subtracted from the positions of the other baselines to yield a table of offsets from the dominant baseline. This table is the value of the actual-baseline-table trait.

The case changes specified by this property are carried out during refinement by changing the value of the "character" property appropriately.

Properties are evaluated against a property-specific context. This context provides:

When a type instance (e.g., a string, a keyword, a numeric, etc.) is recognized in the expression it is evaluated against the property context. This provides the ability for specific values to be converted with the property context's specific algorithms or conversions for use in the evaluation of the expression as a whole.

For example, the "auto" enumeration token for certain properties is a calculated value. Such a token would be converted into a specific type instance via an algorithm specified in the property definition. In such a case the resulting value might be an absolute length specifying the width of some aspect of the formatting object.

In addition, this allows certain types like relative numerics to be resolved into absolute numerics prior to mathematical operations.

All property contexts allow conversions as specified in .

When a set of properties is being evaluated for a specific formatting object in the formatting object tree there is a specific order in which properties must be evaluated. Essentially, the "font-size" property must be evaluated first before all other properties. Once the "font-size" property has been evaluated, all other properties may be evaluated in any order.

When the "font-size" property is evaluated, the current font-size for use in evaluation is the font-size of the parent element. Once the "font-size" property has been evaluated, that value is used as the current font-size for all property contexts of all properties value expressions being further evaluated.

A numeric represents all the types of numbers in an XSL expression. Some of these numbers are absolute values. Others are relative to some other set of values. All of these values use a floating-point number to represent the number-part of their definition.

A floating-point number can have any double-precision 64-bit format IEEE 754 value . These include a special Not-a-Number (NaN) value, positive and negative infinity, and positive and negative zero. See Section 4.2.3 of for a summary of the key rules of the IEEE 754 standard.

The following operators may be used with numerics:

If a non-numeric value is used in an AdditiveExpr and there is no property context conversion from that type into an absolute numeric value, the expression is invalid and considered an error.

An absolute numeric is an absolute length which is a pair consisting of a Number and a UnitName raised to a power. When an absolute length is written without a unit, the unit power is assumed to be zero. Hence, all floating point numbers are a length with a power of zero.

Each unit name has associated with it an internal ratio to some common internal unit of measure (e.g., a meter). When a value is written in a property expression, it is first converted to the internal unit of measure and then mathematical operations are performed.

In addition, only the mod, addition, and subtraction operators require that the numerics on either side of the operation be absolute numerics of the same unit power. For other operations, the unit powers may be different and the result should be mathematically consistent as with the handling of powers in algebra.

A property definition may constrain an absolute length to a particular power. For example, when specifying font-size, the value is expected to be of power "one". That is, it is expected to have a single powered unit specified (e.g., 10pt).

When the final value of a property is calculated, the resulting power of the absolute numeric must be either zero or one. If any other power is specified, the value is an error.

Relative lengths are values that are calculated relative to some other set of values. When written as part of an expression, they are either converted via the property context into an absolute numeric or passed verbatim as the property value.

It is an error if the property context has no available conversion for the relative numeric and a conversion is required for expression evaluation (e.g., within an add operation).

Strings are represented either as literals or as an enumeration token. All properties contexts allow conversion from enumeration tokens to strings. See .

A color is a set of values used to identify a particular color from a color space. Only RGB (Red, Green, Blue) and ICC (International Color Consortium) colors are included in this Recommendation.

RGB colors are directly represented in the expression language using a hexadecimal notation. ICC colors can be specified through an rgb-icc function. Colors can also be specified through the system-color function or through conversion from an EnumerationToken via the property context.

Keywords are special tokens in the grammar that provide access to calculated values or other property values. The allowed keywords are defined in the following subsections.

When processing an expression, white space (ExprWhitespace) may be allowed before or after any expression token even though it is not explicitly defined as such in the grammar. In some cases, white space is necessary to make tokens in the grammar lexically distinct. Essentially, white space should be treated as if it does not exist after tokenization of the expression has occurred.

The following special tokenization rules must be applied in the order specified to disambiguate the grammar:

Values that are the result of an expression evaluation may be converted into property value types. In some instances this is a simple verification of set membership (e.g., is the value a legal country code). In other cases, the value is expected to be a simple type like an integer and must be converted.

It is not necessary that all types be allowed to be converted. If the expression value cannot be converted to the necessary type for the property value, it is an error.

The following table indicates what conversions are allowed.

The specific conversion to be applied is property specific and can be found in the definition of each property.

The units of measure in this Recommendation have the following definitions:

The floor function returns the largest (closest to positive infinity) integer that is not greater than the argument. The numeric argument to this function must be of unit power zero.

The ceiling function returns the smallest (closest to negative infinity) integer that is not less than the argument. The numeric argument to this function must be of unit power zero.

The round function returns the integer that is closest to the argument. If there are two such numbers, then the one that is closest to positive infinity is returned. The numeric argument to this function must be of unit power zero.

The min function returns the minimum of the two numeric arguments. These arguments must have the same unit power.

The max function returns the maximum of the two numeric arguments. These arguments must have the same unit power.

The abs function returns the absolute value of the numeric argument. That is, if the numeric argument is negative, it returns the negation of the argument.

The rgb function returns a specific color from the RGB color space. The parameters to this function must be numerics (real numbers) with a length power of zero.

The rgb-icc function returns a specific color from the ICC Color Profile. The color profile is specified by the name parameter (the fourth parameter). This color profile must have been declared in the fo:declarations formatting object using an fo:color-profile formatting object.

The first three parameters specify a fallback color from the sRGB color space. This color is used when the color profile is not available.

The color is specified by a sequence of one or more color values (real numbers) specified after the name parameter. These values are specific to the color profile.

The system-color function returns a system defined color with a given name.

The system-font function returns a characteristic of a system font. The first argument is the name of the system font and the second argument, which is optional, names the property that specifies the characteristic. If the second argument is omitted, then the characteristic returned is the same as the name of the property to which the expression is being assigned.

For example, the expression "system-font(heading,font-size)" returns the font-size characteristic for the system font named "heading". This is equivalent to the property assignment 'font-size="system-font(heading)"'.

The inherited-property-value function returns the inherited value of the property whose name matches the argument specified, or if omitted for the property for which the expression is being evaluated. It is an error if this property is not an inherited property.

The returned "inherited value" is the computed value of this property on this object's parent. In particular, given the following example:

The background-color property on the fo:block is assigned the value "red" because the (computed, after inheritance) value of the color (not background-color) property on the fo:list-item-body that is the parent of fo:block is "red".

This categorization leads to defining two traits which characterize the relationship between an area and the formatting objects which generate and return that area. These traits are generated-by and returned-by.

The value of the generated-by trait is a single formatting object. A formatting object F is defined to generate an area A if the semantics of F specify the generation of one or more areas and A is one of the areas thus generated, or is a substituted form of one of the areas thus generated, as specified in section .

In the case of substituted glyph-areas, the generating formatting object is deemed to be the formatting object which generated the glyph-area which comes first in the sequence of substituted glyph-areas. In the case of an inserted glyph-area (e.g., an automatically-generated hyphen) the generating formatting object is deemed to be the generating formatting object of the last glyph-area preceding the inserted glyph-area in the pre-order traversal of the area tree.

The value of the returned-by trait is a set of pairs, where each pair consists of a formatting object and a positive integer. The integer represents the position of the area in the ordering of all areas returned by the formatting object.

A formatting object F is defined to return the sequence of areas A, B, C, ... if the pair (F,1) is a member of the returned-by trait of A, the pair (F,2) is a member of the returned-by trait of B, the pair (F,3) is a member of the returned-by trait of C, ...

If an area is a member of the sequence of areas returned by a formatting object, then either it was generated by the formatting object or it was a member of the sequence of areas returned by a child of that formatting object. Not all areas returned by a child of a formatting object need be returned by that formatting object. A formatting object may generate an area that has, as some of its children areas, areas returned by the children of that formatting object. These children (in the area tree) of the generated area are not returned by the formatting object to which they were returned.

A set of nodes in a tree is a lineage if:

The set of formatting objects that an area is returned by is a lineage.

Areas returned by a formatting object may be either normal or out-of-line. Normal areas represent areas in the "normal flow of text"; that is, they become area children of the areas generated by the formatting object to which they are returned. Normal areas have a returned-by lineage of size one. There is only one kind of normal area.

Out-of-line areas are areas used outside the normal flow of text either because they are absolutely positioned or they are part of a float or footnote. Out-of-line areas may have a returned-by lineage of size greater than one.

The area-class trait indicates which class, normal or out-of-line, an area belongs to. For out-of-line areas, it also indicates the subclass of out-of-line area. The values for this trait are: "xsl-normal", "xsl-absolute", "xsl-footnote", "xsl-side-float", or "xsl-before-float". An area is normal if and only if the value of the area-class trait is "xsl-normal"; otherwise, the area is an out-of-line area. (See section .)

The areas returned-by a given formatting object are ordered as noted above. This ordering defines an ordering on the sub-sequence of areas that are of a given area-class, such as the sub-sequence of normal areas. An area A precedes an area B in the sub-sequence if and only if area A precedes area B in the areas returned-by the formatting objects.

A reference-area chain is defined as a sequence of reference-areas that is either generated by the same formatting object that is not a page-sequence formatting object, or that consists of the region reference-areas or normal-flow-reference-areas (see ) generated using region formatting objects assigned to the same flow (see ). The reference-areas in the sequence are said to be "contained" by the reference-area chain, and they have the same ordering relative to each other in the sequence as they have in the area tree, using pre-order traversal order of the area tree.

The root node of the formatting object tree must be an fo:root formatting object. The children of the fo:root formatting object are a single fo:layout-master-set, an optional fo:declarations, and a sequence of one or more fo:page-sequences. The fo:layout-master-set defines the geometry and sequencing of the pages; the children of the fo:page-sequences, which are called flows (contained in fo:flow and fo:static-content), provide the content that is distributed into the pages. The fo:declarations object is a wrapper for formatting objects whose content is to be used as a resource to the formatting process. The process of generating the pages is done automatically by the XSL processor formatting the result tree.

The children of the fo:layout-master-set are the pagination and layout specifications. The names of these specifications end in "-master". There are two types of pagination and layout specifications: page-masters and page-sequence-masters. Page-masters have the role of describing the intended subdivisions of a page and the geometry of these subdivisions. Page-sequence-masters have the role of describing the sequence of page-masters that will be used to generate pages during the formatting of an fo:page-sequence.

Common Usage:

This is the top node of the formatting object tree. It holds an fo:layout-master-set formatting object (which holds all masters used in the document), an optional fo:declarations, and one or more fo:page-sequence objects. Each fo:page-sequence represents a sequence of pages that result from formatting the content children of the fo:page-sequence.

Areas:

Page-viewport-areas are returned by the fo:page-sequence children of the fo:root formatting object. The fo:root does not generate any areas.

Constraints:

The children of the root of the area tree consist solely of, and totally of, the page-viewport-areas returned by the fo:page-sequence children of the fo:root. The set of all areas returned by the fo:page-sequence children is properly ordered. (See Section .)

Contents:

The following properties apply to this formatting object:

Common Usage:

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

Areas:

The fo:declarations formatting object does not generate or return any areas.

Constraints:

None.

Contents:

The fo:declarations flow object may have additional child elements in a non-XSL namespace. Their presence does not, however, change the semantics of the XSL namespace objects and properties. The permitted structure of these non-XSL namespace elements is defined for their namespace(s).

Common Usage:

The fo:color-profile formatting object is used to declare an ICC Color Profile for a stylesheet. The color-profile is referenced again via the name specified in the "color-profile-name" property.

The color-profile is identified by the URI specified in the "src" property value. This URI may identify an internally recognized color-profile or it may point to a ICC Color Profile encoding that should be loaded and interpreted.

When the color-profile is referenced (e.g., via the rgb-icc function ), the following rules are used:

Areas:

The fo:color-profile formatting object does not generate or return any areas.

Constraints:

None.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:page-sequence formatting object is used to specify how to create a (sub-)sequence of pages within a document; for example, a chapter of a report. The content of these pages comes from flow children (consisting of the single fo:flow and any fo:static-content flow objects) of the fo:page-sequence. The layout of these pages comes from the fo:page-sequence-master or page-master referenced by the master-reference trait on the fo:page-sequence. The sequence of areas returned by each of the flow-object children of the fo:page-sequence are made descendants of the generated pages as described below.

Areas:

The fo:page-sequence formatting object generates a sequence of viewport/reference pairs, and returns the page-viewport-areas. For each page-reference-area, and each region specified in the page-master used to generate that page-reference-area, the fo:page-sequence object also generates the viewport/reference pair for the occurrence of that region in that page-reference-area, and may generate a before-float-reference-area, footnote-reference-area, and main-reference-area, and one or more normal-sequence-reference-areas. The generation of these further areas is described in the descriptions of the fo:simple-page-master and region-masters. It may also generate a title-area.

All areas generated by an fo:page-sequence have area-class "xsl-absolute".

Constraints:

Each page-viewport-area/page-reference-area pair is generated using a page-master that satisfies the constraints of the page-sequence-master identified by the master-reference trait of the fo:page-sequence or a page-master that was directly identified by the master-reference trait. The region-viewport-area children of such a page-reference-area must correspond to the regions that are children of that page-master.

The areas generated by the fo:page-sequence have as their descendants the areas returned by the flows that are children of the fo:page-sequence.

The areas returned to the fo:page-sequence by a flow must satisfy four types of constraints:

If a title-area is generated the following constraints must be satisfied:

The default ordering constraint of section does not apply to the fo:page-sequence. The default ordering constraints apply to the flow object children inside the single fo:flow; special ordering constraints apply to the child fo:static-content objects.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:layout-master-set is a wrapper around all masters used in the document. This includes page-sequence-masters, page-masters, and region-masters.

Areas:

The fo:layout-master-set formatting object generates no area directly. The masters that are the children of the fo:layout-master-set are used by the fo:page-sequence to generate pages.

Constraints:

The value of the master-name trait on each child of the fo:layout-master-set must be unique within the set.

Contents:

Common Usage:

The fo:page-sequence-master is used to specify the constraints on and the order in which a given set of page-masters will be used in generating a sequence of pages. Pages are automatically generated when the fo:page-sequence-master is used in formatting an fo:page-sequence.

Areas:

The fo:page-sequence-master formatting object generates no area directly. It is used by the fo:page-sequence formatting object to generate pages.

Constraints:

The children of the fo:page-sequence-master are a sequence of sub-sequence-specifiers. A page-sequence satisfies the constraint determined by an fo:page-sequence-master if (a) it can be partitioned into a sequence of sub-sequences of pages that map one-to-one to an initial sub-sequence of the sequence of sub-sequence-specifiers that are the children of the fo:page-sequence-master and, (b) for each sub-sequence of pages in the partition, that sub-sequence satisfies the constraints of the corresponding sub-sequence-specifier. The sequence of sub-sequences of pages can be shorter than the sequence of sub-sequence-specifiers.

It is an error if the entire sequence of sub-sequence-specifiers children is exhausted while some areas returned by an fo:flow are not placed. Implementations may recover, if possible, by re-using the sub-sequence-specifier that was last used to generate a page.

Contents:

The following properties apply to this formatting object:

Common Usage:

An fo:single-page-master-reference is the simplest sub-sequence-specifier. It specifies a sub-sequence consisting of a single instance of a single page-master. It is used to specify the use of a particular page-master at a given point in the sequence of pages that would be generated using the fo:page-sequence-master that is the parent of the fo:single-page-master-reference.

Areas:

The fo:single-page-master-reference formatting object generates no area directly. It is used by the fo:page-sequence formatting object to generate pages.

Constraints:

The fo:single-page-master-reference has a reference to the fo:simple-page-master which has the same master-name as the master-reference trait on the fo:single-page-master-reference.

The sub-sequence of pages mapped to this sub-sequence-specifier satisfies the constraints of this sub-sequence-specifier if (a) the sub-sequence of pages consists of a single page and (b) that page is constrained to have been generated using the fo:simple-page-master referenced by the fo:single-page-master-reference.

Contents:

The following properties apply to this formatting object:

Common Usage:

An fo:repeatable-page-master-reference is the next simplest sub-sequence-specifier. It specifies a sub-sequence consisting of repeated instances of a single page-master. The number of repetitions may be bounded or potentially unbounded.

Areas:

The fo:repeatable-page-master-reference formatting object generates no area directly. It is used by the fo:page-sequence formatting object to generate pages.

Constraints:

The fo:repeatable-page-master-reference has a reference to the fo:simple-page-master which has the same master-name as the master-reference trait on the fo:repeatable-page-master-reference.

The sub-sequence of pages mapped to this sub-sequence-specifier satisfies the constraints of this sub-sequence-specifier if (a) the sub-sequence of pages consists of zero or more pages, (b) each page is generated using the fo:simple-page-master referenced by the fo:repeatable-page-master-reference, and (c) length of the sub-sequence is less than or equal to the value of maximum-repeats.

If no region-master child of the fo:repeatable-page-master has a region-name associated to any flow in an fo:page-sequence, then the sub-sequence is constrained to have length zero.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:repeatable-page-master-alternatives formatting object is the most complex sub-sequence-specifier. It specifies a sub-sequence consisting of repeated instances of a set of alternative page-masters. The number of repetitions may be bounded or potentially unbounded. Which of the alternative page-masters is used at any point in the sequence depends on the evaluation of a condition on the use of the alternative. Typical conditions include, testing whether the page which is generated using the alternative is the first or last page in a page-sequence or is the page blank. The full set of conditions allows different page-masters to be used for the first page, for odd and even pages, for blank pages.

Areas:

The fo:repeatable-page-master-alternatives formatting object generates no area directly. This formatting object is used by the fo:page-sequence formatting object to generate pages.

Constraints:

The children of the fo:repeatable-page-master-alternatives are fo:conditional-page-master-references. These children will be called alternatives.

The sub-sequence of pages mapped to this sub-sequence-specifier satisfies the constraints of this sub-sequence-specifier if (a) the sub-sequence of pages consists of zero or more pages, (b) each page is generated using the fo:simple-page-master referenced by the one of the alternatives that are the children of the fo:repeatable-page-master-alternatives, (c) the conditions on that alternative are true, (d) that alternative is the first alternative in the sequence of children for which all the conditions are true, and (e) the length of the sub-sequence is less than or equal to the value of maximum-repeats.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:conditional-page-master-reference is used to identify a page-master that is to be used when the conditions on its use are satisfied. This allows different page-masters to be used, for example, for even and odd pages, for the first page in a page-sequence, or for blank pages. This usage is typical in chapters of a book or report where the first page has a different layout than the rest of the chapter and the headings and footings on even and odd pages may be different as well.

Areas:

The fo:conditional-page-master-reference formatting object generates no area directly. It is used by the fo:page-sequence formatting object to generate pages.

Constraints:

The fo:conditional-page-master-reference has a reference to the fo:simple-page-master which has the same master-name as the master-reference trait on the fo:conditional-page-master-reference.

There are three traits, page-position, odd-or-even, and blank-or-not-blank that specify the sub-conditions on the use of the referenced page-master. All three sub-conditions must be true for the condition on the fo:conditional-page-master-reference to be true. Since the properties from which these traits are derived are not inherited and the initial value of all the properties makes the corresponding sub-condition true, this really means that the subset of traits that are derived from properties with specified values must make the corresponding sub-condition true.

The sub-condition corresponding to the page-position trait is true if the page generated using the fo:conditional-page-master-reference has the specified position in the sequence of pages generated by the referencing page-sequence; namely, "first", "last", "rest" (not first nor last) or "any" (all of the previous). The referencing page-sequence is the fo:page-sequence that referenced the fo:page-sequence-master from which this fo:conditional-page-master-reference is a descendant.

The sub-condition corresponding to the odd-or-even trait is true if the value of the odd-or-even trait is "any" or if the value matches the parity of the page number of the page generated using the fo:conditional-page-master-reference.

The sub-condition corresponding to the blank-or-not-blank trait is true, if (1) the value of the trait is "not-blank" and the page generated using the fo:conditional-page-master-reference has areas generated by descendants of the fo:flow formatting object; if (2) the value of the trait is "blank" and the page generated using the fo:conditional-page-master-reference is such that there are no areas from the fo:flow to be put on that page (e.g., (a) to maintain proper page parity due to (i) a break-after or break-before value of "even-page" or "odd-page" or (ii) at the start or end of the page-sequence or (b) because the constraints on the areas generated by descendants of the fo:flow formatting object would not be satisfied if they were descendant from this page); or if (3) the value of the trait is "any".

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:simple-page-master is used in the generation of pages and specifies the geometry of the page. The page may be subdivided into up to five regions: region-body, region-before, region-after, region-start, and region-end.

Areas:

The fo:simple-page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence.

When the fo:simple-page-master is used to generate a page, a viewport/reference pair is generated, consisting of a page-viewport-area and a page-reference-area. The page-viewport-area represents the physical bounds of the output medium. The page-reference-area represents the portion of the page on which content is intended to appear; that is, the area inside the page margins.

In addition, when the fo:simple-page-master is used to generate a page, viewport/reference pairs that correspond to the regions that are the children of the fo:simple-page-master are also generated. (See the formatting object specifications for the five regions (, , , , and ) for the details on the generation of these areas.)

Trait Derivation:

In version 1.0 of this Recommendation, borders and padding are not allowed with a page-reference-area. The remaining traits on the page-reference-area are set according to normal rules for determining the values of traits.

Constraints:

When a page-master is used in the generation of a page, the block-progression-dimension and inline-progression-dimension of the content-rectangle of the page-viewport-area are determined using the computed values of the "page-height" and "page-width" properties.

The traits derived from the margin properties determine the size and position of the content-rectangle of the page-viewport-area. The traits derived from the "margin-top", "margin-bottom", "margin-left" and "margin-right" properties are used to indent the page-reference-area content-rectangle from the corresponding edge of the content-rectangle of the page-viewport-area. Here "top", "bottom", "left" and "right" are determined by the computed values of the "page-height" and "page-width" properties. For sheet media, these values determine the orientation of the sheet; "page-height" is measured from "top" to "bottom". For display media, the display window is always upright; the top of the display screen is "top".

Common Usage:

Used in constructing a simple-page-master. This region specifies a viewport/reference pair that is located in the "center" of the fo:simple-page-master. The overflow trait controls how much of the underlying region-reference-area is visible; that is, whether the region-reference-area is clipped by its parent region-viewport-area.

The fo:region-body may be also be used to provide multiple columns. When the column-count trait is greater than one, then the region-body will be subdivided into multiple columns.

Areas:

The fo:region-body formatting object is used to generate one region-viewport-area and one region-reference-area whenever an fo:simple-page-master that has an fo:region-body as a child is used to generate a page. A scrolling mechanism shall be provided, in an implementation-defined manner, if the value of the overflow trait is "scroll".

The position and size of the region-viewport-area is specified relative to the content-rectangle of the page-reference-area generated by fo:simple-page-master. The content-rectangle of the region-viewport-area is indented from the content-rectangle of the page-reference-area by the values of the "margin-top", "margin-bottom", "margin-left" and "margin-right" properties. In version 1.0 of this Recommendation, the values of the padding and border-width traits must be "0".

The region-reference-area generated using an fo:region-body is the child of the region-viewport-area. The reference-orientation trait of the fo:region-body is used to orient the coordinate system of the region-reference-area generated by the fo:region-body relative to the coordinate system of the page-reference-area generated by fo:simple-page-master (and, therefore, relative to the viewport positioned in that latter coordinate system).

In addition to the viewport/reference pair, when the region-body is used to generate areas, at least one and up to three additional reference-areas are generated. These reference-areas are the optional before-float-reference-area, the optional footnote-reference-area, and the main-reference-area. The latter reference-area comprises the space left after space is borrowed for the other two reference-areas. The main-reference-area has no padding, border, or space associated with it.

The main-reference-area has as its children a sequence of span-reference-areas. These are reference-area block-areas with zero border and padding, whose inline-progression-dimension is equal to that of the main-reference-area, and which are normally stacked within the main-reference-area.

Each span-reference-area has one or more reference-area children, designated as normal-flow-reference-areas. The number and placement of the children of a span-reference-area depends on the column-count trait of the span-reference-area. In turn, the formatter must generate precisely enough of these span-reference-areas, and so set their column-count traits, that block-areas returned from the fo:flow with a span of "all" are children of span-reference-areas with column-count equal to 1, and block-areas returned from the fo:flow with a span of "none" are children of span-reference-areas with column-count equal to the refined value of the column-count property of the associated region-reference-area.

For each span-reference-area, the number N of normal-flow-reference-area children is equal to the value of the column-count trait.

It is an error to specify a column-count other than 1 if the "overflow" property has the value "scroll". An implementation may recover by behaving as if "1" had been specified.

The inline-progression-dimension of each of these normal-flow-reference-areas is determined by subtracting (N-1) times the column-gap trait from the inline-progression-dimension of the main-reference-area and dividing that result by N. Using "body-in-size" for the name of the inline-progression-dimension of the span-reference-area and "column-in-size" for the name of the size of the normal-flow-reference-areas in the inline-progression-direction, the formula is:

column-in-size = (body-in-size - (N - 1)*column-gap)/N

The block-progression-dimension of the normal-flow-reference-areas is the same as that of the parent span-reference-area.

The normal-flow-reference-areas are positioned within the span-reference-area as follows: The first column is positioned with the before-edge and start-edge of its content-rectangle coincident with the before-edge and start-edge of the content-rectangle of the span-reference-area. The content-rectangle of the Jth normal-flow-reference-area child of the span-reference-area is positioned with its before-edge coincident with the before-edge of the content-rectangle of the span-reference-area and with is start-edge at ((J-1)*(column-in-size + column-gap)) in the inline-progression-direction. This results in the end-edge of the content-rectangle of the Nth normal-flow-reference-area being coincident with the end-edge of the content-rectangle of the span-reference-area.

All areas generated by using the fo:region-body are of area-class "xsl-absolute".

Trait Derivation:

The reference-orientation of the region-viewport-area is taken from the value of the reference-orientation trait on the region-master which specifies the region. reference-orientation of the region-reference-area is set to "0" and is, therefore, the same as the orientation established by the region-viewport-area.

The remaining traits on the region-viewport-area and region-reference-area are set according to normal rules for determining the values of traits.

The traits on the span-reference-areas and on the normal-flow-reference-areas are determined, in the same manner as described in , from a set of properties where each property has its initial value except for reference-orientation, writing-mode, and display-align that have the value from the fo:region-body.

Constraints:

The constraints applicable to all regions (see ) all apply.

The inline-progression-dimension of the region-viewport-area is determined by the inline-progression-dimension of the content-rectangle of the page-reference-area minus the values of the start-indent and end-indent traits of the region-master. The start-edge and end-edge of the content-rectangle of the region-viewport-area are determined by the reference-orientation trait on the page-master.

The block-progression-dimension of the region-viewport-area is determined by the block-progression-dimension of the content-rectangle for the page-reference-area minus the values of the space-before and space-after traits of the region-master. The before-edge and after-edge of the content-rectangle of the region-viewport-area are determined by the reference-orientation trait on the page-master.

The values of the space-before and start-indent traits are used to position the region-viewport-area relative to the before-edge and start-edge of the content-rectangle of the page-reference-area.

The constraints on the size and position of the region-reference-area generated using the fo:region-body are covered in the "Constraints applicable to regions" section of .

Contents:

The following properties apply to this formatting object:

Common Usage:

Used in constructing a simple-page-master. This region specifies a viewport/reference pair that is located on the "before" side of the page-reference-area. In lr-tb writing-mode, this region corresponds to the header region. The overflow trait controls how much of the underlying region-reference-area is visible; that is, whether the region-reference-area is clipped by its parent region-viewport-area.

Areas:

The fo:region-before formatting object is used to generate one region-viewport-area and one region-reference-area.

In version 1.0 of this Recommendation, the values of the padding and border-width traits must be "0".

The before-edge of the content-rectangle of this region-viewport-area is positioned coincident with the before-edge of the content-rectangle of the page-reference-area generated using the parent fo:simple-page-master. The block-progression-dimension of the region-viewport-area is determined by the extent trait on the fo:region-before formatting object.

The inline-progression-dimension of the region-viewport-area is determined by the precedence trait on the fo:region-before. If the value of the precedence trait is true, then the inline-progression-dimension extends up to the start-edge and end-edge of the content-rectangle of the page-reference-area. In this case, the region-before region-viewport-area acts like a float into areas generated by the region-start and region-end. If the value of the precedence trait on the fo:region-before is false, then these adjacent regions float into the area generated by the fo:region-before and the extent of the fo:region-before is (effectively) reduced by the incursions of the adjacent regions.

The region-reference-area lies on a canvas underneath the region-viewport-area. The reference-orientation trait is used to orient the coordinate system of the region-reference-area relative to the page-reference-area.

The size of the region-reference-area depends on the setting of the overflow trait on the region. If the value of that trait is "auto", "hidden", "error-if-overflow", "paginate", or "visible" then the size of the reference-area is the same as the size of the viewport. If the value of the overflow trait is "scroll", the size of the reference-area is equal to the size of the viewport in the inline-progression-direction in the writing-mode for the region and has no constraint in the block-progression-direction (which implies that it grows to hold the distribution of all the content bound to the region).

Trait Derivation:

The reference-orientation of the region-viewport-area is taken from the value of the reference-orientation trait on the region-master which specifies the region. reference-orientation of the region-reference-area is set to "0" and is, therefore, the same as the orientation established by the region-viewport-area.

The remaining traits on the region-viewport-area and region-reference-area are set according to normal rules for determining the values of traits.

Constraints:

The constraints on the size and position of the region-reference-area generated using the fo:region-before are covered in the "Constraints applicable to regions" section of .

Contents:

The following properties apply to this formatting object:

Common Usage:

Used in constructing a simple-page-master. This region specifies a viewport/reference pair that is located on the "after" side of the page-reference-area. In lr-tb writing-mode, this region corresponds to the footer region. The overflow trait controls how much of the underlying region-reference-area is visible; that is, whether the region-reference-area is clipped by its parent region-viewport-area.

Areas:

The fo:region-after formatting object is used to generate one region-viewport-area and one region-reference-area.

In version 1.0 of this Recommendation, the values of the padding and border-width traits must be "0".

The after-edge of the content-rectangle of this region-viewport-area is positioned coincident with the after-edge of the content-rectangle of the page-reference-area generated using the parent fo:simple-page-master. The block-progression-dimension of the region-viewport-area is determined by the extent trait on the fo:region-after formatting object.

The inline-progression-dimension of the region-viewport-area is determined by the precedence trait on the fo:region-after. If the value of the precedence trait is true, then the inline-progression-dimension extends up to the start-edge and end-edge of the content-rectangle of the page-reference-area. In this case, the region-after region-viewport-area acts like a float into areas generated by the region-start and region-end. If the value of the precedence trait on the fo:region-after is false, then these adjacent regions float into the area generated by the fo:region-after and the extent of the fo:region-after is (effectively) reduced by the incursions of the adjacent regions.

The region-reference-area lies on a canvas underneath the region-viewport-area. The reference-orientation trait is used to orient the coordinate system of the region-reference-area relative to the page-reference-area.

The size of the region-reference-area depends on the setting of the overflow trait on the region. If the value of that trait is "auto", "hidden", "error-if-overflow", "paginate", or "visible" then the size of the reference-area is the same as the size of the viewport. If the value of the overflow trait is "scroll", the size of the reference-area is equal to the size of the viewport in the inline-progression-direction in the writing-mode for the region and has no constraint in block-progression-direction (which implies that it grows to hold the distribution of all the content bound to the region).

Trait Derivation:

The reference-orientation of the region-viewport-area is taken from the value of the reference-orientation trait on the region-master which specifies the region. reference-orientation of the region-reference-area is set to "0" and is, therefore, the same as the orientation established by the region-viewport-area.

The remaining traits on the region-viewport-area and region-reference-area are set according to normal rules for determining the values of traits.

Constraints:

The constraints on the size and position of the region-reference-area generated using the fo:region-after are covered in the "Constraints applicable to regions" section of .

Contents:

The following properties apply to this formatting object:

Common Usage:

Used in constructing a simple-page-master. This region specifies a viewport/reference pair that is located on the "start" side of the page-reference-area. In lr-tb writing-mode, this region corresponds to a left sidebar. The overflow trait controls how much of the underlying region-reference-area is visible; that is, whether the region-reference-area is clipped by its parent region-viewport-area.

Areas:

The fo:region-start formatting object is used to generate one region-viewport-area and one region-reference-area.

In version 1.0 of this Recommendation, the values of the padding and border-width traits must be "0".

The start-edge of the content-rectangle of this region-viewport-area is positioned coincident with the start-edge of the content-rectangle of the page-reference-area generated using the parent fo:simple-page-master. The inline-progression-dimension of the region-viewport-area is determined by the extent trait on the fo:region-after formatting object.

The block-progression-dimension of the region-viewport-area is determined by the precedence trait on the adjacent fo:region-before and the fo:region-after, if these exist; otherwise it is determined as if the value of the precedence trait was false. If the value of the precedence trait of the fo:region-before (or, respectively, fo:region-after) is false, then the block-progression-dimension extends up to the before- (or, respectively, after-) edge of the content-rectangle of the page-reference-area. In this case, the region-start acts like a float into areas generated by the region-before (respectively, the region-after). If the value of the precedence trait on the adjacent regions is true, then these adjacent regions float into the area generated by the fo:region-start and the extent of the fo:region-start is (effectively) reduced by the incursions of the adjacent regions with the value of the precedence trait equal to true.

The region-reference-area lies on a canvas underneath the region-viewport-area. The reference-orientation trait is used to orient the coordinate system of the region-reference-area relative to the page-reference-area.

The size of the region-reference-area depends on the setting of the overflow trait on the region. If the value of that trait is "auto", "hidden", "error-if-overflow", "paginate", or "visible" then the size of the reference-area is the same as the size of the viewport. If the value of the overflow trait is "scroll", the size of the reference-area is equal to the size of the viewport in the inline-progression-direction in the writing-mode for the region and has no constraint in block-progression-direction (which implies that it grows to hold the distribution of all the content bound to the region).

Trait Derivation:

The reference-orientation of the region-viewport-area is taken from the value of the reference-orientation trait on the region-master which specifies the region. reference-orientation of the region-reference-area is set to "0" and is, therefore, the same as the orientation established by the region-viewport-area.

The remaining traits on the region-viewport-area and region-reference-area are set according to normal rules for determining the values of traits.

Constraints:

The constraints on the size and position of the region-reference-area generated using the fo:region-start are covered in the "Constraints applicable to regions" section of .

Contents:

The following properties apply to this formatting object:

Common Usage:

Used in constructing a simple-page-master. This region specifies a viewport/reference pair that is located on the "end" side of the page-reference-area. In lr-tb writing-mode, this region corresponds to a right sidebar. The overflow trait controls how much of the underlying region-reference-area is visible; that is, whether the region-reference-area is clipped by its parent region-viewport-area.

Areas:

The fo:region-end formatting object is used to generate one region-viewport-area and one region-reference-area.

In version 1.0 of this Recommendation, the values of the padding and border-width traits must be "0".

The end-edge of the content-rectangle of this region-viewport-area is positioned coincident with the end-edge of the content-rectangle of the page-reference-area generated using the parent fo:simple-page-master. The inline-progression-dimension of the region-viewport-area is determined by the extent trait on the fo:region-after formatting object.

The block-progression-dimension of the region-viewport-area is determined by the precedence trait on the adjacent fo:region-before and the fo:region-after, if these exist; otherwise it is determined as if the value of the precedence trait was false. If the value of the precedence trait of the fo:region-before (or, respectively, fo:region-after) is false, then the block-progression-dimension extends up to the before- (or, respectively, after-) edge of the content-rectangle of the page-reference-area. In this case, the region-end acts like a float into areas generated by the region-before (respectively, the region-after). If the value of the precedence trait on the adjacent regions is true, then these adjacent regions float into the area generated by the fo:region-end and the extent of the fo:region-end is (effectively) reduced by the incursions of the adjacent regions with the value of the precedence trait equal to true.

The region-reference-area lies on a canvas underneath the region-viewport-area. The reference-orientation trait is used to orient the coordinate system of the region-reference-area relative to the page-reference-area.

The size of the region-reference-area depends on the setting of the overflow trait on the region. If the value of that trait is "auto", "hidden", "error-if-overflow", "paginate", or "visible" then the size of the reference-area is the same as the size of the viewport. If the value of the overflow trait is "scroll", the size of the reference-area is equal to the size of the viewport in the inline-progression-direction in the writing-mode for the region and has no constraint in block-progression-direction (which implies that it grows to hold the distribution of all the content bound to the region).

Trait Derivation:

The reference-orientation of the region-viewport-area is taken from the value of the reference-orientation trait on the region-master which specifies the region. reference-orientation of the region-reference-area is set to "0" and is, therefore, the same as the orientation established by the region-viewport-area.

The remaining traits on the region-viewport-area and region-reference-area are set according to normal rules for determining the values of traits.

Constraints:

The constraints on the size and position of the region-reference-area generated using the fo:region-end are covered in the "Constraints applicable to regions" section of .

Contents:

The following properties apply to this formatting object:

Common Usage:

The content of the fo:flow formatting object is a sequence of flow objects that provides the flowing text content that is distributed into pages.

Areas:

The fo:flow formatting object does not generate any areas. The fo:flow formatting object returns a sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:flow. The order of concatenation is the same order as the children are ordered under the fo:flow.

Constraints:

The (implicit) flow-map determines the assignment of the content of the fo:flow to a region.

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:static-content formatting object holds a sequence or a tree of formatting objects that is to be presented in a single region or repeated in like-named regions on one or more pages in the page-sequence. Its common use is for repeating or running headers and footers.

This content is repeated, in its entirety, on every page to which it is assigned.

Areas:

The fo:static-content formatting object does not generate any areas. The fo:static-content formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:static-content. The order of concatenation is the same order as the children are ordered under the fo:static-content.

Constraints:

The (implicit) flow-map determines the assignment of the content of the fo:static-content to a region.

The fo:static-content may be processed multiple times and thus the default ordering constraint of section does not apply to the fo:static-content. Instead, it must satisfy the constraint on a per-page basis. Specifically, if P is a page-reference-area, C is an area-class, and S is the set of all descendants of P of area-class C returned to the fo:static-content descendant, then S must be properly-ordered.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:title formatting object is used to associate a title with a given page-sequence. This title may be used by an interactive User Agent to identify the pages. For example, the content of the fo:title can be formatted and displayed in a "title" window or in a "tool tip".

Areas:

This formatting object returns the sequence of areas returned by the children of this formatting object.

Constraints:

The sequence of returned areas must be the concatenation of the sub-sequences of areas returned by each of the flow children of the fo:title formatting object in the order in which the children occur.

Contents:

An fo:title is not permitted to have an fo:float, fo:footnote or fo:marker as a descendant.

Additionally, an fo:title is not permitted to have as a descendant an fo:block-container that generates an absolutely positioned area.

The following properties apply to this formatting object:

The fo:block formatting object is used for formatting paragraphs, titles, figure captions, table titles, etc. The following example illustrates the usage of the fo:block in a stylesheet.

Common Usage:

The fo:block formatting object is commonly used for formatting paragraphs, titles, headlines, figure and table captions, etc.

Areas:

The fo:block formatting object generates one or more normal block-areas. The fo:block returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:block. The fo:block also generates zero or more line-areas as children of the normal block-areas it returns, in accordance with .

Trait Derivation:

The .minimum, .optimum, and .maximum components of the half-leading trait are set to 1/2 the difference of the computed value of the line-height property and the computed value of the sum of the text-altitude and text-depth properties. The .precedence and .conditionality components are copied from the line-height property.

Constraints:

No area may have more than one normal child area returned by the same fo:block formatting object.

The children of each normal area generated by an fo:block must satisfy the constraints specified in .

In addition the constraints imposed by the traits derived from the properties applicable to this formatting object must be satisfied. The geometric constraints are rigorously defined in .

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children, optionally followed by an fo:initial-property-set.

The following properties apply to this formatting object:

Common Usage:

The fo:block-container flow object is used to generate a block-level reference-area, typically containing text blocks with a different writing-mode. In addition, it can also be used with a different reference-orientation to rotate its content.

Areas:

The fo:block-container formatting object generates one or more viewport/reference pairs. The fo:block-container returns these areas and any page-level-out-of-line areas returned by the children of the fo:block-container.

Trait Derivation:

The areas generated by the fo:block-container formatting object have a value of "true" for the is-reference-area.

The size of the viewport-area and the reference-area has to be fixed in the inline-progression-direction. It must be specified unless the inline-progression-direction is parallel to the inline-progression-direction of the reference-area into which the areas generated by this flow object are placed.

Constraints:

The children of each reference-area generated by an fo:block-container formatting object must be normal block-areas returned by the children of the fo:block-container, must be properly stacked, and must be properly ordered.

Any reference-level-out-of-line areas returned by the children of the fo:block-container are handled as described in .

Contents:

In addition an fo:block-container that does not generate an absolutely positioned area may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Inline-level formatting objects are most commonly used to format a portion of text or for generating rules and leaders. There are many other uses. The following examples illustrate some of these uses of inline-level formatting objects.

Common Usage:

The fo:bidi-override formatting object is used when the Unicode BIDI algorithm fails. It forces a string of text to be written in a specific direction.

Areas:

The fo:bidi-override formatting object generates one or more normal inline-areas. The fo:bidi-override returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:bidi-override.

Trait Derivation:

The direction traits are derived from the "writing-mode", "direction", and "unicode-bidi" properties as described in .

Constraints:

No area may have more than one normal child area returned by the same fo:bidi-override formatting object.

The children of each normal area returned by an fo:bidi-override must satisfy the constraints specified in .

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

An fo:bidi-override that is a descendant of an fo:leader or of an fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container.

The following properties apply to this formatting object:

Common Usage:

The fo:character flow object represents a character that is mapped to a glyph for presentation. It is an atomic unit to the formatter.

When the result tree is interpreted as a tree of formatting objects, a character in the result tree is treated as if it were an empty element of type fo:character with a character attribute equal to the Unicode representation of the character. The semantics of an "auto" value for character properties, which is typically their initial value, are based on the Unicode code point. Overrides may be specified in an implementation-specific manner.

Unicode Tag Characters need not be supported.

Areas:

The fo:character formatting object generates and returns one or more normal inline-area.

Constraints:

The dimensions of the areas are determined by the font metrics for the glyph.

When formatting an fo:character with a "treat-as-word-space" value of "true", the User Agent may use a different method for determining the inline-progression-dimension of the area.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:initial-property-set auxiliary formatting object specifies formatting properties for the first line of an fo:block.

Areas:

The fo:initial-property-set formatting object does not generate or return any areas. It simply holds a set of traits that are applicable to the first line-area of the area that has a value of "true" for the is-first trait and that was generated by the parent fo:block of the fo:initial-property-set.

Trait Derivation:

The traits on the fo:initial-property-set are taken into account as traits constraining the first line as if the child inline formatting objects of the fo:block, or parts of them in the case of a line-break, that were used in formatting the first line were enclosed by an fo:wrapper, as a direct child of the fo:block, with those traits.

Constraints:

None.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:external-graphic flow object is used for a graphic where the graphics data resides outside of the fo:element tree.

Areas:

The fo:external-graphic formatting object generates and returns one inline-level viewport-area and one reference-area containing the external graphic. The inline-level area uses the large-allocation-rectangle as defined in .

Constraints:

The viewport's size is determined by the block-progression-dimension and inline-progression-dimension traits. For values of "auto", the content size of the graphic is used.

The content size of a graphic is determined by taking the intrinsic size of the graphic and scaling as specified by the content-height, content-width, and scaling traits. If one of the content-height or content-width is not "auto", the same scale factor (as calculated from the specified non-auto value) is applied equally to both directions.

Once scaled, the reference-area is aligned with respect to the viewport-area using the text-align and display-align traits. If it is too large for the viewport-area, the graphic is aligned as if it would fit and the overflow trait controls the clipping, scroll bars, etc.

In the case when the graphics format does not specify an intrinsic size of the graphic the size is determined in an implementation-defined manner.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:instream-foreign-object flow object is used for an inline graphic or other "generic" object where the object data resides as descendants of the fo:instream-foreign-object, typically as an XML element subtree in a non-XSL namespace.

Areas:

The fo:instream-foreign-object formatting object generates and returns one inline viewport-area and one reference-area containing the instream-foreign-object. The inline-level area uses the large-allocation-rectangle as defined in .

Constraints:

The viewport's size is determined by the block-progression-dimension and inline-progression-dimension traits. For values of "auto", the content size of the instream foreign object is used.

The content size of an instream-foreign-object is determined by taking the intrinsic size of the object and scaling as specified by the content-height, content-width, and scaling traits. If one of the content-height or content-width is not "auto", the same scale factor (as calculated from the specified non-auto value) is applied equally to both directions.

Once scaled, the reference-area is aligned with respect to the viewport-area using the text-align and display-align traits. If it is too large for the viewport-area, the instream-foreign-object is aligned as if it would fit and the overflow trait controls the clipping, scroll bars, etc.

In the case when the instream-foreign-object does not specify an intrinsic size of the object, the size is determined in an implementation defined manner.

Contents:

The fo:instream-foreign-object flow object has a child from a non-XSL namespace. The permitted structure of this child is that defined for that namespace.

The fo:instream-foreign-object flow object may have additional attributes in the non-XSL namespace. These, as well as the xsl defined properties, are made available to the processor of the content of the flow object. Their semantics is defined by that namespace.

The following properties apply to this formatting object:

Common Usage:

The fo:inline formatting object is commonly used for formatting a portion of text with a background or enclosing it in a border.

Areas:

The fo:inline formatting object generates one or more normal inline-areas. The fo:inline returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:inline.

Constraints:

No area may have more than one normal child area returned by the same fo:inline formatting object.

The children of each normal area returned by an fo:inline must satisfy the constraints specified in .

In addition the constraints imposed by the traits derived from the properties applicable to this formatting object must be satisfied. The geometric constraints are rigorously defined in .

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

An fo:inline that is a child of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container.

The following properties apply to this formatting object:

Common Usage:

The fo:inline-container flow object is used to generate an inline reference-area, typically containing text blocks with a different writing-mode.

Areas:

The fo:inline-container formatting object generates one or more viewport/reference pairs. The viewport-areas generated by the fo:inline-container are normal inline-level areas that use the large-allocation-rectangle as defined in . The fo:inline-container returns these areas and any page-level-out-of-line areas returned by the children of the fo:inline-container.

Trait Derivation:

The areas generated by the fo:inline-container formatting object have a value of "true" for the is-reference-area.

The size of the viewport-area and the reference-area has to be fixed in the inline-progression-direction. It must be specified unless the inline-progression-direction is parallel to the inline-progression-direction of the reference-area into which the areas generated by this flow object are placed.

The values in the baseline-table of this object are calculated as follows:

Constraints:

No area may have more than one normal child area returned by the same fo:inline-container formatting object.

The children of each reference-area generated by an fo:inline-container formatting object must be normal block-areas returned by the children of the fo:inline-container, must be properly stacked, and must be properly ordered.

Any reference-level-out-of-line areas returned by the children of the fo:inline-container are handled as described in .

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:leader formatting object is often used:

Areas:

The fo:leader formatting object generates and returns a single normal inline-area.

Trait Derivation:

If the value of the leader-pattern is "use-content" the block-progression-dimension of the content-rectangle is determined in the same manner as for line-areas; otherwise it is determined by the rule-thickness trait.

Constraints:

If the leader's minimum length is too long to place in the line-area, the leader will begin a new line. If it is too long to be placed in a line by itself, it will overflow the line and potentially overflow the reference-area in accordance with that container's overflow trait.

The fo:leader formatting object can have any inline formatting objects and characters as its children, except that fo:leaders may not be nested. Its children are ignored unless the value of the leader-pattern trait is "use-content".

The inline-area generated by the fo:leader has a dimension in the inline-progression-direction which shall be at least the leader-length.minimum and at most the leader-length.maximum.

For lines-areas that have been specified to be justified, the justified line-area must honor the leader-alignment trait of any inline-areas generated by fo:leaders.

If the value of the leader-pattern trait is "dots" or "use-content", the following constraint applies:

The inline-area generated by the fo:leader has as its children the areas returned by children of the fo:leader, or obtained by formatting the pattern specified in the leader-pattern trait, repeated an integral number of times. If the width of even a single repetition is larger than the dimension of the inline-area in the inline-progression-direction, the inline-area shall be filled with blank space. The space-start and space-end of the child areas is set to account for the constraints specified in the leader-pattern-width and leader-alignment traits.

Contents:

The content must not contain an fo:leader, fo:inline-container, fo:block-container, fo:float, fo:footnote, or fo:marker either as a direct child or as a descendant.

The following properties apply to this formatting object:

Common Usage:

The fo:page-number formatting object is used to obtain an inline-area whose content is the page-number for the page on which the inline-area is placed.

Areas:

The fo:page-number formatting object generates and returns a single normal inline-area.

Constraints:

The child areas of this inline-area are the same as the result of formatting a result-tree fragment consisting of fo:character flow objects; one for each character in the page-number string and with only the "character" property specified.

The page-number string is obtained by converting the page-number for the page on which the inline-area is placed in accordance with the number to string conversion properties of the ancestor fo:page-sequence.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:page-number-citation is used to reference the page-number for the page containing the first normal area returned by the cited formatting object.

Areas:

The fo:page-number-citation formatting object generates and returns a single normal inline-area.

Constraints:

The cited page-number is the number of the page containing, as a descendant, the first normal area returned by the formatting object with an id trait matching the ref-id trait of the fo:page-number-citation (the referenced formatting object).

The cited page-number string is obtained by converting the cited page-number in accordance with the number to string conversion properties of the ancestor fo:page-sequence of the referenced formatting object.

The child areas of the generated inline-area are the same as the result of formatting a result-tree fragment consisting of fo:character flow objects; one for each character in the cited page-number string and with only the "character" property specified.

Contents:

The following properties apply to this formatting object:

There are nine formatting objects used to construct tables: fo:table-and-caption, fo:table, fo:table-column, fo:table-caption, fo:table-header, fo:table-footer, fo:table-body, fo:table-row, and fo:table-cell. The result tree structure is shown below.

Common Usage:

The fo:table-and-caption flow object is used for formatting a table together with its caption.

Areas:

The fo:table-and-caption formatting object generates one or more normal block-areas. The fo:table-and-caption returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:table-and-caption.

Constraints:

No area may have more than one normal child area returned by the same fo:table-and-caption formatting object.

The children of the areas generated by the fo:table-and-caption are one or two areas; one for the table caption and one for the table itself. These are positioned relative to each other as specified by the caption-side trait. They are placed relative to the content-rectangle of the generated area as specified by the text-align trait.

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:table flow object is used for formatting the tabular material of a table.

The fo:table flow object and its child flow objects model the visual layout of a table in a "row primary" manner. A complete table may be seen as consisting of a grid of rows and columns where each cell occupies one or more grid units in the row-progression-direction and column-progression-direction.

The table content is divided into a header (optional), footer (optional), and one or more bodies. Properties specify if the headers and footers should be repeated at a break in the table. Each of these parts occupies one or more rows in the table grid.

Areas:

The fo:table formatting object generates and returns one or more normal block-areas. In addition the fo:table returns any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:table.

The areas generated and returned by the fo:table formatting object have as children:

These areas have a z-index controlling the rendering order determined in accordance with 17.5.1 of the CSS2 specification (http://www.w3.org/TR/REC-CSS2/tables.html#table-layers").

Trait Derivation:

The areas generated and returned by the fo:table formatting object have a value of "true" for the is-reference-area.

The column-progression-direction and row-progression-direction are determined by the writing-mode trait. Columns use the inline-progression-direction, and rows use the block-progression-direction.

The method for deriving the border traits for a table is specified by the "border-collapse" property.

If the value of the "border-collapse" property is "separate" the border is composed of two components. The first, which is placed with the inside edge coincident with the outermost table grid boundary line, has the width of half the value for the "border-separation" property. It is filled in accordance with the "background" property of the fo:table. Second, outside the outermost table grid boundary line is placed, for each side of the table, a border based on a border specified on the table.

If the value of the "border-collapse" property is "collapse" or "collapse-with-precedence" the border is determined, for each segment, at the cell level.

Constraints:

No area may have more than one normal child area returned by the same fo:table formatting object.

The inline-progression-dimension of the content-rectangle of the table is the sum of the inline-progression-dimensions of the columns in the table grid. The method used to determine these inline-progression-dimensions is governed by the values of the table-layout and the inline-progression-dimension traits in the following manner:

The automatic table layout and fixed table layout is defined in 17.5.2 of the CSS2 specification (http://www.w3.org/TR/REC-CSS2/tables.html#width-layout").

The method for determining the block-progression-dimension of the table is governed by the block-progression-dimension trait.

It is an error if two table-cells overlap.

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:table-column auxiliary formatting object specifies characteristics applicable to table cells that have the same column and span. The most important property is the "column-width" property.

Areas:

The fo:table-column formatting object does not generate or return any areas. It holds a set of traits that provide constraints on the column widths and a specification of some presentation characteristics, such as background which affects the areas generated by the fo:table (see ). Inheritable properties may also be specified on the fo:table-column. These can be referenced by the from-table-column() function in an expression.

Constraints:

None.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:table-caption formatting object is used to contain block-level formatting objects containing the caption for the table only when using the fo:table-and-caption.

Areas:

The fo:table-caption formatting object generates one or more normal reference-areas. The fo:table-caption returns these reference-areas and any page-level-out-of-line areas returned by the children of the fo:table-caption.

Trait Derivation:

The areas generated by the fo:table-caption formatting object have a value of "true" for the is-reference-area.

Constraints:

For the case when the value of the caption-side trait is "before" or "after" the inline-progression-dimension of the content-rectangle of the generated reference-area is equal to the inline-progression-dimension of the content-rectangle of the reference-area that encloses it.

When the value is "start" or "end" the inline-progression-dimension of the generated reference-area is constrained by the value of the inline-progression-dimension trait.

When the value is "top", "bottom", "left", or "right" the value is mapped in the same way as for corresponding properties (see ) and the property is then treated as if the corresponding value had been specified.

If the caption is to be positioned before the table, the areas generated by the fo:table-caption shall be placed in the area tree as though the fo:table-caption had a "keep-with-next" property with value "always".

If the caption is to be positioned after the table, the areas generated by the fo:table-caption shall be placed in the area tree as though the fo:table-caption had a "keep-with-previous" property with value "always".

No area may have more than one normal child area returned by the same fo:table-caption formatting object.

The children of each normal area returned by an fo:table-caption formatting object must be normal block-areas returned by the children of the fo:table-caption, must be properly stacked, and must be properly ordered.

Any reference-level-out-of-line areas returned by the children of the fo:table-caption are handled as described in .

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:table-header formatting object is used to contain the content of the table header.

Areas:

The fo:table-header formatting object does not generate any areas. The fo:table-header formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:table-header.

Constraints:

The order of concatenation of the sequences of areas returned by the children of the fo:table-header is the same order as the children are ordered under the fo:table-header.

Contents:

The fo:table-header has fo:table-row (one or more) as its children, or alternatively fo:table-cell (one or more). In the latter case cells are grouped into rows using the starts-row and ends-row properties.

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:table-footer formatting object is used to contain the content of the table footer.

Areas:

The fo:table-footer formatting object does not generate any areas. The fo:table-footer formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:table-footer.

Constraints:

The order of concatenation of the sequences of areas returned by the children of the fo:table-footer is the same order as the children are ordered under the fo:table-footer.

Contents:

The fo:table-footer has fo:table-row (one or more) as its children, or alternatively fo:table-cell (one or more). In the latter case cells are grouped into rows using the starts-row and ends-row properties.

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:table-body formatting object is used to contain the content of the table body.

Areas:

The fo:table-body formatting object does not generate any areas. The fo:table-body formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:table-body.

Constraints:

The order of concatenation of the sequences of areas returned by the children of the fo:table-body is the same order as the children are ordered under the fo:table-body.

Contents:

The fo:table-body has fo:table-row (one or more) as its children, or alternatively fo:table-cell (one or more). In the latter case cells are grouped into rows using the starts-row and ends-row properties.

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:table-row formatting object is used to group table-cells into rows; all table-cells in a table-row start in the same geometric row on the table grid.

Areas:

The fo:table-row formatting object does not generate any areas. The fo:table-row formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:table-row. The fo:table-row holds a specification of some presentation characteristics, such as background which affects the areas generated by the fo:table (see ).

Constraints:

The order of concatenation of the sequences of areas returned by the children of the fo:table-row is the same order as the children are ordered under the fo:table-row.

The method for determining the height of the row in the grid is governed by the row-height trait.

Contents:

The following properties apply to this formatting object:

Common Usage:

The fo:table-cell formatting object is used to group content to be placed in a table cell.

The "starts-row" and "ends-row" properties can be used when the input data does not have elements containing the cells in each row, but instead, for example, each row starts at elements of a particular type.

Areas:

The fo:table-cell formatting object generates one or more normal reference-areas. The fo:table-cell returns these reference-areas and any page-level-out-of-line areas returned by the children of the fo:table-cell.

Trait Derivation:

The areas generated by the fo:table-cell formatting object have a value of "true" for the is-reference-area.

The method for deriving the border for a cell is specified by the border-collapse trait.

If the value of the border-collapse trait is "separate" the border is composed of two components. The first, which is placed with the outside edge coincident with the table grid boundary line, has the width of half the value for the border-separation trait. It is filled in accordance with the background trait of the fo:table. Inside this border is placed, for each side of the cell, a border based on a border specified on the cell or inherited.

If the value of the border-collapse trait is "collapse-with-precedence" the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the highest precedence. It is an error if there are two such borders that have the same precedence but are not identical. An implementation may recover by selecting one of the borders. Each border segment is placed centered on the table grid boundary line. On devices that do not support sub-pixel rendering, if an effective border width is determined to be an odd number of pixels it is implementation defined on which side of the grid boundary line the odd pixel is placed.

If the value of the border-collapse trait is "collapse", the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the most "eye catching" border style, see below for the details. Each border segment is placed centered on the table grid boundary line. On devices that do not support sub-pixel rendering, if an effective border width is determined to be an odd number of pixels it is implementation defined on which side of the grid boundary line the odd pixel is placed. Where there is a conflict between the styles of border segments that collapse, the following rules determine which border style "wins":

Constraints:

A table-cell occupies one or more grid units in the row-progression-direction and column-progression-direction. The content-rectangle of the cell is the size of the portion of the grid the cell occupies minus, for each of the four sides:

The method for determining the block-progression-dimension of the cell in the grid is governed by the row-height trait.

No area may have more than one normal child area returned by the same fo:table-cell formatting object.

The children of each normal area returned by an fo:table-cell formatting object must be normal block-areas returned by the children of the fo:table-cell, must be properly stacked, and must be properly ordered.

Any reference-level-out-of-line areas returned by the children of the fo:table-cell are handled as described in .

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

There are four formatting objects used to construct lists: fo:list-block, fo:list-item, fo:list-item-label, and fo:list-item-body.

The fo:list-block has the role of containing the complete list and of specifying values used for the list geometry in the inline-progression-direction (see details below).

The children of the fo:list-block are one or more fo:list-item, each containing a pair of fo:list-item-label and fo:list-item-body.

The fo:list-item has the role of containing each item in a list.

The fo:list-item-label has the role of containing the content, block-level formatting objects, of the label for the list-item; typically an fo:block containing a number, a dingbat character, or a term.

The fo:list-item-body has the role of containing the content, block-level formatting objects, of the body of the list-item; typically one or more fo:block.

The placement, in the block-progression-direction, of the label with respect to the body is made in accordance with the "vertical-align" property of the fo:list-item.

Common Usage:

The fo:list-block flow object is used to format a list.

Areas:

The fo:list-block formatting object generates one or more normal block-areas. The fo:list-block returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:list-block.

Constraints:

No area may have more than one normal child area returned by the same fo:list-block formatting object.

The children of each normal area returned by an fo:list-block formatting object must be normal block-areas returned by the children of the fo:list-block, must be properly stacked, and must be properly ordered.

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:list-item formatting object contains the label and the body of an item in a list.

Areas:

The fo:list-item formatting object generates one or more normal block-areas. The fo:list-item returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:list-item.

Constraints:

No area may have more than one normal child area returned by the same fo:list-item formatting object.

The children of each normal area returned by an fo:list-item formatting object must be normal block-areas returned by the fo:list-item-label and the fo:list-item-body flow objects and must be properly ordered. Those returned by the fo:list-item-label must be properly stacked and those returned by the fo:list-item-body must be properly stacked.

The children of each normal area returned by an fo:list-item formatting object returned by the fo:list-item-label and fo:list-item-body objects are positioned in the block-progression-direction with respect to each other according to the relative-align trait.

In the inline-progression-direction these areas are positioned in the usual manner for properly stacked areas. It is an error if the content-rectangles of the areas overlap.

The block-progression-dimension of the content-rectangle of an area generated by the fo:list-item is just large enough so that the allocation-rectangles of all its child areas are contained in it. In particular, the space-before and space-after of the child areas have no effect on the spacing of the list item. For purposes of the block-stacking constraints the areas generated by fo:list-item are treated as if there they have a fence preceding and a fence following them.

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:list-item-body formatting object contains the content of the body of a list-item.

Areas:

The fo:list-item-body formatting object does not generate any areas. The fo:list-item-body formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:list-item-body.

Constraints:

The order of concatenation of the sequences of areas returned by the children of the fo:list-item-body is the same order as the children are ordered under the fo:list-item-body.

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:list-item-label formatting object contains the content of the label of a list-item, typically used to either enumerate, identify, or adorn the list-item's body.

Areas:

The fo:list-item-label formatting object does not generate any areas. The fo:list-item-label formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:list-item-label.

Constraints:

The order of concatenation of the sequences of areas returned by the children of the fo:list-item-label is the same order as the children are ordered under the fo:list-item-label.

Contents:

In addition this formatting object may have a sequence of zero or more fo:markers as its initial children.

The following properties apply to this formatting object:

Common Usage:

The fo:float formatting object is typically used either to cause an image to be positioned in a separate area at the beginning of a page, or to cause an image to be positioned to one side, with normal content flowing around and along-side the image.

Areas:

The fo:float generates an optional single area with area-class "xsl-anchor", and one or more block-areas that all share the same area-class, which is either "xsl-before-float", "xsl-side-float" or "xsl-normal" as specified by the "float" property. (An fo:float generates normal block-areas if its "float" property value is "none".)

Areas with area-class "xsl-side-float" are reference areas.

An area with area-class "xsl-before-float" is placed as a child of a before-float-reference-area.

The optional area with area-class "xsl-anchor" is not generated if the "float" property value is "none", or if, due to an error as described in the constraints section, the fo:float shall be formatted as though its "float" property was "none". Otherwise, the area with area-class "xsl-anchor" shall be generated.

The area with area-class "xsl-anchor" has no children, and is an inline-area, except where this would violate the constraints that (a.) any area's children must be either block-areas or inline-areas, but not a mixture, and (b.) the children of a line-area may not consist only of anchor areas. In the case where an inline-area would violate these constraints, the fo:float must instead generate a block-area.

Constraints:

The normal inline-area generated by the fo:float shall be placed in the area tree as though the fo:float had a "keep-with-previous" property with value "always". The inline-area has a length of zero for both the inline-progression-dimension and block-progression-dimension.

The term anchor-area is used here to mean the area with area-class "xsl-anchor" generated by the fo:float. An area with area-class "xsl-side-float" is a side-float.

No area may have more than one child block-area with the same area-class returned by the same fo:float formatting object.

Areas with area-class "xsl-before-float" must be properly ordered within the area tree relative to other areas with the same area-class.

The padding-, border-, and content-rectangles of the block-areas generated by fo:float all coincide. That is, the padding and border are zero at all edges of the area.

The following constraints apply to fo:float formatting objects that generate areas with area-class "xsl-before-float":

The following constraints apply to fo:float formatting objects that generate areas with area-class "xsl-side-float":

Contents:

An fo:float is not permitted to have an fo:float, fo:footnote or fo:marker as a descendant.

Additionally, an fo:float is not permitted to have as a descendant an fo:block-container that generates an absolutely positioned area.

The following properties apply to this formatting object:

Common Usage:

The fo:footnote is typically used to produce footnote-citations within the region-body of a page and the corresponding footnote in a separate area nearer the after-edge of the page.

Areas:

The fo:footnote formatting object does not generate any areas. The fo:footnote formatting object returns the areas generated and returned by its child fo:inline formatting object.

Additionally the fo:footnote formatting object returns the block-areas with area class "xsl-footnote" generated by its fo:footnote-body child. An area with area-class "xsl-footnote" is placed as a child of a footnote-reference-area.

Constraints:

The term anchor-area is defined to mean the last area that is generated and returned by the fo:inline child of the fo:footnote.

A block-area returned by the fo:footnote is only permitted as a descendant from a footnote-reference-area that is (a) descendant from a "region-reference-area" generated using the region-master for the region to which the flow that has the fo:footnote as a descendant is assigned, and (b) is descendant from the same page that contains the anchor-area, or from a page following the page that contains the anchor-area.

The second block-area and any additional block-areas returned by an fo:footnote must be placed on the immediately subsequent pages to the page containing the first block-area returned by the fo:footnote, before any other content is placed. If a subsequent page does not contain a region-body, the user agent must use the region-master of the last page that did contain a region-body to hold the additional block-areas.

It is an error if the fo:footnote occurs as a descendant of a flow that is not assigned to a region-body, or of an fo:block-container that generates absolutely positioned areas. In either case, the block-areas generated by the fo:footnote-body child of the fo:footnote shall be returned to the parent of the fo:footnote and placed in the area tree as though they were normal block-level areas.

Contents:

An fo:footnote is not permitted to have an fo:float, fo:footnote, or fo:marker as a descendant.

Additionally, an fo:footnote is not permitted to have as a descendant an fo:block-container that generates an absolutely positioned area.

The following properties apply to this formatting object:

Common Usage:

The fo:footnote-body is used to generate the footnote content.

Areas:

The fo:footnote-body generates and returns one or more block-level areas with area-class "xsl-footnote".

Constraints:

The fo:footnote-body is only permitted as a child of an fo:footnote.

No area may have more than one child block-area returned by the same fo:footnote-body formatting object.

Areas with area-class "xsl-footnote" must be properly ordered within the area tree relative to other areas with the same area-class.

Contents:

The following properties apply to this formatting object:

The following example shows the use of the fo:wrapper formatting object that has no semantics but acts as a "carrier" for inherited properties.

Common Usage:

The fo:wrapper formatting object is used to specify inherited properties for a group of formatting objects.

Areas:

The fo:wrapper formatting object does not generate any areas. The fo:wrapper formatting object returns the sequence of areas created by concatenating the sequences of areas returned by each of the children of the fo:wrapper.

Trait Derivation:

Except for "id", the fo:wrapper has no properties that are directly used by it. However, it does serve as a carrier to hold inheritable properties that are utilized by its children.

Constraints:

The order of concatenation of the sequences of areas returned by the children of the fo:wrapper is the same order as the children are ordered under the fo:wrapper.

Contents:

An fo:wrapper is only permitted to have children that would be permitted to be children of the parent of the fo:wrapper, with two exceptions:

This restriction applies recursively.

The following properties apply to this formatting object:

Common Usage:

The fo:marker is used in conjunction with fo:retrieve-marker to produce running headers or footers. Typical examples include:

The fo:marker has to be an initial child of its parent formatting object.

Areas:

The fo:marker does not directly produce any area. Its children may be retrieved and formatted from within an fo:static-content, using an fo:retrieve-marker whose "retrieve-class-name" property value is the same as the "marker-class-name" property value of this fo:marker.

Constraints:

An fo:marker is only permitted as the descendant of an fo:flow.

Note: Property values set on an fo:marker or its ancestors will not be inherited by the children of the fo:marker when they are retrieved by an fo:retrieve-marker.

It is an error if two or more fo:markers that share the same parent have the same "marker-class-name" property value.

Contents:

An fo:marker may contain any formatting objects that are permitted as a replacement of any fo:retrieve-marker that retrieves the fo:marker's children.

The following properties apply to this formatting object:

Common Usage:

The fo:retrieve-marker is used in conjunction with fo:marker to produce running headers or footers. Typical examples include:

Areas:

The fo:retrieve-marker does not directly generate any area. It is (conceptually) replaced by the children of the fo:marker that it retrieves.

Trait Derivation:

The properties and traits specified on the ancestors of the fo:retrieve-marker are taken into account when formatting the children of the retrieved fo:marker as if the children had the same ancestors as the fo:retrieve-marker.

Constraints:

An fo:retrieve-marker is only permitted as the descendant of an fo:static-content.

The fo:retrieve-marker specifies that the children of a selected fo:marker shall be formatted as though they replaced the fo:retrieve-marker in the formatting tree.

The properties of the fo:retrieve-marker impose a hierarchy of preference on the areas of the area tree. Each fo:marker is conceptually attached to each normal area returned by the fo:marker's parent formatting object. Additionally, an fo:marker is conceptually attached to each non-normal area that is directly generated by the fo:marker's parent formatting object. Conversely, areas generated by any descendant of an fo:flow may have zero or more fo:marker's conceptually attached. The fo:marker whose children are retrieved is the one that is (conceptually) attached to the area that is at the top of this hierarchy.

Every area in the hierarchy is considered preferential to, or "better" than, any area below it in the hierarchy. When comparing two areas to determine which one is better, the terms "first" and "last" refer to the pre-order traversal order of the area tree.

The term "containing page" is used here to mean the page that contains the first area generated or returned by the children of the retrieved fo:marker.

An area that has an attached fo:marker whose "marker-class-name" property value is the same as the "retrieve-class-name" property value of the fo:retrieve-marker is defined to be a qualifying area. Only qualifying areas have positions in the hierarchy.

A qualifying area within a page is better than any qualifying area within a preceding page, except that areas do not have a position in the hierarchy if they are within pages that follow the containing page. If the "retrieve-boundary" property has a value of "page-sequence", then an area does not have a position in the hierarchy if it is on a page from a page-sequence preceding the page-sequence of the containing page. If the "retrieve-boundary" property has a value of "page", then an area does not have a position in the hierarchy if it is not on the containing page.

If the value of the "retrieve-position" property is "first-starting-within-page", then the first qualifying area in the containing page whose "is-first" trait has a value of "true" is better than any other area. If there is no such area, then the first qualifying area in the containing page is better than any other area.

If the value of the "retrieve-position" property is "first-including-carryover", then the first qualifying area in the containing page is better than any other area.

If the value of the "retrieve-position" property is "last-starting-within-page", then the last qualifying area in the containing page whose "is-first" trait has a value of "true" is better than any other area. If there is no such area, then the last qualifying area in the containing page is better than any other area.

If the value of the "retrieve-position" property is "last-ending-within-page", then the last qualifying area in the containing page whose "is-last" trait has a value of "true" is better than any other area. If there is no such area, then the last qualifying area in the containing page is better than any other area.

If the hierarchy of areas is empty, no formatting objects are retrieved.

Contents:

The following properties apply to this formatting object:

XSL Definition:

It is used by all formatting objects that can be contained in fo:flow or fo:static-content (all formatting objects that can be directly created from an XML source element).

Values have the following meanings:

This property provides a pointer back to the original XML document(s) used to create this formatting object tree, in accordance with the Dublin Core definition of "Source" ("A Reference to a resource from which the present resource is derived." See: http://purl.org/DC/documents/rec-dces-19990702.htm.) The value is not validated by and has no inherent standardized semantics for any XSL processor.

W3C Accessibility guidelines, http://www.w3.org/TR/WCAG20/, http://www.w3.org/TR/ATAG10/, and http://www.w3.org/TR/UAAG10/, strongly encourage the use of this property either on the fo:root or on the first formatting object generated from a given source document.

The URI reference is useful for alternate renderers (aural readers, etc.) whenever the structure of the formatting object tree is inappropriate for that renderer.

XSL Definition:

It is used by all formatting objects that can be contained in fo:flow or fo:static-content (all formatting objects that can be directly created from an XML source element).

Values have the following meanings:

This property provides a hint for alternate renderers (aural readers, etc.) as to the role of the XML element or elements that were used to construct this formatting object, if one could be identified during XSLT tree construction. This information can be used to prepare alternate renderings when the normal rendering of a formatting object is not appropriate or satisfactory; for example, the role information can be used to provide better aural renderings of visually formatted material.

To aid alternate renderers, the <string> value should be the qualified name (QName ) of the element from which this formatting object is constructed. If a QName does not provide sufficient context, the <uri-specification> can be used to identify an RDF resource that describes the role in more detail. This RDF resource may be embedded in the result tree and referenced with a relative URI or fragment identifier, or the RDF resource may be external to the result tree. This specification does not define any standard QName or RDF vocabularies; these are frequently application area dependent. Other groups, for example the Dublin Core, have defined such vocabularies.

This property is not inherited, but all subsidiary nodes of this formatting object that do not bear a role property should utilize the same alternate presentation properties. (It is not inherited because knowledge of the start and end of the formatting object subtree generated by the element may be needed by the renderer.)

XSL modifications to the CSS definition:

See definition of property left ().

XSL modifications to the CSS definition:

See definition of property left ().

XSL modifications to the CSS definition:

See definition of property left ().

XSL modifications to the CSS definition:

These properties set the position of the content-rectangle of the associated area.

If both "left" and "right" have a value other than "auto", then if the "width" is "auto" the width of the content-rectangle is overridden; else the geometry is overconstrained and is resolved in accordance with . Similarly, if both "top" and "bottom" have a value other than "auto", then if the "height" is "auto" the height of the content-rectangle is overridden; else the geometry is overconstrained and is resolved in accordance with .

XSL modifications to the CSS definition:

The <uri> value has been changed to a <uri-specification>.

XSL modifications to the CSS definition:

The <uri> value has been changed to a <uri-specification>.

XSL modifications to the CSS definition:

The <uri> value has been changed to a <uri-specification>.

XSL modifications to the CSS definition:

The last paragraph in the CSS description does not apply.