Extensible Stylesheet Language (XSL) Version 2.0

1.1.1 Tree Transformations

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 [XSLT]. A diagram depicting this conceptual process is shown below.

Figure 2. Transform to Another Vocabulary

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.

1.1.2 Formatting

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.

Figure 3. Build the XSL 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 5 Property Refinement / Resolution.

The refinement step is depicted in the diagram below.

Figure 4. Refine the Formatting Object Tree

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.

Figure 5. Generate the Area Tree

Figure 6. Summary of the Process

1.2.1 Paging and Scrolling

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 beyond those available in either CSS2 or DSSSL. 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 [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, were 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:

1. CSS properties by copy (unchanged from their CSS2 semantics)

2. CSS properties with extended values

3. CSS properties broken apart and/or extended

4. XSL-only properties

1.2.2 Selectors and Tree Construction

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.

1.2.3 An Extended Page Layout Model

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.

1.2.4 A Comprehensive Area Model

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 4 Area Model 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 7.2 XSL Areas and the CSS Box Model. The area model provides a vocabulary for describing the relationships and space-adjustment between letters, words, lines, and blocks.

1.2.5 Internationalization and Writing-Modes

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 7.32.7 writing-mode 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 [UNICODE Character Database] for those characters and the Unicode bidirectional (BIDI) algorithm [UNICODE UAX #9].

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.

1.2.6 Linking

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.

4.2.1 Area Types

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.

An inline-area may have one or two annotation-areas containing annotations such as ruby and emphasis dots.

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

4.2.2 Common Traits

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 7.22.3 reference-orientation. The inline-progression-direction and block-progression-direction are determined by the location of these edges as described in 7.32.7 writing-mode.

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. Only specific formatting objects generate reference areas.

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 viewport-area also has the value true for the is-reference-area trait.

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

Other traits include:

• the is-first and is-last traits, which are Boolean traits indicating the order in which areas are generated and returned (See 6.1.1 Definitions Common to Many Formatting Objects) by a given formatting object. is-first is true for the first area (or only area) generated and returned by a formatting object, and is-last is true for the last area (or only area);

• the amount of space outside the border-rectangle: space-before, space-after, space-start, and space-end (though some of these may be required to be zero on certain classes of area);

  Note:

  "Before", "after", "start", and "end" refer to relative directions and are defined below.

• the thickness of each of the four sides of the padding: padding-before, padding-after, padding-start, and padding-end;

• the style, thickness, and color of each of the four sides of the border: border-before, etc.;

• the background rendering of the area: background-color, background-image, and other background traits; and

• the nominal-font for an area, as determined by the font properties and the character descendants of the area's generating formatting object. (see 5.5.7 Font Properties)

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 4.7.2 Line-building and 4.9.4 Border, Padding, and Background.) The id trait is computed for formatting objects but is not present on areas.

4.2.3 Geometric Definitions

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.

Figure 7. Normal-allocation-rectangle of an inline-area

Figure 8. Large-allocation-rectangle of an inline-area

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.

Figure 9. Allocation- and content-rectangles of a block-area

The edges of a rectangle are designated as follows:

• the before-edge is the edge occurring first in the block-progression-direction and perpendicular to it;

• the after-edge is the edge opposite the before-edge;

• the start-edge is the edge occurring first in the inline-progression-direction and perpendicular to it,

• the end-edge is the edge opposite the start-edge.

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 areas with different writing-modes or reference-orientation.

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

Each inline-area has an alignment-point determined by the formatter, on the start-edge of its allocation-rectangle; for a glyph-area, this is a point on the start-edge of the glyph on its alignment baseline (see below). This is script-dependent and does not necessarily correspond to the (0,0) coordinate point used for the data describing the glyph shape.

4.2.4 Tree Ordering

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.

4.2.5 Stacking Constraints

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 may 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 4.3 Spaces and Conditionality), it is defined that A and B have block-stacking constraint S if any of the following conditions holds:

1. B is a block-area which is the first normal child of A, and S is the sequence consisting of the space-before of B.

2. A is a block-area which is the last normal child of B, and S is the sequence consisting of the space-after of A.

3. A and B are both block-areas, and either

   a. B is the next stackable sibling area of A, and S is the sequence consisting of the space-after of A and the space-before of B;

   b. B is the first normal child of a block-area P, B is not a line-area, there is no fence preceding P, A and P have a block-stacking constraint S', and S consists of S' followed by the space-before of B; or

   c. A is the last normal child of a block-area P, A is not a line-area, there is no fence following P, P and B have a block-stacking constraint S'', and S consists of the space-after of A followed by S''.

   d. A has a block-stacking constraint S' with a block-area E, E has a block-stacking constraint S'' with B, E is empty (i.e., it has zero border, padding, and block-progression-dimension, and no normal children), and S consists of S' followed by S''.

Figure 10. Adjacent Edges with Block-stacking

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

• In case 1, the before-edge of the content-rectangle of A and the before-edge of the allocation-rectangle of B.

• In case 2, the after-edge of the allocation-rectangle of A and the after-edge of the content-rectangle of B.

• In case 3a, the after-edge of the allocation-rectangle of A and the before-edge of the allocation-rectangle of B.

• In case 3b, the first of the adjacent edges of A and P, and the before-edge of the allocation-rectangle of B.

• In case 3c, the after-edge of the allocation-rectangle of A and the second of the adjacent edges of P and B.

• In case 3d, the first of the adjacent edges of A and E, and the second of the adjacent edges of E and B.

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

Figure 11. Block-stacking constraint example

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:

1. A is an inline-area or line-area, B is an inline-area which is the first normal child of A, and S is the sequence consisting of the space-start of B.

2. B is an inline-area or line-area, A is an inline-area which is the last normal child of B, and S is the sequence consisting of the space-end of A.

3. A and B are each either an inline-area or a line-area, and either

   a. both A and B are inline-areas, B is the next normal sibling area of A, and S is the sequence consisting of the space-end of A and the space-start of B;

   b. B is an inline-area which is the first normal child of an inline-area P, P has no fence following A, A and P have an inline-stacking constraint S', the inline-progression-direction of P is the same as the inline-progression-direction of the nearest common ancestor area of A and P, and S consists of S' followed by the space-start of B.

   c. A is an inline-area which is the last normal child of an inline-area P, P has no fence preceding B, P and B have an inline-stacking constraint S'', the inline-progression-direction of P is the same as the inline-progression-direction of the nearest common ancestor area of P and B, and S consists of the space-end of A followed by S''.

   d. B is an inline-area which is the last normal child of an inline-area P, P has no fence following A, A and P have an inline-stacking constraint S', the inline-progression-direction of P is opposite to the inline-progression-direction of the nearest common ancestor area of A and P, and S consists of S' followed by the space-end of B.

   e. A is an inline-area which is the first normal child of an inline-area P, P has no fence preceding B, P and B have an inline-stacking constraint S'', the inline-progression-direction of P is opposite to the inline-progression-direction of the nearest common ancestor area of P and B, and S consists of the space-start of A followed by S''.

Figure 12. Adjacent Edges with Inline-stacking

Figure 13. Adjacent Edges with Inline-stacking, continued

Figure 14. Mixed English and Arabic

Figure 15. Mixed English and Arabic

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

• In case 1, the start-edge of the content-rectangle of A and the start-edge of the allocation-rectangle of B.

• In case 2, the end-edge of the allocation-rectangle of A and the end-edge of the content-rectangle of B.

• In case 3a, the end-edge of the allocation-rectangle of A and the start-edge of the allocation-rectangle of B.

• In case 3b, the first of the adjacent edges of A and P, and the start-edge of the allocation-rectangle of B.

• In case 3c, the end-edge of the allocation-rectangle of A and the second of the adjacent edges of P and B.

• In case 3d, the first of the adjacent edges of A and P, and the end-edge of the allocation-rectangle of B.

• In case 3e, the start-edge of the allocation-rectangle of A and the second of the adjacent edges of P and B.

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, provided that no descendant of P which is an ancestor of A has a space-before (in the case of a block-stacking constraint) or a space-start (in the case of an inline-stacking constraint) whose computed minimum, maximum, or optimum values are nonzero. 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, provided that no descendant of P which is an ancestor of A has a space-after (in the case of a block-stacking constraint) or a space-end (in the case of an inline-stacking constraint) whose computed minimum, maximum, or optimum values are nonzero. 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.

4.3.1 Space-resolution Rules

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 4.2.5 Stacking Constraints). Define S' to be a subsequence of S'' as follows:

• if S is the space-before or space-after of a line-area, then S' is the maximal subsequence of S'' containing S such that all the space-specifiers in S' are traits of line-areas,

• if S is the space-before or space-after of a block-area which is not a line-area, then S' is the maximal subsequence of S'' containing S such that all the space-specifiers in S' are traits of block-areas which are not line-areas,

• if S is the space-start or space-end of an inline-area, then S' is all of S''.

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

1. If any of the space-specifiers in S' is conditional, and begins a reference-area or line-area, then it is suppressed, which means that its resolved space-specifier is zero. Further, any conditional space-specifiers which consecutively follow it in the sequence are also suppressed. For purposes of this rule, a space-specifier U consecutively follows a space-specifier V if it U follows V and U and V are separated in the sequence only by conditional space-specifiers and/or space-specifiers whose computed minimum, maximum, and optimum values are zero.

   If a conditional space-specifier ends a reference-area or line-area, then it is suppressed together with any other conditional space-specifiers which consecutively precede it in the sequence. For purposes of this rule, a space-specifier U consecutively precedes a space-specifier V if it U precedes V and U and V are separated in the sequence only by conditional space-specifiers and/or space-specifiers whose computed minimum, maximum, and optimum values are zero.

2. If any of the remaining space-specifiers in S' is forcing, all non-forcing space-specifiers are suppressed, and the value of each of the forcing space-specifiers is taken as its resolved value.

3. Alternatively if all of the remaining space-specifiers in S' are non-forcing, then the resolved space-specifier is defined in terms of those non-suppressed space-specifiers whose precedence is numerically highest, and among these those whose optimum value is the greatest. All other space-specifiers are suppressed. If there is only one of these then its value is taken as its resolved value.

   Otherwise, follow these rules when there are two or more space-specifiers all of the same highest precedence and the same (largest) optimum: The resolved space-specifier of the last space-specifier in the sequence is derived from these spaces by taking their common optimum value as its optimum. The greatest of their minimum values is its minimum. The least of their maximum values is its maximum. All other space-specifiers are suppressed.

4. If S is subject to overconstrainment relaxing, then its maximum value is set to the actual block-progression-dimension of the containing block-area. See 4.3.2 Overconstrained space-specifiers

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.

4.3.2 Overconstrained space-specifiers

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.

4.4.1 Stacked Block-areas

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:

1. For each block-area B which is a descendant of P, the following hold:

   • the before-edge and after-edge of its allocation-rectangle are parallel to the before-edge and after-edges of the content-rectangle of P,

   • the start-edge of its allocation-rectangle is parallel to the start-edge of the content-rectangle of R (where R is the closest ancestor reference-area of B), and offset from it inward by a distance equal to the block-area's start-indent plus its start-intrusion-adjustment (as defined below), minus its border-start, padding-start, and space-start values, and

   • the end-edge of its allocation-rectangle is parallel to the end-edge of the content-rectangle of R, and offset from it inward by a distance equal to the block-area's end-indent plus its end-intrusion-adjustment (as defined below), minus its border-end, padding-end, and space-end values.

   

   Figure 16. Content Rectangle of Reference Area

   Note:

   The notion of indent is intended to apply to the content-rectangle, but the constraint is written in terms of the allocation-rectangle, because as noted earlier (4.2.3 Geometric Definitions) the edges of the content-rectangle may not correspond to like-named edges of the allocation-rectangle.

   The start-intrusion-adjustment and end-intrusion-adjustment are traits used to deal with intrusions from floats in the inline-progression-direction.

   See also section 5.3.2 Margin, Space, and Indent Properties for how the margin properties affect the indents.

2. For each pair of normal areas B and B' in the subtree below P, if B and B' have a block-stacking constraint S and B is not empty (see 4.2.5 Stacking Constraints), then the distance between the adjacent edges of B and B' is consistent with the constraint imposed by the resolved values of the space-specifiers in S.

   

   Example. In the diagram, if area A has a space-after value of 3 points, B a space-before of 1 point, and C a space-before of 2 points, all with precedence of force, and with zero border and padding, then the constraints will place B's allocation-rectangle 4 points below that of A, and C's allocation-rectangle 6 points below that of A. Thus the 4-point gap receives the background color from P, and the 2-point gap before C receives the background color from B.

4.4.2 Positioning in the block-progression direction

A general comment: positioning (and justification) is connected to regions and columns, and the interaction between them, and that work is not yet complete. In addition, the term vertical in this section should be taken to mean the block-progression direction.

4.4.3 Intrusion Adjustments

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

4.6.1 Stacked Inline-areas

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 (4.6.3 Font Baseline Tables).

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

1. For each inline-area descendant I of P, the start-edge, end-edge, before-edge and after-edge of the allocation-rectangle of I are parallel to corresponding edges of the content-rectangle of the nearest ancestor reference-area of I.

2. For each pair of normal areas I and I' in the subtree below P, if I and I' have an inline-stacking constraint S, then the distance between the adjacent edges of I and I' is consistent with the constraint imposed by the resolved values of the space-specifiers in S.

3. For any inline-area descendant I of P, the distance in the shift-direction from the dominant baseline of the parent Q of I, to the alignment-point of I equals the offset between the dominant baseline of Q and the baseline of Q corresponding to the alignment-baseline trait of I, plus the baseline-shift for I.

   The first summand is computed to compensate for mixed writing systems with different baseline types, and the other summands involve deliberate baseline shifts for things like superscripts and subscripts.

4.6.2 Glyph-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.

4.6.3 Font Baseline Tables

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 5.5.8 Fonts and Font Data.

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

4.7.1 General Ordering Constraints

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.

4.7.2 Line-building

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 (and any associated annotation-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, script and hyphenation constraints (7.10 Common Hyphenation Properties, 7.17.1 hyphenation-keep, and 7.17.2 hyphenation-ladder-count) 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 an 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).

4.7.3 Inline-building

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 and/or annotation-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.

4.9.1 Geometry

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 4.9.2 Viewport Geometry.

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 4.9.2 Viewport Geometry.

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.

4.9.2 Viewport Geometry

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.

4.9.3 Visibility

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.

4.9.4 Border, Padding, and Background

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.

4.9.5 Intrinsic Marks

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.

4.9.6 Layering and Conflict of Marks

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.

4.11.1 Summary

Allowing copyfitting on fo:region, fo:region-* objects, fo:block-container and fo:table-cell.

Adding a new value ("justify") for the property "display-align" (already in XSL-FO) to activate copyfitting. Though the same property is used for vertical justification, users can exploit the property "force-page-count" (along with a correct definition of page-masters and page-sequences) to avoid conflicts.

Introducing the concept of “list of prioritized adjustable properties”. An adjustable property is an existing XSL-FO property that can be modified in order to do copyfitting or vertical justification.

Exploiting range values of existing properties to specify how (and how much) each property can be adjusted. Introducing the idea of "elasticity".

Adding a new property "adjustable-properties" that specifies such lists.

Adding new values to the property "force-page-count" to model copyfit into a fixed number of pages or a multiple of a number.

Adding a new formatting object fo:alternative-copyfit-content to express alternative content for copyfitting

4.11.2 Copyfit: basic approach and definitions

Many options exist to copyfit content to a certain area. For example, a user could add some space between paragraphs, widen or narrow spaces before and after titles, images and tables, modify the line height of some paragraphs, etc. All these fine tunings, and their multiplicity of combinations, lead to different results, and different users could have different preferences.

Thus, copyfitting actually requires two logically separated tasks: (1) the request of copyfitting to a given area, and (2) the definition of strategies to copyfit.

Copyfitting is enabled by setting the property display-align to the value "justify". Copyfitting strategies are then expressed through "adjustable properties lists" using the. adjustable-properties property.

Although the same approach is used for vertical justification, users can exploit the property force-page-count and/or the definition of page-masters and page-sequences to avoid conflicts.

The display-align property applies to fo:region, fo:region-*, fo:block-container and fo:table-cell. It is then possible to copyfit content in a block-container or in a table cell, and also to copyfit the content of one flow to a single region, multiple flows to a single region or even multiple flows to multiple regions.

A display-align-last property is also added, to specify different treatment of the last page in a copyfitted seqence, by analogy with text-align and text-align-last.

4.11.3 Copyfit Examples

Let us first consider two flows A and B that go into two distinct regions R1 and R2, as defined in the following XSL-FO excerpt:

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:page-master master-name="sample1" 
     page-height="11in" page-width="8.5in" margin-top="3pt"
     margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
  <fo:region  region-name="R1" 
     display-align="justify" 
     adjustable-properties="line-height"/> 
  <fo:region  region-name="R2" 
     display-align="before"/> 
</fo:page-master>

<fo:flow-map flow-map-name="M1">
  <fo:flow-assignment>
    <fo:flow-source-list>
       <fo:flow-name-specifier flow-name-reference="A"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
     <fo:region-name-specifier region-name-reference="R1"/>
    </fo:flow-target-list>
   </fo:flow-assignment>
   <fo:flow-assignment>
    <fo:flow-source-list>
     <fo:flow-name-specifier flow-name-reference="B"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
     <fo:region-name-specifier region-name-reference="R2"/>
    </fo:flow-target-list>
    </fo:flow-assignment>
 </fo:flow-map>

<fo:page-sequence force-page-count="1" flow-map-reference="M1">
  <fo:flow flow-name="A">
   <fo:block> Lorem maecenas blandit ac, neque sed ut pulvinar,
   lectus sagittis sapien per risus vel.  Ligula sapien sed morbi cras
   tellus commodo. Si qua ex docet dei etris crucis</fo:block>
  <fo:block> curabitur magna nisi, faucibus sed ornare sed,
  congue eu dui.  Pellentesque habitant morbi tristique senectus et
  netus et malessecularia uada fames ac turpis
  egestas. </fo:block>
  <fo:block> Nunc sit amet dolor sed sem congue mattis sed ut
  arcu. Mauris id magna sit amet elit aliquam.</fo:block>
  <fo:block>Pellentesque habitant morbi tristique senectus et
  netus et malesuada fames.</fo:block>
 </fo:flow>

 <fo:flow flow-name="B">
  <fo:block>Crucis rosa ut hoc sien qua non res veni.</fo:block>
  <fo:block> Etiam tristique, nulla a pulvinar hendrerit nihil
  tortor urna auctor etim domine secularia cali sed ut quotie ire in
  domince hoc fantus quis eius rei rei.  </fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>

The property display-align is added to the element "fo:region" to activate copyfit for region R1. No copyfit is activated on region R2 since the property display-align has value "before". Note also that the property force-page-count of the element "fo:page-sequence" states that the overall content has to be copyfitted in one page. Finally, the property adjustable-properties lists those XSL-FO properties that can be modified to copyfit text.

The expected result is shown below:

Figure 19. Expected result of copyfit example.

The same flows and regions are expected to produce a different output, when the flow-map M2 is used instead:

<fo:flow-map flow-map-name="M2">
<fo:flow-assignment>
<fo:flow-source-list>
<fo:flow-name-specifier flow-name-reference="A"/>
<fo:flow-name-specifier flow-name-reference="B"/>
</fo:flow-source-list>
<fo:flow-target-list>
<fo:region-name-specifier region-name-reference="R1"/>
<fo:region-name-specifier region-name-reference="R2"/>
</fo:flow-target-list>
</fo:flow-assignment>
</fo:flow-map>

In this case, the two flows go into region R1 and then region R2. If the properties display-align does not change, the expected result is the following:

Figure 20. Expected result of copyfit example with display-align = before.

The expected result is different when either the property "display-align" of region R2 is set to "justify":

<fo:page-master master-name="sample1" 
   page-height="11in" page-width="8.5in" margin-top="3pt"
   margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
  <fo:region  region-name="R1" 
     display-align="justify" 
     adjustable-properties="line-height"/> 
    <fo:region  region-name="R2" 
      display-align="justify"/>
  </fo:page-master>

In fact, both the regions end up being copyfitted as shown below:

Figure 21. Expected result of copyfit example with display-align = justify.

When the formatter is expected to produce as many pages as needed (for instance, by setting the property force-page-count to "no-force"), the property display-align is used to activate vertical justification. The property display-align-last is then used to set the vertical alignment of the last page.

Let us consider the following example, where only one region R1 and one flow A are declared:

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
 <fo:page-master master-name="sample1" 
    page-height="11in" page-width="8.5in" margin-top="3pt"
   margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
  <fo:region-body region-name="xsl-region-body" 
    display-align="justify" 
    display-align-last="relative"
    adjustable-properties="..."/>
</fo:page-master>

<fo:page-sequence>
  <fo:flow flow-name="A">

<fo:block>Lorem ipsum dolor sit amet, nunc euismod nisl nam euismod, quis maecenas
blandit ac, neque sed ut pulvinar, lectus sagittis ... quorneque tortor
neque, commodo mauris sagittis yurpis,hic fecit leuc em.</fo:block>

<fo:block>Lorem ipsum dolor sit amet, nunc ... lectus sagittis sapien
mauris per risus.</fo:block>

<fo:block>Ligula sapien sed morbi cras tellus ... quoque
cra ut sic fecit quorem deis hoc hac lorem ipse die cruci faucibus sed ultrices
tempor inter dum.</fo:block>
<fo:block>Lorem ipsum dolor sit amet, .... Rutrum mattis accumsan.</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>

The values of the properties display-align and display-align-last of the element "fo:region-body" require the formatter to produce the following output:

Figure 22. Three pages of text; the first two are full, and the third is partially filled.

By setting the property display-align-last to "justify", the last page is also vertically justified:

Figure 23. showing last page justification

Note also that this case can be easily generalized for the case of multiple flows going into the same region.

The formatter is expected to copyfit text in a given number of pages when the property force-page-count is set to an integer value. Consider for instance the previous declaration of "fo:region-body" changed into:

<fo:region-body region-name="xsl-region-body" 
display-align="justify" 
display-align-last="justify"
 force-page-count="2"
adjustable-properties="..."/>

The formatter is now expected to produce the following result:

Figure 24. Showing a fixed number of pages (2 in the example)

The last page is vertically justified since the property display-align-last is set to "justify". By changing that property, user can obtain the same number of pages without imposing the last one to be completely filled.

Figure 25. A more complex example, summarizing multiple cases:

4.11.4 Content Adjusting Strategies

XSL-FO provides a general mechanism to express strategies for copyfitting or vertical justification. The overall approach is flexible and independent on the formatting task and may be applied to other contexts in the future.

An "adjustable properties list" is an ordered sequence of properties names (or group of names) that a formatter is allowed to modify to format the content. In fact, such lists are used to drive copyfitting, vertical justification and feathering. The order of the names in the list follows the priority rules described below.

Adjustable properties lists can be associated with fo:objects using the property adjustable-properties.

It is important to note that the “adjustable-properties list” only states the strategy to format the content and does not define the actual property ranges the application is allowed to modify. These are instead expressed (as in an XSL-FO 1.1 document) throughout the flow and its descendant formatting objects: this provides a great expressing power in a simple way, as, for example, it allows for different fo:block elements to have different adjusting properties.

For example: adjustable-properties=”space-before word-spacing” means that the application is allowed to modify the actual value of the space-before and word-spacing properties. Although the “adjustable-properties” property is defined in the fo:flow-assignment object, the variations are defined in the “space-before” and “word-spacing” properties of the blocks within the actual flow. In most cases values of these properties are actually inherithed. The application should try to adjust the text by choosing appropriate values for the space-before traits (using a value either greater or smaller that the .optimum one but still between the relevant .minimum and .maximum) of each block.

In fact, many FO properties (dating back to the initial XSL-FO specification) can be given a length range value, expressed using a .minimum, .optimum and .maximum components; others (allowed-height-scale, allowed-width-scale) can be given a list of numeric values; font-family can be given a list of values.

A property having a range value can create some elasticity: the dimensions of the areas generated by the affected formatting objects can stretch or shrink from an optimal value. An FO subtree is said to have inline elasticity if there are properties involved in the line building process that have some degree of elasticity; similarly, an FO subtree is said to have block elasticity if there are properties involved in the block stacking process that have some degree of elasticity. It should be noted that a length range in an inline-related property can involve both inline and block elasticity (as, for example, a variation in word-spacing may result in the creation of fewer or more lines), while a range in a block-related property only creates block elasticity.

The presence of some elasticity is the first condition to adjust content (for copyfitting or vertical justification). Properties with range or list values, in fact, can be adjusted in order to achieve the expected result.

On the other hand, elasticity does not automatically imply that content will be formatted as expected. It may happen that properties listed in “adjustable properties list” do not have elasticity while other do. In that case the formatter cannot achieve the expected result and should warn the user.

If properties listed in the “adjustable properties list” do have elasiticy but the formatter is not able to achieve the expected result – because of syntax errors, limitated support of required strategies, etc. – the formatter should warn the user too.

An example of copyfit declaration and application is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <fo:page-master master-name="sample1" page-height="11in" 
        page-width="8.5in" margin-top="3pt"
	margin-bottom="3pt" margin-left="3pt" margin-right="3pt">
   <fo:region  region-name="R1" 
       display-align="justify" 
       adjustable-properties="line-height"/> 
   <fo:region  region-name="R2" 
       display-align="before"/> 
</fo:page-master>

<fo:flow-map flow-map-name="M1">
  <fo:flow-assignment>
    <fo:flow-source-list>
     <fo:flow-name-specifier flow-name-reference="A"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
     <fo:region-name-specifier region-name-reference="R1"/>
    </fo:flow-target-list>
  </fo:flow-assignment>

  <fo:flow-assignment>
   <fo:flow-source-list>
    <fo:flow-name-specifier flow-name-reference="B"/>
   </fo:flow-source-list>
   <fo:flow-target-list>
     <fo:region-name-specifier region-name-reference="R2"/>
   </fo:flow-target-list>
  </fo:flow-assignment>
</fo:flow-map>

<fo:page-sequence force-page-count="1" flow-map-reference="M1">
  <fo:flow flow-name="A">
 
  <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt"
  line-height.minimum="8pt" line-height.maximum="14pt"> Lorem
  maecenas blandit ac, neque sed ut pulvinar, lectus sagittis sapien
  per risus vel.  Ligula sapien sed morbi cras tellus commodo.  Si qua
  ex docet dei etris crucis</fo:block>

  <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt"
  line-height.minimum="8pt" line-height.maximum="14pt"> curabitur
  magna nis, faucibus sed ornare sed, congue eu dui.  Pellentesque
  habitant morbi tristique senectus et netus et malessecularia uada
  fames ac turpis egestas. </fo:block>

  <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt"
  line-height.minimum="8pt" line-height.maximum="14pt"> Nunc sit
  amet dolor sed sem congue mattis sed ut arcu. Mauris id magna sit
  amet elit aliquam.</fo:block> <fo:block>Pellentesque
  habitant morbi tristique senectus et netus et malesuada
  fames.</fo:block>

  </fo:flow>
  <fo:flow flow-name="B">

  <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt"
  line-height.minimum="8pt" line-height.maximum="14pt">Crucis rosa
  ut hoc sien qua non res veni.</fo:block>

  <fo:block word-spacing.minimum="1pt" word-spacing.maximum="4pt"
  line-height.minimum="8pt" line-height.maximum="14pt"> Etiam
  tristique, nulla a pulvinar hendrerit nihil tortor urna auctor etim
  domine secularia cali sed ut quotie ire in domince hoc fantus quis
  eius rei rei.  </fo:block>

</fo:flow>
</fo:page-sequence>
</fo:root>

The two regions R1 and R2 use different strategies to copyfit. Flow A is copyfitted into region R1 by only adjusting the word-space of each block (that will be a value between 1pt and 4pt), while flow B is copyfitted into region R2 by adjusting line-height of each block (that will be a value between 8pt and 14pt).

Notice again that the declaration of the strategies for copyfitting is completely disconnected from the declaration of the copyfit itself.

5.1.1 Specified Values

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 a parent formatting object; in this case, the initial value is used if necessary.

5.1.2 Computed Values

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 5.3 Computing the Values of Corresponding Properties.

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.

5.1.3 Actual Values

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.

5.1.4 Inheritance

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.

5.3.1 Border and Padding Properties

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

5.3.2 Margin, Space, and Indent Properties

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

5.3.3 Height, and Width Properties

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

5.3.4 Overconstrained Geometry

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.

5.4.1 Background-position-horizontal and background-position-vertical Properties

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

5.4.2 Column-number Property

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.

5.4.3 Text-align Property

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

5.4.4 Text-align-last Property

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

5.4.5 z-index Property

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.

5.4.6 Language Property

A value being a 2-letter code in conformance with [ISO639] is converted to the corresponding 3-letter [ISO639-2] terminology code, a 3-letter code in conformance with [ISO639-2] bibliographic code is converted to the corresponding 3-letter terminology code, a value of 'none' or 'mul' is converted to 'und'.

5.5.1 Word spacing and Letter spacing Properties

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

5.5.2 Reference-orientation Property

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

5.5.3 Writing-mode and Direction Properties

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 4.2.2 Common Traits.

5.5.4 Absolute-position Property

If absolute-position has the value "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.

5.5.5 Relative-position Property

If relative-position has the value "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.

5.5.6 Text-decoration Property

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.

5.5.7 Font Properties

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 5.5.8 Fonts and Font Data.

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 7.9.2 font-selection-strategy).

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.

5.5.8 Fonts and Font Data

Fonts and Font Data

XSL uses an abstract model of a font. This model is described in this section and is based on current font technology as exemplified by the OpenType specification [OpenType].

A font consists of a collection of glyphs together with the information, the font tables, necessary to use those glyphs to present characters on some medium. A glyph is a recognizable abstract graphic symbol which is independent of any specific design. The combination of the collection of glyphs and the font tables is called the font data.

The font tables include the information necessary to map characters to glyphs, to determine the size of glyph areas and to position the glyph area. Each font table consists of one or more font characteristics, such as the font-weight and font-style.

The geometric font characteristics are expressed in a coordinate system based on the em box. (The em is a relative measure of the height of the glyphs in the font; see 5.11.7.2 Relative Lengths.) This box that is 1 em high and 1 em wide is called the design space. Points in this design space are expressed in geometric coordinates in terms of fractional units of the em.

The coordinate space of the em box is called the design space coordinate system. For scalable fonts, the curves and lines that are used to draw a glyph are represented using this coordinate system.

XSL assumes that the font tables will provide at least three font characteristics: an ascent, a descent and a set of baseline-tables. The coordinate values for these are given in the design space coordinate system. The ascent is given by the vertical coordinate of the top of the em box; the descent is given by the vertical coordinate of the bottom of the em box. The baseline-table is explained below.

The glyphs of a given script are positioned so that a particular point on each glyph, the alignment-point, is aligned with the alignment-points of the other glyphs in that script. The glyphs of different scripts are typically aligned at different points on the glyph. For example, Western glyphs are aligned on the bottoms of the capital letters, certain Indic glyphs (including glyphs from the Devanagari, Gurmukhi and Bengali scripts) are aligned at the top of a horizontal stroke near the top of the glyphs and Far Eastern glyphs are aligned either at the bottom or center of the em box of the glyph. Within a script and within a line of text having a single font-size, the sequence of alignment-points defines, in the inline-progression-direction, a geometric line called a baseline. Western and most other alphabetic and syllabic glyphs are aligned to an "alphabetic" baseline, the above Indic glyphs are aligned to a "hanging" baseline and the Far Eastern glyphs are aligned to an "ideographic" baseline.

Figure 26. This figure shows the vertical position of the alignment-point for alphabetic and many syllabic scripts, illustrated by a Roman "A"; for certain Indic scripts, illustrated by a Gurmukhi syllable "ji"; and for ideographic scripts, illustrated by the ideograhic glyph meaning "country". The thin black rectangle around the ideographic glyph illustrates the em box for that glyph and shows the typical positioning of the "black marks" of the glyph within the em box.

A baseline-table specifies the position of one or more baselines in the design space coordinate system. The function of the baseline table is to facilitate the alignment of different scripts with respect to each other when they are mixed on the same text line. Because the desired relative alignments may depend on which script is dominant in a line (or block), there may be a different baseline table for each script. In addition, different alignment positions are needed for horizontal and vertical writing modes. Therefore, the font may have a set of baseline tables: typically, one or more for horizontal writing-modes and zero or more for vertical writing-modes.

Figure 27. Examples of horizontal and vertical baseline positions. The thin lined box in each example is the "em box". For the Latin glyphs, only the em box of the first glyph is shown. Example 1 shows typical Latin text written horizontally. This text is positioned relative to the alphabetic baseline, shown in blue. Example 2 shows a typical ideographic glyph positioned on the horizontal ideographic baseline. Note that the em box is positioned differently for these two cases. Examples 3 and 4 show the same set of baselines used in vertical writing. The Latin text, example 3, is shown with a glyph-orientation of 90 degrees which is typical for proportionally space Latin glyphs in vertical writing. Even though the ideographic glyph in example 4 is positioned on the vertical ideographic baseline, because it is centered in the em box, all glyphs with the same em box are centered, vertically, with respect to one another. Additional examples showing the positioning of mixed scripts are given in the introductions to 7.15 Area Alignment Properties and 7.32 Writing-mode-related Properties.

The font tables for a font include font characteristics for the individual glyphs in the font. XSL assumes that the font tables include, for each glyph in the font, one width value, one alignment-baseline and one alignment-point for the horizontal writing-modes. If vertical writing-modes are supported, then each glyph must have another width value, alignment-baseline and alignment-point for the vertical writing-modes. (Even though it is specified as a width, for vertical writing-modes the width is used in the vertical direction.)

The script to which a glyph belongs determines an alignment-baseline to which the glyph is to be aligned. The position of this baseline in the design space coordinate system determines the default block-progression-direction position of the alignment-point. The inline-progression-direction position of the alignment-point is on the start-edge of the glyph. (These positions are adjusted according to the specifications in 7.15.1 alignment-adjust when an instance of a glyph is used in an inline or block formatting object. The "space-start" and/or the "space-end" properties of the fo:character that maps to the glyph may be adjusted to effect "kerning" with respect to adjacent glyphs.)

Figure 28. This figure shows glyphs from three different scripts, each with its em box and within the em box, the baseline table applicable to that glyph. The alignment-point of each glyph is shown by an "X" on the start edge of the em box and by making alignment-baseline blue. The baseline-table of the parent formatting object of the characters that mapped to these glyphs is shown as a set of dashed lines.

In addition to the font characteristics required above, a font may also supply substitution and positioning tables that can be used by a formatter to re-order, combine, and position a sequence of glyphs to make one or more composite glyphs. The combination may be as simple as a ligature, or as complex as an Indic syllable which combines, usually with some re-ordering, multiple consonants and vowel glyphs. See 4.7.2 Line-building.

5.7.1 Text-transform Property

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

5.9.1 Block and Line-related Properties for Ruby

The line-stacking-annotation is used to determine the line stacking method for block elements containing annotation areas such as from ruby or emphasis dots.

5.11.1 Property Context

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.

All property contexts allow conversions as specified in 5.11.12 Expression Value Conversions.

5.11.2 Evaluation Order

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.

5.11.3 Basics

5.11.4 Function Calls

5.11.5 Numerics

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 [IEEE 754]. These include a special "Not-a-Number" (NaN) value, positive and negative infinity, and positive and negative zero. See Section 4.2.3 of [JLS] for a summary of the key rules of the IEEE 754 standard.

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.

Numeric Expressions

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.

5.11.6 Absolute Numerics

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.

5.11.7 Relative Numerics

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

5.11.8 Strings

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

5.11.9 Colors

A color is a set of values used to identify a particular color from a color space. Only RGB [sRGB] (Red, Green, Blue) and ICC (International Color Consortium) [ICC] 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.

5.11.10 Keywords

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.

5.11.11 Lexical Structure

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:

• If the character following an NCName (possibly after intervening ExprWhitespace) is "(", then the token must be recognized as FunctionName.

• A number terminates at the first occurrence of a non-digit character other than ".". This allows the unit token for length quantities to parse properly.

• When an NCName immediately follows a Number, it should be recognized as a UnitName or it is an error.

• The Keyword values take precedence over EnumerationToken.

• If a NCName follows a numeric, it should be recognized as an OperatorName or it is an error.

Expression Lexical Structure

5.11.12 Expression Value Conversions

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.

5.11.13 Definitions of Units of Measure

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

5.12.1 Number Functions

number floor(number)

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

number ceiling(number)

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

number round(number)

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.

number min(number, number)

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

number max(number, number)

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

number abs(number)

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.

5.12.2 Color Functions

color rgb(number, number, number)

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(number, number, number, NCName, number, number)

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 color value (real number) specified after the name parameter. These values are specific to the color profile.

color icc-named-color(number, number, number, NCName, string)

The icc-named-color function returns a specific named 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 color is specified by the last parameter.

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

color system-color(NCName)

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

color cmyk-icc-color(number, number, number, NCName, number, number, number, number)

The cmyk-icc-color 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 four color values (real numbers) specified after the name parameter.

color cie-lab-color(number, number, number, number, number, number, number)

The cie-lch-color function returns a specific color from the cartesian form of the CIE Lab [CIE15] color space. The 'Lightness', 'a', and 'b' values are specified by the fourth to sixth parameters, respectively.

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

color cie-lch-color(number, number, number, number, number, number, number)

The cie-lab-color function returns a specific color from the cylindrical form of the CIELUV [CIE15] color space. The 'Lightness', 'Hue', and 'Chroma' values are specified by the fourth to sixth parameters, respectively.

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

5.12.3 Font Functions

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

5.12.4 Property Value Functions

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. For example, given the following:

<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 the fo:block is "red".

number label-end()

The label-end function returns the calculated label-end value for lists. See the definition in 7.33.12 provisional-label-separation.

number body-start()

The body-start function returns the calculated body-start value for lists. See the definition in 7.33.11 provisional-distance-between-starts.

object from-parent(NCName?)

The from-parent function returns a computed value (see 5.1 Specified, Computed, and Actual Values, and Inheritance) of the property whose name matches the argument specified, or if omitted for the property for which the expression is being evaluated. The value returned is that for the parent of the formatting object for which the expression is evaluated. If there is no parent, the value returned is the initial value. If the argument specifies a shorthand property and if the expression only consists of the from-parent 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 from-parent 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 from-parent 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 from-parent 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.

object from-nearest-specified-value(NCName?)

The from-nearest-specified-value function returns a computed value of the property whose name matches the argument specified, or if omitted for the property for which the expression is being evaluated. The value returned is that for the closest ancestor of the formatting object for which the expression is evaluated on which there is an assignment of the property in the XML result tree in the fo namespace. If there is no such ancestor, the value returned is the initial value. If the argument specifies a shorthand property and if the expression only consists of the from-nearest-specified-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 from-nearest-specified-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 from-nearest-specified-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 from-nearest-specified-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.

object from-page-master-region(NCName?)

The from-page-master-region function returns the computed value of the property whose name matches the argument specified, or if omitted for the property for which the expression is being evaluated.

In XSL-FO this function may only be used as the value of the "writing-mode" and "reference-orientation" properties. In addition the argument of the function must be omitted. If an argument is present, it is an error.

The computed value of the designated property is taken from that property on the layout formatting object being used to generate the region viewport/reference area pair.

If this function is used in an expression on a formatting object, F, that is a descendant of an fo:page-sequence, then the computed value is taken from the region specification that was used to generate the nearest ancestor region reference area which has as its descendants the areas returned by F.

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.

<fo:root>

<fo:layout-master-set>
  <fo:simple-page-master master-name="all-pages">
    <fo:region-body region-name="xsl-region-body" margin="0.75in"
                    writing-mode="tb-rl" />
    <fo:region-before region-name="xsl-region-before" extent="0.75in"/>
  </fo:simple-page-master>
  <fo:page-sequence-master master-name="default-sequence">
    <fo:repeatable-page-master-reference master-reference="all-pages"/>
  </fo:page-sequence-master>
</fo:layout-master-set>

<fo:page-sequence master-name="default-sequence">
  <fo:flow flow-name="xsl-region-body">
    <fo:block>
        [Content in a language which allows either
         horizontal or vertical formatting]
    </fo:block>
  </fo:flow>
</fo:page-sequence>

</fo:root>

<fo:page-sequence master-name="default-sequence">

<fo:page-sequence master-name="default-sequence"
                  writing-mode="from-page-master-region()">

object from-table-column(NCName?)

The from-table-column 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, from the fo:table-column whose column-number matches the column for which this expression is evaluated and whose number-columns-spanned also matches any span. If there is no match for the number-columns-spanned, it is matched against a span of 1. If there is still no match, the initial value is returned. If the argument specifies a shorthand property and if the expression only consists of the from-table-column 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 from-table-column 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 from-table-column 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 from-table-column 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. It is also an error to use this function on formatting objects that are not an fo:table-cell or its descendants.

number proportional-column-width(number)

The proportional-column-width function returns N units of proportional measure where N is the argument given to this function. The column widths are first determined ignoring the proportional measures. The difference between the table-width and the sum of the column widths is the available proportional width. One unit of proportional measure is the available proportional width divided by the sum of the proportional factors. It is an error to use this function on formatting objects other than an fo:table-column. It is also an error to use this function if the fixed table layout is not used.

object merge-property-values(NCName?)

The merge-property-values function returns a value of the property whose name matches the argument, or if omitted for the property for which the expression is being evaluated. The value returned is the specified value on the last fo:multi-property-set, of the parent fo:multi-properties, that applies to the User Agent state. If there is no such value, the computed value of the parent fo:multi-properties is returned. If the argument specifies a shorthand property and if the expression only consists of the merge-property-values 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 merge-property-values 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 merge-property-values 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 merge-property-values 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.

It is an error to use this function on formatting objects other than an fo:wrapper that is the child of an fo:multi-properties.

5.15.1 Improved font support

The XSL-FO Subgroup wants to align with CSS, SVG and with the emerging consensus on Web fonts for downloadable font support, and to see what font properties will be available. A future draft of this document is likely to contain a more detailed section here.

5.15.2 Force line justification

Allows a user to force line justification when the line length is within a certain range. For example, normally the last line of a paragraph would not be justified, but if the last line is longer than a certain threshold, a user may want to justify it anyway.

5.15.3 Alignment around breaks

Properties to specify what the alignment should be for the 'last line before a break' and the 'first line after a break'.

5.15.4 Tabs and tab stops

Support for tabs and tab stops as per word processors. Compatibility with other formats, mainly word processor formats is seen as important.

5.15.5 Word and letter spacing

This allows users to specify the priority between word and letter spacing.

5.15.6 Hyphenation and line breaking

Supports the specification of the number of syllables in addition to the number of characters to control hyphenation.

6.1.1 Definitions Common to Many Formatting Objects

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 4.7.2 Line-building.

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:

• there is a node N in the set such that all the nodes in the set are ancestors of N, and

• for every node N in the set, if the set contains an ancestor of N, it also contains the parent of N.

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 4.2.5 Stacking Constraints.)

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 6.4.17 fo:region-body) generated using region formatting objects assigned to the same flow (see 6.4.1.4 Flows and Flow Mapping). 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.

6.4.1 Introduction

The root node of the formatting object tree must be an fo:root formatting object. The children of the fo:root formatting object are an fo:layout-master-set, an optional fo:declarations, an optional fo:bookmark-tree, and a sequence of one or more fo:layout-master-set and/or fo:page-sequence and/or fo:page-sequence-wrapper elements. The fo:layout-master-set elements define 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 an fo:layout-master-set are pagination and layout specifications and flow-map specifications. 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. Flow-maps have the role of assigning flows to regions.

6.4.1.6 Pagination Tree Structure

The result tree structure is shown below.

Figure 39. Tree Representation of the Formatting Objects for Pagination

6.4.1.7 Example Flow Maps

A typical use of flow maps are where there are two or more flows that each, independently of each other, flow into separate regions on the pages. Another one is when the flow is flowed from one region into another region on the same page and continuing onto further pages. A third use is when two or more flows are "concatenated"; each flow beginning where the previous one ends.

6.4.1.7.1 Two flows mapping into their own regions

Figure 40. Mapping flow A to region R, flow B to region S

In this case the flows are specified as:

<fo:flow flow-name="A">
  <fo:block>In the second century of
the Christian Aera, the empire of Rome ... </fo:block>
</fo:flow>

and

<fo:flow flow-name="B">
  <fo:block>Quo usque tandem abutere, Catilina, patientia nostra? ...
</fo:block>
</fo:flow>

The regions are specified with region-name="R" and region-name="S", respectively, and the flow map is specified as follows:

<fo:flow-map flow-map-name="E1">
  <fo:flow-assignment>
    <fo:flow-source-list>
      <fo:flow-name-specifier flow-name-reference="A"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
      <fo:region-name-specifier region-name-reference="R"/>
    </fo:flow-target-list>
  </fo:flow-assignment>
  <fo:flow-assignment>
    <fo:flow-source-list>
      <fo:flow-name-specifier flow-name-reference="B"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
      <fo:region-name-specifier region-name-reference="S"/>
    </fo:flow-target-list>
  </fo:flow-assignment>
</fo:flow-map>

6.4.1.7.2 A flow mapping into two regions

Figure 41. Mapping flow A to regions R1 and R2

In this case the flow map is specified as follows:

<fo:flow-map flow-map-name="E2">
  <fo:flow-assignment>
    <fo:flow-source-list>
      <fo:flow-name-specifier flow-name-reference="A"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
      <fo:region-name-specifier region-name-reference="R1"/>
      <fo:region-name-specifier region-name-reference="R2"/>
    </fo:flow-target-list>
  </fo:flow-assignment>
</fo:flow-map>

6.4.1.7.3 Two flows mapping into a region

Figure 42. Mapping flows A and B to region R

In this case the flow map is specified as follows:

<fo:flow-map flow-map-name="E3">
  <fo:flow-assignment>
    <fo:flow-source-list>
      <fo:flow-name-specifier flow-name-reference="A"/>
      <fo:flow-name-specifier flow-name-reference="B"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
      <fo:region-name-specifier region-name-reference="R"/>
    </fo:flow-target-list>
  </fo:flow-assignment>
</fo:flow-map>

6.4.1.7.4 Two flows mapping into two regions

Figure 43. Mapping flows A and B to regions R1 and R2

In this case the flow map is specified as follows:

<fo:flow-map flow-map-name="E4">
  <fo:flow-assignment>
    <fo:flow-source-list>
      <fo:flow-name-specifier flow-name-reference="A"/>
      <fo:flow-name-specifier flow-name-reference="B"/>
    </fo:flow-source-list>
    <fo:flow-target-list>
      <fo:region-name-specifier region-name-reference="R1"/>
      <fo:region-name-specifier region-name-reference="R2"/>
    </fo:flow-target-list>
  </fo:flow-assignment>
</fo:flow-map>

6.4.1.8 Initial Caps

Large initial capital letters are often used for the first paragraph of a new section or chapter. Many scripts have precise alignment conventions for how the initial letter should be positioned relative to the text in the paragraph.

There are three main types of initial letter.

The first of these is called a "raised initial"; it is set in a larger size then the main text, and space must be left for it in the block direction. No special support is needed for raised initials, as an fo:inline can be used with an increased font-size.

The second sort is a margin initial; it protrudes into the margin in the inline direction, and is often larger than the paragraph text. This is treated as a special case of the third sort of initial capital, because of its vertical alignment requirements.

The third sort of initial letter is often called a drop capital (often abbreviated to "drop cap"). The initial letter is large enough that it extends in the block direction to the Nth following baseline; the drop capital in Figure 44 is sized such that its baseline aligns with the baseline of the fourth line of text in the paragraph, and the top aligns with the cap-height on the first line; this is called a 4-line drop cap.

Figure 44. Sample Paragraph Starting With Four-Line Drop Capital.

Note:

The height of the letter D is thus one cap-height plus three line-heights (including vertical spacing); this will not in general be equal to four times the font size, and an implementation may need to use an algorithm such as binary search to discover the correct font size given the number of lines to span.

Note:

If the line spacing varies over the course of the paragraph, the resulting size of an initial cap is implementation dependent: it must either be positioned using the inherited line spacing where the initial occurs, or must correctly take into account the varying line spacing, and align with the appropriate actual line of text.

6.4.2 Side by Side

A way to position objects next to each other. Side-by-side includes complex positioning and breaking rules

Multiple separate flows are synchronized in layout. One flow is designated as primary and contains synchronization regions marked up to draw content from the other, secondary flow or flows; this secondary content will be rendered alongside the main flow at the synchronization points.

A flow map showing dependencies.

<fo:flow-map>
   <fo:flow-assignment>
      <fo:flow-source-list>
        <fo:flow-name-specifier
           flow-name-reference="Arabic-Flow"/>
      </fo:flow-source-list>
      <fo:flow-target-list>
         <fo:region-name-specifier
         region-name-reference="Region-Middle"/>
      </fo:flow-target-list>
   </fo:flow-assignment>
   <fo:flow-assignment flow-map-dependency-reference=”Arabic-Flow”>
      <fo:flow-source-list>
         <fo:flow-name-specifier
            flow-name-reference="Armenian-Flow"/>
      </fo:flow-source-list>
      <fo:flow-target-list>
         <fo:region-name-specifier
           region-name-reference="Region-Right"/>
      </fo:flow-target-list>
   </fo:flow-assignment>
   <fo:flow-assignment flow-map-dependency-reference="Arabic-Flow">
      <fo:flow-source-list>
         <fo:flow-name-specifier
          flow-name-reference="Syriac-Flow"/>
      </fo:flow-source-list>
   <fo:flow-target-list>
      <fo:region-name-specifier
        region-name-reference="Region-Left"/>
   </fo:flow-target-list>
 </fo:flow-assignment>
 </fo:flow-map>

6.4.2.1 Common Dependencies Properties for Formatting Objects

The dependency-content-begin dependency-content-end properties are used to identify spans of separate flows that are to be synchronized, in a manner similar to that used to mark change bars. These properties can be applied to any objects, including in particular fo:block and fo:inline; the indicated spans can start and end in different elements, and the two end-points of a span do not both have to be block or inline; the spans are treated as being asynchronous with respect to the formatting.

In the example in figure 45, taken from a parallel-text edition of a text for which there are manuscripts in three different languages, corresponding sections from each manuscript are formatted side by side, with the start of each on the same line, even if the section does not start at the beginning of the line.

Figure 45. Dependent Content on non-block boundaries.

The following markup might be used:

<fo:flow flow-name=”Arabic-Flow”>
   …
   <fo:block dependency-content-begin=”Key_A”>
       And Nadan went to Haiqâr, and said to him, 
       ‘W’allah, O my uncle! The king verily 
       rejoiceth in thee for having done what he 
       commanded thee.
   </fo:block>
   <fo:block>
       And now he hath sent me to thee that thou 
       mayst dismiss the soldiers to their duties 
       and come thyself to him with thy handsbound 
       behind thee, and thy feet chained, that the 
       ambassadors of Pharaoh may see this, and 
       that the king may be feared by them and by 
       their king’.
   </fo:block> 
   <fo:block>
       And Nadan took him and went with him to the 
       king.
   </fo:block>
   <fo:block dependency-content-end=”Key_A”>
       Then answered Haiqâr and said, ‘To hear is 
       to obey.’
   </fo:block>
   …
 </fo:flow>

Example : dependency-content-begin and -end properties

6.4.3 Widow and Orphan Management

Synchronization of flows is generally implemented in a formatter by leaving space between blocks, as can be seen in the left and right columns in Figure 45. Widow and Orphan management is a mechanism for specifying how content between synchronized spans should be treated: it can be kept with a block or moved to the start of the next synchronized spam, or the synchronization gap can be suppressed entirely. If the gap is suppressed, the alignmnent of synchronized spans may not be correct, or the formatter may use other copyfitting techniques to achieve alignment.

Figure 46. illustrates the case where widows and orphans are generated.

Figure 46. Dependent Content: Formation of Widows and Orphans.

The following example shows the the keep-with-dependent-content property used together with synchronized flow content:

<fo:block keep-with-dependent-content=”widows” 
          dependent-content-begin=”Key_A”>
    Text text text …
   <fo:inline dependent-content-end=”Key_A”>
       Text text … 
   </fo:inline>
    Text text text …
 </fo:block>
 <fo:block keep-with-dependent-content=”all”>
     Text text text …
     <fo:block dependent-content-begin=”Key_B”>
         Text text … 
     </fo:inline>
     Text text text …
 </fo:block> 

Using this example as the document structure equivalent for the schematic representation in Figure 46, the result of applying the keeps is illustrated in Figure 47.

Figure 47. Dependent Content: Widow and Orphan Management Using Keep.

6.4.4 fo:root

Common Usage:

This is the top node of the formatting object tree. It holds an fo:layout-master-set formatting object, an optional fo:declarations, an optional fo:bookmark-tree, and one or more fo:layout-master-set, fo:page-sequence or fo:page-sequence-wrapper objects. An fo:layout-master-set holds masters used in the document. Each fo:page-sequence represents a sequence of pages that result from formatting the content children of the fo:page-sequence. An fo:page-sequence-wrapper can also occur as the child of fo:root. An fo:page-sequence-wrapper can contain zero or more fo:page-sequence objects or fo:page-sequence-wrapper objects. The fo:page-sequence-wrapper is used to specify inherited properties for the fo:page-sequence objects it wraps; it has no additional formatting semantics.

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 4.7.1 General Ordering Constraints.)

Contents:

(layout-master-set,declarations?,bookmark-tree?,(layout-master-set|page-sequence|page-sequence-wrapper)+)

It is an error if there is not at least one fo:page-sequence descendant of fo:root.

The following properties apply to this formatting object:

7.5 Common Accessibility Properties
7.33.8 id
7.25.1 index-class
7.25.2 index-key
7.30.15 media-usage

6.4.5 fo:declarations

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:

(color-profile)*

The fo:declarations formatting 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).

6.4.6 fo:color-profile

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 5.12.2 Color Functions), the following rules are used:

1. If the color-profile is available, the color value identified from the color-profile should be used.

2. If the color-profile is not available, the sRGB ([sRGB]) fallback must be used.

Areas:

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

Constraints:

None.

Contents:

EMPTY

The following properties apply to this formatting object:

7.33.16 src
7.19.2 color-profile-name
7.19.3 rendering-intent

6.4.7 fo:page-sequence

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 of the fo:page-sequence as assigned by the flow-map in effect for that 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, region-masters and fo:flow-map. 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.

For each formatting object descendant D under the change bar influence of a given fo:change-bar-begin object F (as defined in 6.13.2 fo:change-bar-begin), the fo:page-sequence generates a "change bar area" for each area A returned by D, as a child of the ancestor region-area of A. Each change bar area is of class xsl-absolute, with zero margin and padding, with border-end-color given by the change-bar-color of F, with border-end-style given by the change-bar-style of F, with border-end-width given by the change-bar-width of F, with inline progression-dimension equal to zero and block-progression-dimension equal to the dimension of A parallel to the block-progression-dimension of the region-area.

The change bar area is positioned to be adjacent to the nearest ancestor area C of A which is either a normal-flow-reference-area or region-reference-area. The change bar area is aligned with A and lies away from C by a distance given by the change-bar-offset of F, with respect to the start-edge or the end-edge of C as determined by the change-bar-placement trait of F.

Trait Derivation:

The reference-orientation and writing-mode of the region-viewport-areas are determined by the values of the "reference-orientation" and "writing-mode" properties of the fo:page-sequence.

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 five types of constraints:

• Completeness. All areas returned by formatting object descendants of the flow children of the fo:page-sequence become descendants of areas generated by the fo:page-sequence, with the exception of glyph-areas subject to deletion or substitution as in Sections 4.7.2 Line-building and 4.7.3 Inline-building.

• Flow-map association. The areas returned from a flow child of the fo:page-sequence must be descendants of region-reference-areas generated using regions to which the flow is assigned by the flow-map in effect.

  Areas returned from an fo:static-content with a flow-name of xsl-before-float-separator become children of the before-float-reference-area of an area associated to an fo:region-body, following all sibling areas of area-class xsl-before-float. Areas returned from an fo:static-content with a flow-name of xsl-footnote-separator become children of the footnote-reference-area of an area associated to an fo:region-body, preceding all sibling areas of area-class xsl-footnote.

  If the flow-map-reference is specified, the flow-map in effect is the closest preceding fo:flow-map (this is a child of a preceding fo:layout-master-set) having a flow-map-name matching the specified value of flow-map-reference on the fo:page-sequence. If the flow-map-reference is not specified, the flow-map in effect is the implicit flow-map shown in 6.4.32 fo:flow-map.

• Area-class association. Areas returned by flow children of an fo:page-sequence are distributed as follows:

  • All areas of area-class xsl-footnote, and all areas returned from an fo:static-content with a flow-name of xsl-footnote-separator, must be descendants of a footnote-reference-area;

  • all areas of area-class xsl-before-float, and all areas returned from an fo:static-content with a flow-name of xsl-before-float-separator, must be descendants of a before-float-reference-area;

  all other areas must be descendants of a region-reference-area and further they must be descendants of a main-reference-area child of that region-reference-area if it has one.

• Stacking. The stackable areas of a given class returned by children of each flow are properly stacked within the appropriate reference-area, as described above.

• Flow-assignment ordering. The default ordering constraint of 4.7.1 General Ordering Constraints does not apply to the fo:page-sequence. The default ordering constraint applies to the flow object children inside each fo:flow; special ordering constraints apply to the child fo:static-content objects.

  If the flow-map in effect for a page-sequence has a flow-assignment child with flow-source-list S and flow-target-list T and the child flow-name-specifiers of S have flow-name-reference values F₁,...,F_m, and the child region-name-specifiers of T have region-name-reference values R₁,...,R_n, then for each area-class C, the areas returned to the page-sequence belonging to that class have the same order in the area tree (relative to the region ordering) as their generating formatting objects (relative to the flow ordering). That is, if A and B are areas of area-class C and either A and B are returned by the same flow with A returned prior to B, or A and B are returned by flows with flow-name values F_i and F_j, respectively, for some i and j such that i<j, then one of the following conditions must hold:

  • the ancestor page-reference-area of A precedes the ancestor page-reference-area of B, or

  • A and B share the same ancestor page-reference-area, A is a descendant of a region-reference-area generated using a region whose region-name value is R_k and B is a descendant of a region-reference-area generated using a region whose region-name value is R_l for some k and l such that k<l, or

  • A and B are descendants of the same region-reference-area and A precedes B in the pre-order-tree traversal of the area tree.

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

• Completeness. All areas returned by formatting object descendants of the fo:title child of the fo:page-sequence become descendants of the title-area generated by the fo:page-sequence, with the exception of glyph-areas subject to deletion or substitution as in Sections 4.7.2 Line-building and 4.7.3 Inline-building.

• Stacking. The areas returned by children of the fo:title are properly stacked within the title-area.

The default ordering constraint of section 4.7.1 General Ordering Constraints does apply to the fo:title.

Contents:

(title?,folio-prefix?,folio-suffix?,static-content*,flow+)

The following properties apply to this formatting object:

7.10.1 country
7.30.7 flow-map-reference
7.29.1 format
7.10.6 language
7.29.4 letter-value
7.29.2 grouping-separator
7.29.3 grouping-size
7.33.8 id
7.25.1 index-class
7.25.2 index-key
7.30.11 initial-page-number
7.30.10 force-page-count
7.30.13 master-reference
7.22.3 reference-orientation
7.32.7 writing-mode

6.4.8 fo:page-sequence-wrapper

Common Usage:

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

Areas:

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

Trait Derivation:

Except for "id", "index-class", and "index-key", the fo:page-sequence-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:page-sequence-wrapper is the same order as the children are ordered under the fo:page-sequence-wrapper. An fo:page-sequence-wrapper that contains no fo:page-sequence objects as descendants returns no areas.

Contents:

(layout-master-set|page-sequence|page-sequence-wrapper)*

The following properties apply to this formatting object:

7.33.8 id
7.25.1 index-class
7.25.2 index-key

6.4.9 fo:layout-master-set

Common Usage:

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

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:

(simple-page-master|page-sequence-master|flow-map)+

6.4.10 fo:page-sequence-master

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:

(single-page-master-reference|repeatable-page-master-reference|repeatable-page-master-alternatives)+

The following properties apply to this formatting object:

7.30.12 master-name

6.4.11 fo:single-page-master-reference

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:

7.30.13 master-reference

6.4.12 fo:repeatable-page-master-reference

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 page-master referred to by this formatting object 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:

7.30.13 master-reference
7.30.14 maximum-repeats

6.4.13 fo:repeatable-page-master-alternatives

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. The repetitions may also be cyclic. 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;

• Blank

• The nth page in a page-sequence or a page cycle.

The full set of conditions allows different page-masters to be used for the first page, for odd and even pages, for blank pages, etc.

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

(conditional-page-master-reference+)

The following properties apply to this formatting object: