Extensible Stylesheet Language (XSL) Version 1.1

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.

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.

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.

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.

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.

Issue (id-on-area):

The processing of the "id" trait of the formatting objects into traits on the generated areas needs to be extended. One proposal is:

Each area has an id trait which holds a list of IDs. This list is composed of the value of the id trait on the formatting object that generated the area and the values of the id traits on all the ancestors (in the refined formatting object tree) of that generating formatting object

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.

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.

• In the pre-order traversal order of a tree, the children of each node (their order unchanged relative to one another) follow the node, but precede any following siblings of the node or of its ancestors.

• In the post-order traversal order of a tree, the children of each node precede the node, but follow any preceding siblings of the node or of its ancestors.

"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.

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.

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.

• If the display-align value is "after" or "center" and P is the first normal area generated by the formatting object, then the space-before of the first normal child of P is subject to overconstrainment relaxing.

• If the display-align value is "before" or "center" and P is the last normal area generated by the formatting object, then the space-after of the last normal child of P is subject to overconstrainment relaxing.

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:

1. zero;

2. if the parent of B is not a reference area: the start-intrusion-adjustment of the parent of B; and

3. if B has intrusion-displace="block", then for each area A of class xsl-side-float with float="start" such that the generating formatting object of A is not a descendant of the generating formatting object of B, and such that A encroaches upon some line-area child of B: the start-encroachment of A on B; and

4. if B has intrusion-displace = "block", then for each area A of class xsl-side-float with float="start" such that A and B are inline-overlapping, and for each block-area ancestor B' of B which is a descendant of the nearest reference area ancestor of B, such that A encroaches on a line-area child of B': the start-encroachment of A on B'.

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:

1. the start-intrusion-adjustment of the parent of L;

2. for each area A of class xsl-side-float with float="start" such that A encroaches upon L: the start-encroachment of A on L; and

3. if the parent of L has intrusion-displace = "indent", then for each area A of class xsl-side-float with float="start" such that A and L are inline-overlapping, and for each block-area ancestor B' of L which is a descendant of the nearest reference area ancestor of L, such that A encroaches on some line-area child L' of B': the start-encroachment of A on B'.

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:

1. zero;

2. if the parent of B is not a reference area: the end-intrusion-adjustment of the parent of B; and

3. if B has intrusion-displace="block", then for each area A of class xsl-side-float with float="end" such that the generating formatting object of A is not a descendant of the generating formatting object of B, and such that A encroaches upon some line-area child of B: the end-encroachment of A on B; and

4. if B has intrusion-displace = "block", then for each area A of class xsl-side-float with float="end" such that A and B are inline-overlapping, and for each block-area ancestor B' of B which is a descendant of the nearest reference area ancestor of B, such that A encroaches on a line-area child of B': the end-encroachment of A on B'.

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:

1. the end-intrusion-adjustment of the parent of L;

2. for each area A of class xsl-side-float with float="end" such that A encroaches upon L: the end-encroachment of A on L; and

3. if the parent of L has intrusion-displace = "indent", then for each area A of class xsl-side-float with float="end" such that A and L are inline-overlapping, and for each block-area ancestor B' of L which is a descendant of the nearest reference area ancestor of L, such that A encroaches on some line-area child L' of B': the end-encroachment of A on B'.

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.

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:

1. Each subset consists of a sequence of inline-areas, or of a single block-area.

2. The ordering of the partition follows the ordering of the formatting object tree. Specifically, if A is in S_i and B is in S_j with i < j, or if A and B are both in the same subset S_i with A before B in the subset order, then either A is returned by a preceding sibling formatting object of B, or A and B are returned by the same formatting object with A being returned before B.

3. The partitioning occurs at legal line-breaks. Specifically, if A is the last area of S_i and B is the first area of S_i+1, then the rules of the language and script in effect must permit a line-break between A and B, within the context of all areas in S_i and S_i+1.

4. Forced line-breaks are respected. Specifically, if C is a descendant of F, and C is a fo:character whose Unicode character is U+000A, and A is the area generated by C, then either C is a child of F and A is the last area in a subset S_i, or C is a descendant of a child C' of F, and A ends (in the sense of 4.2.5) an area A' returned by C', such that A' is the last area in a subset S_i.

5. The partition follows the ordering of the area tree, except for certain glyph substitutions and deletions. Specifically, if B₁, B₂, ..., B_p are the normal child areas of the area or areas returned by F, (ordered in the pre-order traversal order of the area tree), then there is a one-to-one correspondence between these child areas and the partition subsets (i.e. n = p), and for each i,

   • S_i consists of a single block-area and B_i is that block-area, or

   • S_i consists of inline-areas and B_i is a line-area whose child areas are the same as the inline-areas in S_i, and in the same order, except that where the rules of the language and script in effect call for glyph-areas to be substituted, inserted, or deleted, then the substituted or inserted glyph-areas appear in the area tree in the corresponding place, and the deleted glyph-areas do not appear in the area tree. For example, insertions and substitutions may occur because of addition of hyphens or spelling changes due to hyphenation, or glyph image construction from syllabification, or ligature formation. Deletions occur as specified in 6, below.

6. white-space-treatment is enforced. In particular, deletions in 5 occur when there is a glyph area G such that

   (a.) the white-space-treatment of G is "ignore" and the character of G is classified as white space in XML; or

   (b.) the white-space-treatment of G is "ignore-if-before-linefeed" or "ignore-if-surrounding-linefeed", the suppress-at-line-break of G is "suppress", and G would end a line-area; or

   (c.) the white-space-treatment of G is "ignore-if-after-linefeed" or "ignore-if-surrounding-linefeed", the suppress-at-line-break of G is "suppress", and G would begin a line-area.

   In these cases the area G is deleted; this may cause the condition in clauses (b.) or (c.) to become true and lead to further deletions.

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 and normal block-areas returned by the child formatting objects, such that the following are all satisfied:

1. Each subset consists of a sequence of inline-areas, or of a single block-area.

2. The ordering of the partition follows the ordering of the formatting object tree, as defined above.

3. The partitioning occurs at legal line-breaks, as defined above.

4. Forced line-breaks are respected, as defined above.

5. The partition follows the ordering of the area tree, except for certain glyph substitutions and deletions, as defined above.

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.

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):

1. If the tree-construction process placed the property on the formatting object, use the value of that property as the specified value. This is called "explicit specification".

2. Otherwise, if the property is inheritable, use the value of that property from the parent formatting object, generally the computed value (see below).

3. Otherwise use the property's initial value, if it has one. The initial value of each property is indicated in the property's definition. If there is no initial value, that property is not specified on the formatting object. In general, this is an error.

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".

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:

• border-after-color

• border-before-color

• border-end-color

• border-start-color

• border-after-style

• border-before-style

• border-end-style

• border-start-style

• border-after-width

• border-before-width

• border-end-width

• border-start-width

• padding-after

• padding-before

• padding-end

• padding-start

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 computed value of the of the absolute "margin" property is determined by the CSS descriptions of the properties and the relevant sections (in particular section 10.3) of the CSS Recommendation referenced by these properties. 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 any of "height", "min-height", or "max-height" is specified:

  • If "height" is specified then first set:

    block-progression-dimension.minimum=<height>

    block-progression-dimension.optimum=<height>

    block-progression-dimension.maximum=<height>

  • If "height" is not specified, then first set:

    block-progression-dimension.minimum=auto

    block-progression-dimension.optimum=auto

    block-progression-dimension.maximum=auto

  • Then, if "min-height" is specified, reset:

    block-progression-dimension.minimum=<min-height>

  • Then, if "max-height" is specified, reset:

    block-progression-dimension.maximum=<max-height>

  • However, if "max-height" is specified as "none", reset:

    block-progression-dimension.maximum=auto

• If any of "width", "min-width", or "min-width" is specified:

  • If "width" is specified then first set:

    inline-progression-dimension.minimum=<width>

    inline-progression-dimension.optimum=<width>

    inline-progression-dimension.maximum=<width>

  • If "width" is not specified, then first set:

    inline-progression-dimension.minimum=auto

    inline-progression-dimension.optimum=auto

    inline-progression-dimension.maximum=auto

  • Then, if "min-width" is specified, reset:

    inline-progression-dimension.minimum=<min-width>

  • Then, if "max-width" is specified, reset:

    inline-progression-dimension.maximum=<max-width>

  • However, if "max-width" is specified as "none", reset:

    inline-progression-dimension.maximum=auto

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

• If any of "height", "min-height", or "max-height" is specified:

  • If "height" is specified then first set:

    inline-progression-dimension.minimum=<height>

    inline-progression-dimension.optimum=<height>

    inline-progression-dimension.maximum=<height>

  • If "height" is not specified, then first set:

    inline-progression-dimension.minimum=auto

    inline-progression-dimension.optimum=auto

    inline-progression-dimension.maximum=auto

  • Then, if "min-height" is specified, reset:

    inline-progression-dimension.minimum=<min-height>

  • Then, if "max-height" is specified, reset:

    inline-progression-dimension.maximum=<max-height>

  • However, if "max-height" is specified as "none", reset:

    inline-progression-dimension.maximum=auto

• If any of "width", "min-width", or "min-width" is specified:

  • If "width" is specified then first set:

    block-progression-dimension.minimum=<width>

    block-progression-dimension.optimum=<width>

    block-progression-dimension.maximum=<width>

  • If "width" is not specified, then first set:

    block-progression-dimension.minimum=auto

    block-progression-dimension.optimum=auto

    block-progression-dimension.maximum=auto

  • Then, if "min-width" is specified, reset:

    block-progression-dimension.minimum=<min-width>

  • Then, if "max-width" is specified, reset:

    block-progression-dimension.maximum=<max-width>

  • However, if "max-width" is specified as "none", reset:

    block-progression-dimension.maximum=auto

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.

These properties may set values for the space-start and space-end traits, as described in the property definitions.

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 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:

• A list of allowed resultant types for a property value.

• Conversions from resultant expression value types to an allowed type for the property.

• The current font-size value.

• Conversions from relative numerics by type to absolute numerics within additive expressions.

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.

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.

The following operators may be used with numerics:

+

Performs addition.

-

Performs subtraction or negation.

*

Performs multiplication.

div

Performs floating-point division according to IEEE 754.

mod

Returns the remainder from a truncating division.

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).

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.

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:

numeric floor(numeric)

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.

numeric ceiling(numeric)

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.

numeric round(numeric)

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.

numeric min(numeric, numeric)

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

numeric max(numeric, numeric)

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

numeric abs(numeric)

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.

color rgb(numeric, numeric, numeric)

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.

color rgb-icc(numeric, numeric, numeric, NCName, numeric, numeric)

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.

color system-color(NCName)

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

object system-font(NCName, NCName?)

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)"'.

object inherited-property-value(NCName?)

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. If the argument specifies a shorthand property and if the expression only consists of the inherited-property-value function with an argument matching the property being computed, it is interpreted as an expansion of the shorthand with each property into which the shorthand expands, each having a value of inherited-property-value with an argument matching the property. It is an error if arguments matching a shorthand property are used in any other way. Similarly, if the argument specifies a property of a compound datatype and if the expression only consists of the inherited-property-value function with an argument matching the property being computed, it is interpreted as an expansion with each component of the compound property having a value of inherited-property-value with an argument matching the component. It is an error if arguments matching a property of a compound datatype are used in any other way.

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

<fo:list-block>
  ...
  <fo:list-item color="red">
    <fo:list-item-body background-color="green">
      <fo:block background-color="inherited-property-value(color)">
      </fo:block>
    </fo:list-item-body>
  </fo:list-item>
</fo:list-block>

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".

numeric label-end()

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 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:

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:

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.

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-flow-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".

The page-viewport-areas identify one of the sides as a page binding edge. This recommendation does not specify the mechanism for selecting which side is the page binding edge.

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:

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:

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:

EMPTY

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:

EMPTY

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:

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", "only" (both first and 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:

EMPTY

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.

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.

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:

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:

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: