Quick Table of Contents
|4 Area Model
4.2 Rectangular Areas
4.3 Spaces and Conditionality
4.5 Stacked Block-areas
4.8 Stacked Inline-areas
4.10 Ordering Constraints
4.11 Keeps and Breaks
4.12 Rendering Model
4.13 Sample Area Tree
4.14 List of Traits on Areas
In XSL, one creates a tree of formatting objects that serve as inputs or specifications to a formatter. The formatter generates a hierarchical arrangement of areas which comprise the formatted result. This section defines the general model of areas and how they interact. The purpose is to present an abstract framework which is used in describing the semantics of formatting objects. It should be seen as describing a series of constraints for conforming implementations, and not as prescribing particular algorithms.
The formatter generates an ordered tree, the area tree, which describes a geometric structuring of the output medium. The terms child, sibling, parent, descendant, and ancestor refer to this tree structure. The tree has a root node.
Each area tree node other than the root is called an area and is associated to a rectangular portion of the output medium. Areas are not formatting objects; rather, a formatting object generates zero or more rectangular areas, and normally each area is generated by a unique object in the formatting object tree.
The only exceptions are when several leaf nodes of the formatting object tree are combined to generate a single area, for example when several characters in sequence generate a single ligature glyph. In all such cases, relevant properties such as font-family and font-size are the same for all the generating formatting objects (see section [4.10.2 Line-building]).
An area has a content-rectangle, the portion in which its child areas are assigned, and optional padding and border. The diagram shows how these portions are related to one another. The outer bound of the border is called the border-rectangle, and the outer bound of the padding is called the padding-rectangle.
Each area has a set of traits, a mapping of names to values, in the way elements have attributes and formatting objects have properties. Individual traits are used either for rendering the area or for defining constraints on the result of formatting, or both. Traits used strictly for formatting purposes or for defining constraints may be called formatting traits, and traits used for rendering may be called rendering traits. Traits whose values are copied from property of the same or a corresponding name are listed in [C Property Index] and [5 Property Refinement / Resolution]; other traits are listed in [4.14 List of Traits on Areas].
The semantics of each type of formatting object that generates areas are given in terms of which areas it generates and their place in the area-tree hierarchy. This may be further modified by interactions between the various types of formatting objects. The properties of the formatting object determine what areas are generated and how the formatting object's content is distributed among them. (For example, a word that is not to be hyphenated may not have its glyphs distributed into areas on two separate line-areas.)
The traits of an area are either:
1. "directly-derived" -- The values of directly-derived traits are the computed value of a property of the same name on the generating formatting object, or
2. "indirectly-derived" -- The values of indirectly-derived traits are the result of a computation involving the computed values of one or more properties on the generating formatting object, other traits on this area or other interacting areas (ancestors, parent, siblings, and/or children) and/or one or more values constructed by the formatter. The calculation formula may depend on the type of the formatting object.
This description assumes that refined values have been computed for all properties of formatting objects in the result tree, i.e., all relative and corresponding values have been computed and the inheritable values have been propagated as described in [5 Property Refinement / Resolution]. This allows the process of inheritance to be described once and avoids a need to repeat information on computing values in this description.
There are two types of areas: block-areas and inline-areas. These differ according to how they are typically stacked by the formatter. An area can have block-area children or inline-area children as determined by the generating formatting object, but a given area's children must all be of one type. Although block-areas and inline-areas are typically stacked, some areas can be explicitly positioned.
A line-area is a special kind of block-area whose children are all inline-areas. A glyph-area is a special kind of inline-area which has no child areas, and has a single glyph image as its content.
Typical examples would be: a paragraph rendered by using an fo:block formatting object, which generates block-areas, and a character rendered by using an fo:character formatting object, which generates an inline-area (in fact, a glyph-area).
Associated with any area are two directions, which are derived from the generating formatting object's writing-mode and reference-orientation properties: the block-progression-direction is the direction for stacking block-area descendants of the area, and the inline-progression-direction is the direction for stacking inline-area descendants of the area. Another trait, the shift-direction, is present on inline-areas and refers to the direction in which baseline shifts are applied. Also the glyph-orientation defines the orientation of glyph-images in the rendered result.
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
is called a reference-area.
Only a reference-area may have a block-progression-direction which is different from
that of its parent.
A reference-area may be either a
block-area or an inline-area.
The Boolean trait is-viewport-area determines
whether or not an area establishes an opening through which its
descendant areas can be viewed, and can be used to
present clipped or scrolled material; for example, in printing
applications where bleed and trim is desired.
An area for which this trait is
is called a viewport-area.
A common construct is a viewport/reference pair. This is a block-area 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 coincide with the start-edge and end-edge of the content-rectangle of V.
Each element 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
case of areas generated by descendants of formatting objects
whose absolute-position is
fixed); the left-offset
and top-offset determine the amount by which
a relatively-positioned area is shifted for rendering. These traits receive
their values during the formatting process, or in the case
of absolutely positioned areas, during refinement.
The block-progression-dimension and inline-progression-dimension of an area represent the extent of the content-rectangle of that area in each of the two relative dimensions
Other traits include:
the is-first and is-last traits, which are Boolean traits
indicating the order in which areas are generated and returned by a given
formatting object. is-first is
for the first area (or only area) generated and returned by a formatting object,
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);
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.; and
the background rendering of the area: background-color, background-image, and other background traits.
"Before", "after", "start", and "end" refer to relative directions and are defined below.
a set of font traits (see "Common Font Properties") which determine the nominal-font that is deemed to be used within that area.
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.10.2 Line-building] and [4.12.4 Border, Padding, and Background].)
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 glyph contents or descendant 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 extends to the content-rectangle in the block-progression-direction and to the border-rectangle in the inline-progression-direction.
Allocation- and content-rectangles 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.
The inclusion of space outside the border-rectangle of a block-area in the inline-progression-direction does not affect placement constraints, and is intended to promote compatibility with the CSS box model.
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.
The following diagram shows the correspondence between the various edge names for a mixed writing-mode example:
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 with the same-named edges on the padding-, border-, and allocation-rectangles. This is important in the case of nested block-areas with different writing-modes.
Each inline-area has a position-point determined by the formatter, on the start-edge of its allocation-rectangle; for a glyph-area, this is a point on the leading edge of the glyph on its preferred 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.
In the area tree, the set of areas with a given parent is ordered. The terms initial, final, preceding, and following refer to this ordering.
In any ordered tree, this sibling order extends to an ordering of the entire tree in at least two ways.
In the pre-order traversal order of a tree, the children of each node (their order unchanged relative to one another) follow the node, but precede any following siblings of the node or of its ancestors.
In the post-order traversal order of a tree, the children of each node precede the node, but follow any preceding siblings of the node or of its ancestors.
"Preceding" and "following", when applied to non-siblings, will depend on the extension order used, which must be specified. However, in either of these given orders, the leaves of the tree (nodes without children) are unambiguously ordered.
This section defines the notion of block-stacking constraints and inline-stacking constraints involving areas. These are defined as ordered relations, i.e., if A and B have a stacking constraint it does not necessarily mean that B and A have a stacking constraint.
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
area is an area with area-class
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
placement of these areas is controlled by the formatting object generating
the relevant reference-area. Areas with area-class equal to one of
xsl-before-float are defined to be
indicating that they are supposed to be properly stacked.
If P is a block-area, then there is a fence-before 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-after 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, it is defined that A and B have block-stacking constraint S if any of the following conditions holds:
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.
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.
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, there is no fence-before 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, there is no fence-after P, P and B have a block-stacking constraint S'', and S consists of the space-after of A followed by S''.
Adjacent Edges with Block-stacking
The use of "stackable" in two places in the above definition allows block-stacking constraints to apply between areas of area-class
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 content-rectangle of A and the after-edge of the allocation-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.
The intention of the definition is to identify areas at any level of the tree which have only space between them.
Block-stacking constraint example
Example. In this diagram each node represents a block-area. Assume that all padding and border widths are zero, and none of the areas are reference-areas. Then P and A have a block-stacking constraint, as do A and B, A and C, B and C, C and D, D and B, B and E, D and E, and E and P; these are the only pairs in the diagram having block-stacking constraints. If B had non-zero padding-after, then D and E would not have any block-stacking constraint (though B and E would continue to have a block-stacking constraint).
Inline-stacking constraints. This section will recursively define the inline-stacking constraints between two inline-areas, together with the notion of fence-before and fence-after; 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 block-progression-direction different from that of its parent.)
If P and Q have an inline-stacking constraint, then P has a fence-before 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-after 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 inline-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:
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.
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.
A and B are both inline-areas, and either
a. 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 the first normal child of an inline-area P, P has no fence-after 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 the last normal child of a block-area P, P has no fence-before 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 A and P, and S consists of the space-end of A followed by S''.
d. B is the last normal child of an inline-area P, P has no fence-after 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 the first normal child of a block-area P, P has no fence-before 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 A and P, and S consists of the space-start of A followed by S''.
Adjacent Edges with Inline-stacking 1.
Adjacent Edges with Inline-stacking 2.
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 content-rectangle of A and the end-edge of the allocation-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. In this case the second of the adjacent edges of P and A is defined to be a leading edge in P. A space-specifier which applies to the leading edge is also defined to begin P
Similarly, An area A ends an area P if A is a descendant of P and A and P have either a block-stacking constraint or an inline-stacking constraint. In this case the first of the adjacent edges of A and P is defined to be a trailing edge in P. A space-specifier which applies to the trailing edge is also defined to end P
Each script has its preferred "baseline" for aligning glyphs from that script. Western scripts typically use a "alphabetic" baseline that touches at or near the bottom of capital letters. Further, for each font there is a preferred way of aligning embedded characters from different scripts, e.g., for a Western font there is a separate baseline for aligning embedded ideographic or Indic characters.
Each block-area and inline-area has a dominant-baseline trait which is a baseline-type, an enumerated type corresponding to the type of alignment expected for the nominal font for that area. Similarly, each inline-area has a baseline-identifier trait, corresponding to the type of alignment preferred for that area. The geometric line identified by this trait is called the preferred baseline of the inline-area.
Associated to each font is a table of baseline shifts, called the baseline table, which associates to each pair of possible baseline types the distance between the corresponding baselines in that font.
Example. For a Western font, the baseline table would
associate to the pair <
hanging> a distance
approximately equal to the ascent of the font, representing the offset
from the alphabetic baseline of the designated
alignment-point for embedded hanging-aligned characters.
Some font standards, e.g., OpenType, define a baseline table as part of the font data.
Certain baselines which are not part of the registered set of baselines are defined
as follows. The offset of the
is determined by the ascent of the nominal-font relative to the
baseline offset is defined to be the descent of the nominal-font.
For each line-area, the offset of the "before-edge" baseline is determined by ignoring
all inline-areas whose baseline-identifier is
The "before-edge" baseline
offset is set to the maximum extent in the direction opposite the block-progression-direction,
of the before-edges of the remaining inline-areas. If all
the inline-areas in a line-area are aligned "before-edge"
then use "text-before-edge" as the
"before-edge" alignment offset. The determination of the "after-edge" baseline is analogous.
For each area before-baseline-height and after-baseline-height are defined to be the respective distances from the area's dominant-baseline to the before-edge and after-edge baselines. The text-before-baseline-height and the text-after-baseline-height are defined to be the respective distances from the area's dominant-baseline to the text-before-edge and text-after-edge baselines.
A space-specifier is a compound datatype whose components are minimum, optimum, and maximum, conditionality, and precedence.
Minimum, optimum, and maximum are lengths and can be used to define a constraint on a distance, namely that the distance should preferably be the optimum, and in any case no less than the minimum nor more than the maximum. Any of these values may be negative, which can (for example) cause areas to overlap, but in any case the minimum should be less than or equal to the optimum value, and the optimum less than or equal to the maximum value.
Conditionality is an enumerated value which controls whether a
space-specifier has effect at the beginning or end of a reference-area or a
line-area. Possible values are
a conditional space-specifier is one for which this value is
Precedence has a value which is either an integer or the special
force. A forcing space-specifier
is one for which this value is
Space-specifiers occurring in sequence may interact with each other. The constraint imposed by a sequence of space-specifiers is computed by calculating for each space-specifier its associated resolved space-specifier in accordance with their conditionality and precedence, as shown below in the space-resolution rules.
The constraint imposed on a distance by a sequence of resolved space-specifiers is additive; that is, the distance is constrained to be no less than the sum of the resolved minimum values and no larger than the sum of the resolved maximum values.
To compute the resolved space-specifier of a given space-specifier S, consider the maximal inline-stacking constraint or block-stacking constraint containing S. The resolved space-specifier of S is a non-conditional space-specifier computed in terms of this sequence.
If any of the space-specifiers (in the maximal sequence) 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.
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.
If any of the remaining space-specifiers 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.
Alternatively if all of the remaining space-specifiers are non-forcing, then the resolved space-specifier is defined in terms of those 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, when there are at 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 as its minimum, and the least of their maximum values as its maximum, and all other space-specifiers are suppressed.
Example. Suppose the sequence of space values occurring at the
beginning of a reference-areas 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
retain; and third, a space
with value 5 points and conditionality
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 the 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 may be specified as conditional. If so, then it is set to zero if its associated edge is a leading or trailing edge in a reference-area. In this case, the border or padding is taken to be zero for purposes of the stacking constraint definitions.
Block-areas have several traits which typically affect the placement of their
children. The line-height is used in line placement calculations.
The line-stacking-strategy trait controls what kind of allocation
is used for descendant line-areas and has an enumerated value
line-height). This is all rigorously described below.
All areas have these traits,
but they only have relevance for areas which have stacked line-area children.
The space-before and space-after determine the distance between the block-area and surrounding block-areas.
A block-area which is not a line-area typically has its size in the inline-progression-direction determined by its start-indent and end-indent and by the size of its nearest ancestor reference-area. A block-area which is not a line-area typically varies its block-progression-dimension to accommodate its descendants. Alternatively the generating formatting object may specify a block-progression-dimension for the block-area.
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:
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, 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, minus its border-end, padding-end, and space-end values.
For each pair of normal areas B and B' in the subtree below P, if B and B' have a block-stacking constraint S, 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.
The start-intrusion-adjustment and end-intrusion-adjustment are traits used to deal with intrusions from floats in the inline-progression-direction. 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 the edges of the content-rectangle may not correspond to like-named edges of the allocation-rectangle.
Example. In the diagram, if area
has a space-after value of 3 points, B a
of 1 point, and C a space-before of 2 points, all
force, and with zero border and padding,
then the constraints will place B's
4 points below that of A, and C's
6 points below that
of A. Thus the 4-point gap receives the
from P, and the 2-point gap before C
receives the background color from B.
A line-area is a special type of block-area, and is generated by the same formatting object which generated its parent. Line-areas do not have borders and padding, i.e., border-before-width, padding-before-width, etc. are all zero. Inline-areas are stacked within a line-area relative to a baseline-start-point which is a point determined by the formatter, on the start-edge of its content-rectangle.
The allocation-rectangle of a line is determined by the value of the
line-stacking-strategy trait: if the
font-height, the allocation-rectangle is
the nominal-requested-line-rectangle, defined below; if the value is
max-height, the allocation-rectangle is the
maximum-line-rectangle, defined below; and if
the value is
line-height, the allocation-rectangle is the
per-inline-height-rectangle, defined below.
The nominal-requested-line-rectangle for a line-area is the rectangle whose start-edge and end-edge are parallel to and coincident with the start-edge and end-edge of the content-rectangle of the parent block-area (as modified by typographic properties such as indents), whose before-edge is separated from the baseline-start-point by the text-before-baseline-height, and whose after-edge is separated from the baseline-start-point by the text-after-baseline-height. It has the same block-progression-dimension for each line-area child of a block-area.
The maximum-line-rectangle for a line-area is the rectangle whose start-edge and end-edge are parallel to and coincident with the start-edge and end-edge of the nominal-requested-line-rectangle, and whose extent in the block-progression-direction is the minimum required to enclose both the nominal-requested-line-rectangle and the allocation-rectangles of all the inline-areas stacked within the line-area; this may vary depending on the descendants of the line-area.
Nominal and Maximum Line Rectangles
The per-inline-height-rectangle has the same length as the nominal-requested-line-rectangle in the inline-progression-direction. For each inline-area the half-leading is defined to be half the difference of its line-height minus its block-progression-dimension. The expanded-rectangle of an inline-area is the rectangle with start-edge and end-edge coincident with those of its allocation-rectangle, and whose before-edge and after-edge are outside those of its allocation-rectangle by a distance equal to the half-leading. The per-inline-height-rectangle is then defined to have the minimum block-progression-dimension required to enclose both the nominal-requested-line-rectangle and the expanded-rectangles of all the inline-areas stacked within the line-area; this may vary depending on the descendants of the line-area.
Using the nominal-requested-line-rectangle allows equal baseline-to-baseline spacing. Using the maximum-line-rectangle allows constant space between line-areas. Using the per-inline-height-rectangle and zero space-before and space-after allows CSS-style line box stacking.
An inline-area has its own line-height trait, which may be
different from the line-height of its containing block-area. This may affect the
placement of its ancestor line-area when the line-stacking-strategy
line-height. An inline-area has a baseline table
for its nominal-font. It has
a dominant-baseline trait which determines how
its stacked inline-area descendants are to be aligned.
An inline-area may or may not have child areas, and if so it may or may not be a reference-area. The dimensions of the content-rectangle for an inline-area without children is computed as specified by the generating formatting object, as are those of an inline-area with block-area children.
An inline-area with inline-area children has a content-rectangle which is the minimum rectangle (with sides parallel to those of the content-rectangle of its parent area) which includes the allocation-rectangles of all of its children, and which extends from its position-point by at least the after-baseline-height in the block-progression-direction, and in the opposite direction by at least the before-baseline-height from its position-point (these latter quantities derived from the nominal-font of the area, as defined in section [4.2.6 Font Baseline Tables]).
Examples of inline-areas with children might include portions of inline mathematical expressions or areas arising from mixed writing systems (left-to-right within right-to-left, for example).
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 a baseline, defined as follows:
1. If P is a line-area, the baseline of P is defined to be the line through the baseline-start-point which is parallel to the inline-progression-direction;
2. If P is an inline-area, the baseline of P is defined to be the line through the position-point of P which is parallel to the inline-progression-direction.
For a parent area P whose children are inline-areas, P is defined to be properly stacked if all of the following conditions hold:
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.
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.
For any inline-area descendant I of P, the distance in the shift-direction from the baseline of P to the position-point of I equals the distance between the dominant-baseline of P and the preferred baseline of I (as determined by the dominant-baseline table of P), plus the sum of the baseline-shifts for I and all of its ancestors which are descendants of P. This alignment is done with respect to the line-area's dominant-baseline, and not with respect to the baseline of any intermediate area.
The first summand is computed to compensate for mixed writing systems with different nominal glyph baselines, and the other summands involve deliberate baseline shifts for things like superscripts and subscripts.
The most common inline-area is a glyph-area, which contains the representation for a character 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 position-point and preferred baseline 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 baseline table are the same for all glyphs in a font.
A subset S of the areas returned to a formatting object is called properly ordered if the areas in that subset have the same order as their generating formatting objects. Specifically, if A1 and A2 are areas in S, returned by child formatting objects F1 and F2 where F1 precedes F2, then A1 must precede A2 in the pre-order traversal order of the area tree. If F1 equals F2 and A1 is returned prior to A2, then A1 must precede A2 in the pre-order-traversal of the area tree.
For each formatting object F and each area-class C, the subset consisting of the areas returned to F with area-class C must be properly ordered, except where otherwise specified.
This section describes the ordering constraints that apply to formatting an fo:block or similar block-level object.
A block-level formatting object F which constructs lines does so by constructing block-areas which it returns to its parent formatting object, and placing normal areas 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 S1, S2, ..., Sn of the normal areas returned by the child formatting objects, such that the following are all satisfied:
Each subset consists of a sequence of inline-areas, or of a single block-area.
The ordering of the partition follows the ordering of the formatting object tree. Specifically, if A is in Si and B is in Sj with i < j, or if A and B are both in the same subset Si 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.
The partitioning occurs at legal line-breaks. Specifically, if A is the last area of Si and B is the first area of Si+1, then the rules of the language and script in effect must permit a line-break between A and B, within the context of all areas in Si and Si+1.
The partition follows the ordering of the area tree, except for certain glyph substitutions and deletions. Specifically, if B1, B2, ..., Bp 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,
if Si consists of a single block-area then Bi is that block-area, and
if Si consists of inline-areas then
Bi is a line-area whose child areas are the
same as the inline-areas in Si, 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. Deletions occur when a glyph-area which is
first or last within a subset, has a
suppress-at-line-break value of
Insertions and substitutions may
occur because of addition of hyphens or spelling changes due to
hyphenation, or glyph image construction from syllabification, or
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, baseline-identifier, color
trait, background traits, dominant-baseline, font traits,
glyph-orientation-vertical, line-height, line-height-shift-adjustment,
Line-areas do not receive the background traits or text-decoration of their generating formatting object, or any other trait that requires generation of a mark during rendering.
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 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 S1, S2, ..., Sn of the normal inline-areas returned by the child formatting objects, such that the following are all satisfied:
Each subset consists of a sequence of inline-areas
The ordering of the partition follows the ordering of the formatting object tree, as defined above.
The partitioning occurs at legal line-breaks, as defined above.
The partition follows the ordering of the area tree, except for certain glyph substitutions and deletions, as defined above (except that the case where Si is a block-area does not arise).
Keep and break conditions apply to a class of areas, which are typically page-reference-areas, column-areas, and line-areas. The appropriate class for a given condition is referred to as a context and an area in this class is a context-area. As defined in Section [6.4.1 Introduction], page-reference-areas are areas generated by an fo:page-sequence using the specifications in a fo:page-master, and column-areas are reference-areas generated from a region-master.
A keep or break condition is an open statement about a formatting object and the tree relationships of the areas it generates with the relevant context-areas. These tree relationships are defined mainly in terms of leading or trailing areas. If A is a descendant of P, then A is defined to be leading in P if A has no preceding sibling which is a normal area, nor does any of its ancestor areas up to but not including P. Similarly, A is defined to be trailing in P if A has no following sibling which is a normal area, nor does any of its ancestor areas up to but not including P. For any given formatting object, the next formatting object in the flow is the first formatting object following (in the pre-order traversal order) which generates and returns normal areas.
Break conditions are either break-before or break-after conditions. A break-before condition is satisfied if the first area generated and returned by the formatting object is leading within a context-area. A break-after condition depends on the next formatting object in the flow; it is satisfied if either there is no such next formatting object, or if the first normal area generated and returned by that formatting object is leading in a context-area.
Break conditions are imposed by the break-before and
break-after properties. A
refined value of
page for these traits imposes a
break condition with a context
consisting of the page-reference-areas; a value of
odd-page imposes a
break condition with a context of even-numbered page-reference-areas
page-reference-areas, respectively; a value of
column imposes a
break condition with a
context of column-areas. A value of
auto in a
break-before or break-after
trait imposes no break condition.
Keep conditions are either keep-with-previous, keep-with-next, or keep-together conditions. A keep-with-previous condition on an object is satisfied if the first area generated and returned by the formatting object is not leading within a context-area, or if there are no preceding areas in a post-order traversal of the area tree. A keep-with-next condition is satisfied if the last area generated and returned by the formatting object is not trailing within a context-area, or if there are no following areas in a pre-order traversal of the area tree. A keep-together condition is satisfied if all areas generated and returned by the formatting object are descendants of a single context-area.
Keep conditions are imposed by the "within-page", "within-column", and "within-line" components
of the keep-with-previous, keep-with-next, and
The refined value of each component specifies the strength of the keep condition
imposed, with higher numbers being stronger than lower numbers and the value
always being stronger than all numeric values.
A component with value
does not impose a keep condition. A "within-page" component imposes a keep-condition
with context consisting of the page-reference-areas; "within-column", with context consisting of
the column-areas; and "within-line" with context consisting of the line-areas.
The area tree is constrained to satisfy all break conditions imposed. Each keep condition must also be satisfied, except when this would cause a break condition or a stronger keep condition to fail to be satisfied. If not all of a set of keep conditions of equal strength can be satisfied, then some maximal satisfiable subset of conditions of that strength must be satisfied (together with all break conditions and maximal subsets of stronger keep conditions, if any).
This section makes explicit the relationship between the area tree and visually rendered output.
Areas generate three types of marks: (1) the area background, if any, (2) the marks intrinsic to the area (a glyph, image, or decoration) if any, and (3) the area border, if any.
An area tree is rendered by causing marks to appear on an output medium in accordance with the areas in the area tree. This section describes the geometric location of such marks, and how conflicts between marks are to be resolved.
Each area is rendered in a particular location. Formatting object semantics describe the location of instrinsic 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.12.2 Viewport Geometry].
All areas in the tree with an area-class of
are positioned such
that the left-, right-, top-, and bottom-edges of its
offset inward from the content-rectangle of its ancestor page-viewport-area
by distances specified by the left-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.12.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
content-rectangle of its nearest ancestor reference-area by distances
specified by the left-position,
bottom-position traits, respectively. These are shifted left
and down by the values of the top-offset
and left-offset traits, respectively, if the area
has a relative-position of
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 coincident with the start-edge and end-edge of the content-rectangle of its parent viewport-area, 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 scroll-amount.
If the block-progression-dimension of the reference-area is larger
of the viewport-area and the overflow trait
for the reference-area is
then the scroll-amount is determined by a scrolling mechanism, if any,
provided by the user agent. Otherwise, the scroll-amount is zero.
The visibility of marks depends upon the location of the marks, the visibility of the area, and the overflow of any ancestor viewport-areas.
If an area has visibility
hidden it generates no marks.
If an area has an overflow of
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
the clipping rectangle do not appear.
The border- and padding-rectangles are determined relative to the content-rectangle by the values of the common padding and border width traits (border-before-width, etc.).
For any area which is not a child of a viewport-area, the border is rendered between the border-rectangle and the padding-rectangle in accordance with the common border color and style traits. For a child of a viewport-area, the border is not rendered.
For an area which is not part of a viewport/reference pair, the
background is rendered. For an area that is either a viewport-area or a
reference-area in a viewport/reference pair, if the refined value of
and the block-progression-dimension of the reference-area is larger than
that of the viewport-area, then the background is rendered on the
reference-area and not the viewport-area, and otherwise it is rendered
on the viewport-area and not the reference-area.
The background, if any, is rendered in the padding-rectangle, in accordance with the background-image, background-color, background-repeat, background-position-vertical, and background-position-horizontal traits.
For each class of formatting objects, the marks intrinsic to its generated areas are specified in the formatting object description. For example, an fo:character object generates a glyph-area, and this is rendered by drawing a glyph within that area's content-rectangle in accordance with the area's font traits and glyph-orientation and blink traits.
In addition, other traits (for example the various score and score-color traits) specify other intrinsic marks. In the case of score traits (underline-score, overline-score and through-score), the score thickness and position are specified by the nominal-font in effect; where the font fails to specify these quantities, they are implementation-dependent.
Marks are layered as described below, which defines a partial ordering of which marks are beneath which other marks.
Two marks are defined to conflict if they apply to the same point in the output medium. When two marks conflict, the one which is beneath the other does not affect points in the output medium where they both apply.
Marks generated by the same area are layered as follows: the area background is beneath the area's intrinsic marks, and the intrinsic marks are beneath the border. Layering among the area's intrinsic marks is defined by the semantics of the area's generating formatting object and its properties. For example, a glyph-area's glyph drawing comes beneath the marks generated for text-decoration.
If A and B are areas, and the z-index of A is less than the z-index of B, then all marks generated by A are beneath all marks generated by B.
If A and B are areas with the same z-index, 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 z-index), 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 z-index 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.