Copyright © 1999 W3C
(MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.
XSL is a language for expressing stylesheets. It consists of two parts:
a language for transforming XML documents, and
an XML vocabulary for specifying formatting semantics.
An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary.
This is a W3C Working Draft for review by W3C members and other interested parties. This adds additional functionality to what was described in the previous draft. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. The XSL Working Group will not allow early implementation to constrain its ability to make changes to this specification prior to final release. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR.
Comments may be sent to xsl-editors@w3.org. Public discussion of XSL takes place on the XSL-List mailing list.
This specification defines the Extensible Stylesheet Language (XSL). XSL is a language for expressing stylesheets. Given a class of structured documents or data files in XML, designers use an XSL stylesheet to express their intentions about how that structured content should be presented; that is, how the source content should be styled, laid out and paginated onto some presentation medium such as a window in a Web browser or a set of physical pages in a book, report, pamphlet, or memo.
An XSL stylesheet processor accepts a document or data in XML and an XSL stylesheet and produces the presentation of that XML source content as intended by the stylesheet. There are two sub-processes to this presentation process: first, constructing a result tree from the XML source tree and second, interpreting the result tree to produce a formatted presentation on a display, on paper, in speech or onto other media. The first (sub-)process is called tree transformation and the second (sub-)process is called formatting. The process of formatting is performed by the formatter.
Splitting the processing of a stylesheet into two sub-processes allows greater flexibility in constructing the presentation of the source content. With tree transformation, the structure of the result tree can be totally different from the structure of the source tree. In constructing the result tree, the source tree can be filtered and reordered, and arbitrary structure and generated content can be added. For example, one could add a table-of-contents a filtered selection of an original source document or one could map the result of a database query (expressed in XML) into a sorted tabular presentation of the relevant portion of the query result. In constructing the result tree, the tree transformation process also adds the information necessary to format that result tree.
The second process, formatting, is enabled by making the result tree have formatting semantics. In this recommendation, formatting semantics are expressed in terms of a catalog of formatting objects. The nodes of the result tree are instances of formatting objects. The formatting objects denote typographic abstractions such as page, paragraph, rule, and so forth. Finer control over the presentation of these abstractions is provided by a set of formatting properties, such as indents; word- and letter-spacing; and widow, orphan, and hyphenation control. The formatting objects and formatting properties provide the vocabulary for expressing presentation intent.
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.
NOTE: Issue: How much more about Tree transformation should be said in this document; it clearly needs to be enough for someone to get an good idea of what a typical result tree is/looks like.
Formatting is begun when the result tree has been completely constructed using the tree construction rules. For formatting, the nodes in this result tree are instances of formatting objects.
Syntactically, an instance of a formatting object is represented as an XML element, with the properties represented by a set of attribute-value pairs. The content of the formatting object instance is the content of the element.
The vocabulary of formatting objects supported by XSL - the set of xsl:fo
element types - represents the set of typographic
"units of organization" available to the designer.
Semantically, each formatting object instance 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 represents the breaking of
the content of a paragraph into lines. Other parts of the specification
may come from other formatting object instances; 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 in 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 hyphenation control, only constrain the set of possible formatted results without specifying any particular formatted result.
XSL builds on the prior work on Cascading Style Sheets [CSS2]and the Document Style Semantics and Specification Language [DSSSL]. XSL provides the most of the formatting objects and properties of CSS. (Conceptually, the formatting objects of CSS are indicated by using the "display" property of CSS on some existing source element.) Over 90 percent of the properties in XSL are properties that are already defined in CSS. This set of properties (and formatting objects), however, is not sufficient to accomplish all the goals of XSL. In particular, this version of XSL introduces a model for pagination and layout that can be extended, in a straightforward way, to page structures beyond the simple page models described in this specification.
Doing both scrollable document windows and pagination introduces new issues to the styling (and pagination) of XML content. Because pagination introduces arbitrary boundaries (pages or regions on pages) on the content, issues such as the control of spacing at page, region and block boundaries become more important. There are issues of adjusting the spaces between lines (to "vertically justify the page) and between words and letters (to justify the lines of text). These issues do not arise with a scrollable document window, such as those found in a browser. But, there is a correspondence between a page with multiple regions, such as a body, header, footer and left and right side-bars, 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 allow a designer to control 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 CSS set of formatting objects and formatting properties. In addition, the selection of XML source components (elements, attributes, text nodes, comments and processing instructions) that can be styled is an extension of the CSS selector set.
In designing these extensions, DSSSL was used as the first source of the extension content. The actual extension, however, does not always look like the DSSSL construct on which it was based. To either conform more closely with the CSS specification or to handle cases more simply than in DSSSL, some extensions diverged from DSSSL.
There are several ways in which extensions were made to the CSS property catalog. In some cases, it sufficed to add new values to an existing CSS property. For example, a number of CSS properties had values added to reflect other writing-modes, such as top-to-bottom, rather than just left-to-right and right-to-left.
In other cases, it was necessary to split a CSS property into several new properties to provide independent control over independent aspects of a property. For example, the CSS "white-space" property was split into two properties, a "white-space-treatment" property that controls how white-space is processed and a "wrap-option" property that controls whether lines are automatically wrapped when the encounter a boundary, such as the edge of a column. The effect of splitting a CSS property into two or more (sub-)properties is to make the existing CSS property a "shorthand" for the set of sub-properties it subsumes.
In still other cases, it was necessary to create new properties because CSS had not (yet) addressed the topic. 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-char" (which varies from script to script).
The four above classes of XSL properties are identified as: (1)CSS properties by reference; (2)CSS properties with extended values; (3)CSS properties broken apart and/or extended or (4)XSL only properties. The first class includes all the CSS properties that are used in this specification unchanged from their CSS semantics.
The XSL extensions to CSS are discussed below:
The patterns that are used in tree construction provide much finer control over how portions of the source content are presented and what properties are associated with those content portions. For example, the patterns of XSLT allow the selection of a portion of a string or the Nth text node in a paragraph; selections which are not possible in CSS. In addition, properties can be associated with a content portion based on the numeric value of that content portion or attributes on the element which contains the content. This allows one to have a style rule that will make negative values appear in "red" and positive values appear in "black".
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 side-bars; 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 side-bars 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 the layout extensions, there are extensions to the set of properties used in CSS to provide the level of control over formatting that is typical of paginated documents. This includes control over hyphenation, expanding the control over text that is kept with other text in the same column, on the same page.
The extension of the properties and formatting objects, particularly in the area on control over the spacing of blocks, lines, and page regions and within lines, necessitated an extension of the CSS box formatting model. This extended model is described in Section 3.4: Formatting Model of this specification. The CSS box model is a subset of this model. The formatting model provides a vocabulary for describing the extensions to adjusting spaces between letters, words, lines, and blocks. It also attempts to clarify which components of the CSS Box model are actual adjustable and conditional (spacing) values.
The CSS2 specification is written for languages whose normal script is set with words proceeding from left-to-right (or right-to-left) and with lines proceeding from top-to-bottom. There are many 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. Many of the properties, which are expressed in terms of a fixed, absolute frame of reference (using top, bottom, left, and right) do not generalize well to the languages based on these scripts.
For this reason DSSSL and now XSL have used a relative frame of reference for the formatting object and property descriptions. Just as the CSS 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). These relative directions are relative to the property, "writing-mode". The writing-mode is a way of capturing 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 note 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 Section 5.18.38: 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 most often lines) are placed one after another.
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. Some of these other directions include the escapement-direction and the shift-direction (which is used for sub- and super-scripts), etc.
Because XML, unlike HTML, has no built-in semantics, there is no built-in notion of a hypertext link. Therefore, XSL had to add a formatting object that could express the dual semantics of formatting the content of the link reference and the semantics of following the link. CSS does not define a way to identify links, but it does provide a way to change the styling of the link content depending on whether the link has been visited or not. In CSS this is done with the Link Pseudo Class. XSL provides two mechanisms for changing the presentation of a link after it has been visited. One of these mechanisms allows the a different set of formatting properties to be associated with the content in the link fragment of the result tree and the other allows both the result tree content and the formatting properties to change.
This document is divided into three main sections: the mechanisms common to all formatting objects, Section 3: the formatting objects, Section 4; and the catalog of properties which may be applicable to the formatting objects, Section 5. Section 2 is a short section that refers to the separate XSLT document that describes the construction of the result tree. Section 5 is a glossary that contains definitions for all the defined terms within this specification.
The formatting objects are the typographic units from which a presentation of the XML source content is constructed. The formatting behavior of an instance of a formatting object depends on the formatting properties associated with that object. The formatting implications of each property are described in the property descriptions in Section 5. Therefore, understanding a formatting object is dependent on understanding the properties that are applicable to that object. Similarly, there are several mechanisms that underlie all the formatting objects. These common mechanisms include the Inheritance mechanism, the Formatting Model, and the Expression Language. To understand a formatting object, one must also understand the common mechanisms because the formatting objects are defined in terms of the vocabularies of the common mechanisms.
The definition of each formatting object is intended to provide the following information: (1)an overview of the role of the formatting object, (2)the semantics of the formatting object, and (3)a listing of the properties and content applicable to the formatting object. The formatting semantics of the formatting object are specified by "reducing" the properties and content of the formatting object to one or more areas within the Formatting model. There are several aspects to this reduction. The content of the formatting object is "distributed" into the areas "generated" in the reduction. The semantics do not specify any particular method for achieving the distribution of the content into areas, but instead specify a set of "constraints" which the distribution must satisfy.
The constraints are most often expressed in terms of properties on the formatting object for which the content is being distributed; for example, that the content of a flow object must be kept with the content of the previous or next flow object. Some constraints, however, are derived from the structure of the result tree or the formatting object itself; for example, which type of areas are generated to hold the content. The definition of each formatting object specifies what constraints must be satisfied.
This form of specification is used to avoid a built-in bias toward any particular implementation technique. In fact, one way to conceive of an implementation is to generate all possible distributions of the content into areas and then evaluate each such distribution to see if the constraints are satisfied. If the particular collection of areas that resulted from a particular distribution satisfies all the constraints, then that is an "acceptable distribution" of the content. In general, there will be more than one acceptable distribution of the content. A conforming processor must be able to produce at least one acceptable distribution.
Reflecting the nature of the two-level semantics, the semantic description is divided into several sections, some of which may be meaningless for a given formatting-object. There is a section on the "kind of areas", if any, that are generated by the formatting-object. This section includes information of the size of the areas and their relationships. There may be a section, if applicable, on traits which specifies how the values of the traits on the generated areas are determined. And, finally, there may be a section on the "distribution of content" which describes the constraints on the distribution of content into the generated areas.
One reason for specifying the semantics as a reduction is that there are a number of constraints that are primarily spatial. The formatting model has been developed to represent both the spatial constraints and the positioning of areas without regard to the actual content of those areas. This abstraction makes it simpler to specify the handling of areas and the spacing between them. Within the formatting model abstraction, the content is not important, but it and the information about backgrounds, padding, and borders must be carried in the model. This information is carried in "traits" that are associated with each area. Therefore, another piece of the semantic definition of a formatting object is the specification of how the values on the traits on the areas generated by the formatting object are determined. Traits are typically determined from the properties of the same name. Not all properties become traits, however. For some traits there is a set of corresponding properties which determine a single trait. The correspondences between various properties are specified in Section 3.1: Specified, Computed, and Actual Values and Inheritance
The Tree Construction is described in "XSL Transformations (XSLT)":
http://www.w3.org/TR/1999/WD-xslt-19990421
http://www.w3.org/TR/1999/WD-xslt-19990421.xml
http://www.w3.org/TR/1999/WD-xslt-19990421.html
The provisions in "XSL Transformations" form an integral part of this recommendation and are considered normative.
The semantics of formatting is divided into a set of simple steps to simplify the explanation and to highlight what interactions (or, perhaps more importantly, lack of interactions) exist between formatting objects and the properties on them. Although they are described as steps, this is solely for the convenience of exposition and does not imply they must be implemented as separate steps in any conforming implementation. A conforming implementation must only achieve the same effect. Some of the relevant steps are, for each formatting-object in the result tree, determining (computed) values for all the properties applicable to that formatting object and then using the formatting model to describe how the values of these properties constrain the distribution of the content of these formatting objects into glyph-, inline-, line-, and block-areas as well as area-containers and the resolution of the spacing adjustments among the various areas.
The step of determining the computed values of the relevant properties is described below. The process of distribution and space resolution is described and/or contrained by the descriptions of the formatting properties and the formatting objects which use them.
For every property that is applicable to the a given formatting object, it is necessary to determine the value of the property. Three variants of the property value are distinguished: the specified value, the computed value, and the actual value. The "specified value" is one that is placed on the formatting object during the tree constuction process. The specified values may not be in a form that is directly usable; for example, it may be a percentage that must be converted into an absolute value. The value resulting from such a conversion is called the "computed value". Finally, the computed value may not be realizable on the output media and may need to be adjusted prior to use in rendering. For example, a line width may be adjusted to become an integral number of output medium pixels. This adjusted value is the "actual value."
The specified value of a property is determined using the following mechanisms (in order of precedence):
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".
Otherwise, if the property is inheritable, use the value of that property from the parent formatting object, generally the computed value (see below).
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 specifed on the formatting object. (A property will only be "not specified" if there are corresponding properties that can provide equivalent information.
Since it has no parent, the root of the result tree cannot use values from its parent formatting object; in this case, the initial value is used if necessary.
Specified values may be absolute (i.e., they are not specified relative to another value, as in "red" or "2mm") or relative (i.e., they are specified relative to another value, as in "auto", "2em", and "12%"). 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 relative units (em, ex, px) must be made absolute by multiplying with the appropriate font or pixel 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.
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 the section on Computing the values of Corresponding Properties, below.
In most cases, elements inherit computed values. However, there are some properties whose specified value may be inherited (e.g., the number value for the "line-height" property). In the cases where child elements do not inherit the computed value, this is described in the property definition.
A computed value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may, therefore, have to adjust the computed width to an integral number of media pixels. The actual value is the computed value after any such adjustments have been applied.
Some of the properties applicable to formatting objects are "inheritable." Such properties are so identified in the property description. These properties are not shown in the DTD except where the property is actually used in the definition of the formatting object. The inheritable properties can be placed on any formatting object. The inheritable properties are propagated down the result tree from a parent to each child. (These properites 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 descendents until explicitly re-set in a lower descendent); 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.
Where there are corresponding properties, such as "padding-left" and "padding-start", a computed value is determined for all the corresponding properties. How the computed values are determined for a given formatting object is dependent on which of the corresponding properties are specified.
The simplest class of corresponding properties are those for which there are only two variants in the correspondance, an absolute property and a relative property, and the property names differ only in the choice of absolute or relative desigination; for example, "border-left-color" and "border-start-color".
NOTE: Issue: Need to add description of the correspondance because it involves both writing-mode and reference orientation of all enclosing area containers.
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 relative property of the same name.
Note that if both the absolute and the relative properties are not explicitly specified, then the rules for determining the specifed value will use either inheritance if that is defined for the property or the initial value. The initial value must be the same for all possible corresponding properties. If both an absolute and a corresponding relative property are explicitly specified, then the above rule gives precedence to the absolute property and the specified value of the corresponding relative property is ignored in determining the computed value of the corresponding properties.
The (corresponding) properties that use the above rule to determine their computed value are:
Border-after-color
Border-before-color
Border-end-color
Border-start-color
Border-after-style
Border-before-style
Border-end-style
Border-start-style
Border-after-width
Border-before-width
Border-end-width
Border-start-width
Padding-after
Padding-before
Padding-end
Padding-start
The "space-before", "space-after", "space-start", and "space-end" properties are handled very similarly to the properties immediately above, but the corresponding absolute properties are in the set: "margin-top", "margin-bottom", "margin-left", and "margin-right". Again the correspondance between the relative property and the corresponding absolute property is determined by the "writing-mode" property of the formatting object. For example, at the top level of a document, if the "writing-mode" is "lr-tb", then "space-before" corresponds to "margin-top", but if the "writing-mode" is "tb-rl", the "space-before" corresponds to "margin-right".
There are two more properties, "end-indent" and "start-indent", for which the computed value may be determined by the computed value of the absolute margin properties. For these traits, the calculation of the value of the trait when the corresponding absolute property is present depends on three computed values: the computed value of the corresponding absolute property, the computed value of the corresponding "padding" property, and the computed value of the corresponding "border-width" property.
Here the term "corresponding" has been broadened to mean that if "margin-left" is the corresponding absolute property to "start-indent", then "padding-left" (and "padding-start") and 'border-left-width" (and "border-start-width") are the "corresponding" "padding" and "border-width" properties.
The formulae for calculating the computed value of the x-indent properties are as follows (where "margin-corresponding" is a place-holder for the corresponding absolute "margin" property):
End-indent = margin-corresponding + padding-end + border-end-width
Start-indent = margin-corresponding + padding-start + border-start-width
If an absolute "margin" property is not explicity specified, these equations determine a computed value for the corresponding "margin" property given values for the three traits corresponding-indent, padding-corresponding and border-corresponding width.
In XSL, one creates a number of formatting objects that serve as inputs (or specifications) to a formatter. The formatter, by applying the formatting model, constructs a hierarchical arrangement of areas and spaces to produce the formatted result. This sectiom describes that general model of spaces and areas, as well as how they interact with one another. The purpose is to present an (abstract) semantic model that describes the formatting semantics that are common to all formatting objects. It should be seen as describing a series of constraints for conforming implementations, and not a prescribing any particular algorithm, e.g., for line-breaking, letter-spacing, hyphenation, or kerning.
The formatting model is defined in terms of rectangular areas and spaces. These are not formatting objects; rather, a formatting object generates one or more rectangular areas. In fact, part of the definition of a formatting object will be what rectangular areas it gives rise to and how these are structured. To keep this distinction clear, rectangular areas (and spaces) have "traits" whereas formatting objects have "properties."
Areas reserve space and hold content.
Selected rectangular areas may have their own coordinate systems and may contain other rectangular areas.
Typically, rectangular areas may contain with other areas; when this happens the contained areas are placed in accordance with the "writing-mode", which controls the direction of the placement of successive contained areas.
NOTE: Further versions or extensions of the model may take into account non-rectangular areas.
A rectangular area is like a CSS box in that it has borders and padding, which are specified by properties of the formatting object that caused the creation of the area. However, we do not define a separate notion of margin, instead subsuming the concept in inline indents, and the addition of associated display- and inline-spaces.
Spaces reserve space before and after areas and do not have content. They are used to make adjustments to the layout.
For each formatting object, its semantics are given in terms of a mapping of the formatting object and its content into one or more areas into which the content is distributed. The properties on the formatting object constrain both the areas that are generated and how the content is distributed into those areas. For example, a word that is not to be hyphenated may not have its characters distributed into areas on two separate line-areas. The traits of the generated areas are derived from the properties applicable to the formatting objects from which they were generated and/or other traits.
In the description of this formatting model, it is assumed that absolute values have been computed for all properties applicable to the formatting objects in the result tree. That is, all relative and/or corresponding values have been computed and the inheritable values have been propagated as described in the Section 3.1: Specified, Computed, and Actual Values and Inheritance. This allows the process of inheritance to be described once and avoids a need to repeat information on computing values in this model description.
There are four kinds of rectangular areas: area-containers, block-areas, line-areas, and inline-areas.
area-containers may contain smaller area-containers. Alternatively, an area-container may contain a sequence of block-areas and display-spaces, which are stacked (placed sequentially and adjacent to one another, possibly separated by display-spaces) within the area-container in a direction determined by the "writing-mode".
Area-containers always have a "writing-mode" and set a coordinate system for all contained areas. The "start-indent" and "end-indent" of any block-area is measured from the area-container's corresponding edges, not from the edges of any intervening (nested) block-area.
Area-containers may be placed at a specific positions within the containing area or may be attached to the inside of any edge of the containing area.
block-areas contain line-areas, display-spaces, and nested block-areas stacked (placed sequentially and adjacent to one another, possibly separated by display-spaces) in a direction determined by the "writing-mode".
block-areas should not be thought of as abstract entities which are "broken" across an area-container boundary; rather, at a container boundary a block-level formatting object may generate two (or more) block-areas.
Block-areas are always stacked in the containing area.
Line-areas contain inline-areas and inline-spaces in a direction determined by the "writing-mode".
Line-areas are always stacked (placed sequentially and adjacent to one another, possibly separated by display-spaces) in the containing block-area.
An inline-area may contain other inline-areas. The lowest level inline-area commonly contains a single "character" glyph image (and is then called a glyph-area). Alternatively, an inline-area may have more complex content (e.g., an inline mathematical expression or a graphic).
Inline-areas should not be thought of as abstract entities which are "broken" across a line boundary; rather, at a line boundary an inline formatting object may generate two (or more) inline-areas.
Inline-areas are always stacked (placed sequentially and adjacent to one another, possibly separated by inline-spaces) in the containing area.
Rectangular areas have a number of common features. Each has a border and padding, defined as follows.
A border surrounds the content of the area. A border is described by the color and the width of each of its four sides.
Padding is the open space between the inside of the border and the content of the area. It is described by the width in each of the four directions.
In contrast to the CSS model, XSL does not define a margin as a separate set of traits. Block-areas and line-areas have indents in the inline-progression-direction, and in other directions and areas the terms inline-spaces and display-spaces are used.
NOTE: Margins were eliminated in favor of indents and spaces because indents allow absolute position of content relative to the area-containers rather than just relative to the immediately containing area. Furthermore, there is no loss of functionality because all margin changes are mapped into changes in the indents or spaces and the indent values are inheritable.
(Not all areas are area-containers; area-containers are typically defined in the page layout rather than in the content.) In addition, margins were eliminated to allow a more uniform treatment of spaces on the edges of areas.
The step of computing values for all applicable properties on the formatting objects in the result tree has computed values for the indent and space properties, whether these properties were explicitly specified or inherited or whether the corresponding margin properties were specified. The mapping of margins into indents and/or spaces is described in the Section 3.1: Specified, Computed, and Actual Values and Inheritance. The figure below shows the mapping for a "left-to-right - top-to-bottom" writing-mode that is oriented with the top of page being the top edge of the coordinate space.
NOTE: Issue: we know we have an issue regarding Cartesian coordinate spaces that must be resolved.
Rectangular Area with Padding and Border and Associated Spaces
This model identifies a number of specific rectangles:
The content-rectangle of a rectangular area is the rectangle surrounding the area's content.
The padding rectangle surrounds the area's padding. If the padding has 0 thickness, the padding rectangle is the same as the content-rectangle.
The border rectangle surrounds the area's border. If the border has 0 width, the border rectangle is the same as the padding rectangle.
NOTE: These are parallel to concepts in CSS, called the padding area and border area, respectively.
All rectangular areas have traits that are derived either from properties or other traits as follows:
The trait is directly derived from the computed value of the property with the same name on the formatting object that generated the area, or
The trait is derived by a computation using some set of values of other traits or computed values of properties on the formatting object that generated the area.
Background, border, and padding are directly derived traits.
The "writing-mode" property determines several directions used for rectangular area placement:
block-progression-direction: the direction of progression of sequential block-areas within an area-container.
line-progression-direction: the direction of progression of sequential line-areas within a block-area. This is usually the same as the block-progression-direction but may sometimes be opposite to the block-progression-direction.
inline-progression-direction: the direction of progression of sequential inline-areas within a line-area. This is always perpendicular to the line-progression-direction.
escapement-progression-direction: the direction of progression of sequential glyph-areas within an inline-area. This is usually the same as the inline-progression-direction but may sometimes be opposite to the inline-progression-direction.
Inline-areas have a designated position-point. This model defines, the descender-depth of a glyph-area to be how far it extends in the line-progression-direction from the position-point, and the ascender-height to be how far it extends in the opposite direction. Similar definitions may be made for more complex inline-areas.
The edges of any rectangle associated with a rectangular area are identified by their relative direction, based on the "writing-mode".
The edge occurring first in the block-progression-direction or the line-progression-direction (as applicable) and perpendicular to it is called the before-edge of the rectangle. The opposite edge is the after-edge.
The edge occurring first in the inline-progression-direction or the escapement-progression-direction (as applicable) is called the start-edge of the rectangle. The opposite edge is called the end-edge.
NOTE: In European writing systems, these are the "top" and "bottom" edges, and "left" and "right" edges, respectively, and "ascender-height" and "descender-depth" have their usual meanings.
A rectangular area is immediately contained in another rectangular area if that first rectangular area is contained within the second rectangular area and there is no other area which contains the first rectangular area and is contained in the second rectangular area. For every rectangular area A and its immediately containing rectangular area B, the rectangular area A is the either initial in B or it has a preceding rectangular area C (in B). The rectangular area A is an initial rectangular area if (a) A is a block- or line-area and it is the first such area in the block-progression-direction in the immediately containing area B, or (b) A is an inline-area and it is the first such area in the inline-progression-direction in the immediately containing area B. If A is not an initial rectangular area, then there is an rectangular area C that immediately precedes the rectangular area to A in the appropriate direction (block-progression-direction if A is a block- or line-area and inline-progression-direction if A is an inline-area). C is called the "rectangular area" preceding A or the "preceding rectangular area". By analogy, the final rectangular area and the following rectangular area are similarly defined (mutatis mutandis). For spaces, a space precedes a rectangular area A if it is (a) on the before-edge of a block- or line-area or (b) is on the start-edge of an inline-area. The space is an initial space if it precedes an initial rectangular area. Final space and following space area similarly defined.
Two rectangles associated with a rectangular area are of particular significance:
The content-rectangle bounds the portion of the area in which the allocation-rectangles of smaller areas may appear. It is possible for marks associated with an area to be found outside the content-rectangle, but these are considered decoration and are deemed not to take up area.
The allocation-rectangle bounds the portion of the area which is used to allocate space when placing the area inside a larger area. An area's "size" normally refers to the dimensions of its allocation-rectangle.
For area-containers the allocation-rectangle is the same as the border rectangle.
For all other rectangular areas, the allocation-rectangle extends to the border rectangle in the inline-progression-direction. For block-areas, it extends to the border rectangle in the line-progression-direction, and for line-areas and inline-areas, it extends only to the content-rectangle in that direction.
Allocation Rectangle for Block-level Areas
Allocation Rectangle for Inline Area
[Ednote: This diagram should omit the margin rectangle; the allocation rectangle should extend only to the border.]
Display-spaces adjust the relative positioning of line-areas and/or block-areas in the block-progression direction. They are assigned preceding and following line-areas and block-areas either automatically by the formatter or as otherwise specified.
A display-space between two areas (block or line) is specified by a triple of values (minimum, optimum, maximum) which defines the limits of how the space may be transformed by later processes such as vertical justification. In the absence of further processing, the two areas will be separated by the optimum value, but such processing (or other specified properties) may reduce it as small as the specified minimum or stretch it as large as the specified maximum.
A display-space is thought of as having a before-edge and after-edge separated in the block-progression-direction or line-progression-direction by the display-space's value. A display-space value may be negative, which can cause areas to overlap.
When two or more display-spaces occur consecutively in the formatted result (with no intervening rectangular area, space, padding or border), they shall be resolved into a one or more display-space(s) whose minimum, optimum, and maximum values are derived according to the space-resolution-rules, as described below. These depend on certain specified traits of the display-space, namely conditionality, block-conditionality, and precedence. "Consecutive" is defined formally below.
Conditionality is a Boolean value which specifies whether an initial or final space persists in an area-container. If true, the space is called a conditional-space and is always omitted if it appears at the before-edge or after-edge of the allocation-rectangle of an area-container; in this case any immediately succeeding conditional-spaces are also omitted.
Block-conditionality is a Boolean value which specifies whether the space persists at the beginning or end of a block-area. If true, the space is called a block-conditional-space and is always omitted if it appears at the before-edge or after-edge of the allocation-rectangle of a block-area; in this case any immediately succeeding block-conditional-spaces are also omitted.
Precedence has a value which is either an integer or the special token "force". A space with a precedence value of "force" is called a forcing space.
Rectangular areas and spaces within an area-container are structured in a tree by containment. An ordering is defined recursively by defining A to be before B when:
A is a prior sibling of B under the same parent, or
A is before the parent of B, or
A's parent is before B.
This gives a strict partial ordering of rectangular areas and spaces of any given page. It's "partial" because if A is contained (directly or indirectly) in B then this ordering does not place one before the other.
If A is before B, this model defines that there is an intervening rectangular area or space between A and B if there is a rectangular area or display space C such that A is before C and C is before B.
There is intervening padding or border between A and B if either A is contained in a block-area X which is before B and has non-zero border or padding at the after-edge, or if B is contained in a block area Y which is after A and has non-zero padding or border at the before-edge.
A display space D is consecutively followed by a display space D' if D is before D', and there is no intervening rectangular area, space, border or padding; therefore, D and D' are consecutive.
When several spaces are assigned to be consecutive, they are resolved into one or more spaces as follows:
At the beginning or end of an area-container, any conditional-spaces are suppressed if this has not already been done. At the beginning or end of a block-container, any block-conditional-spaces are suppressed if this has not already been done.
NOTE: Issue: this is to be reworded using the terms "initial" and "final" rather than "beginning" or "end". In addition, we do not have a term "block-container" defined. Is this supposed to be a "block-area" or referring to the "block" that contains another "block"?
Then, if any space is forcing, all non-forcing spaces are suppressed. The forcing spaces are not resolved further, but remain adjacent to one another and thus have an additive effect.
If all spaces are non-forcing, then the eligible spaces shall be those with the maximum precedence, and among these, the space or spaces having the greatest optimum value. All other spaces are suppressed.
If there is more than one eligible space (i.e., with the same optimum value) the resolved space is taken to have the same optimum value as the eligible spaces; its minimum value shall be the greatest of the minimum values of the eligible spaces, and its maximum value shall be the least of the maximum values. All the spaces shall be suppressed and the resolved space replaces the eligible space that comes latest in the tree order (and in particular, to belong to that space's containing rectangular area).
NOTE: Issue: new language to clarify "tree order" is to be developed.
However, a space associated with a line-area (e.g., half-leading) does not merge with any space outside of its immediately containing block.
The padding of a block area never merges with any display space. Also note that by the definition, the presence of non-zero padding (or border) forces display spaces surrounding it to be non-consecutive.
The border or padding associated with a rectangular area may be specified as conditional. For purposes of conditionality, if the border or padding at the before-edge of the area are non-zero and not suppressed, then the initial space within the area's content-rectangle is not at the beginning of an area-container (and so is not suppressed in step 1); similarly if the border or padding at the after-edge of the area are non-zero and not suppressed, then the final space within the area's content rectangle is not at the end of an area-container
Inline-spaces adjust the relative positioning of adjacent inline-areas, in the inline-progression-direction. They are assigned preceding and following inline-areas, either automatically by the formatter (e.g., for word-spacing, letter-spacing, or kerning) or as otherwise specified.
An inline-space is specified by a triple of values (minimum, optimum, maximum) which defines the limits of how the space may be transformed by later processes such as justification. It separates inline-areas in a direct analogy to the way display-space separates block-areas. An inline-space has a start-edge and end-edge, separated in the inline-progression-direction by the inline-space's value. An inline-space value may be negative, which can cause inline-areas to overlap.
Inline-spaces have conditionality and precedence. Conditional inline-spaces are suppressed at the start and end of a line-area. When multiple inline-spaces are assigned to be adjacent, they are resolved in accordance with the space-resolution-rules.
NOTE: It is not the intent of this recommendation to specify a particular algorithm for handling word-spacing, letter-spacing, kerning or any combination thereof. It should be seen as describing a series of constraints that a conforming implementation must satisfy rather than prescribing any particular algorithm. An implementation is free to choose any algorithm that produces output that satisfies the constraints.
An area-container defines a coordinate system for its content, which may be oriented differently from that of its containing area. The orientation of the coordinate system of the contained area-container is derived from the coordinate system of the containing area-container and the "reference-orientation" property on the formatting object that generates the contained area-container. The coordinate systems of the contained area-container is rotated, counter-clockwise, as described in the description of the "reference-orientation" property.
NOTE: See previous issue on Cartesian coordinate spaces. Specify the relationship to the position of "top", "right", etc.
The block-progression-direction of an area-container is derived from its coordinate system and its "writing-mode", and controls the orientation and placement of block-areas in the area-container. The coordinate-system specifies the "top", "bottom", "right", and "left" directions, and the "writing-mode" is specified in terms of these. The mapping of writing-mode to the various directions used in this formatting model is in the description of the "writing-mode" property.
The allocation-rectangle of an area-container has a fixed size in the direction perpendicular to its block-progression-direction, and may have a fixed size in the block-progression-direction, or may grow to accommodate its content.
Area-containers may be directly contained in larger area-containers, block-areas, line-areas or inline-areas, or may be uncontained (e.g., a page area). When an area-container is contained in a larger area-container or block-area, the area-container is treated as if it were a block-area with respect to placement in the larger area-container. When an area-container is contained in a line-area or inline-area, the area-container is treated as if it were an inline-area with respect to placement in the inline-area. Area-containers may directly contain block-areas, line-areas, or smaller area-containers. The latter are treated as if they were a block-areas with respect to placement in the larger area-container.
A block-area's borders and padding are used by the formatter based on the properties of its generating flow object.
A block-area's "writing-mode" is the same as the writing-mode of the immediate containing area-container. This determines its line-progression-direction, which controls the orientation and placement of line-areas in its content-rectangle, and its inline-progression-direction, which is used to determine the direction of writing within contained line-areas.
NOTE: Issue: improve language and add information about the bidi switch.
Block-areas also have a specified "nominal-font-size" and a "nominal-font-family" (a list of font names). Other traits include "line-height" (the nominal distance between the before-edges of successive line-areas), half-leading (one-half of the difference between "line-height" and "nominal-font-size"; it may be negative) and "space-before" and "space-after" specifications. There is also a "line-stacking-strategy" that controls what kind of allocation-rectangle is used for contained line-areas; its value is symbolic and is one of "font-height", "max-height", or "line-height".
One derived trait of a block-area is its nominal-glyph-height, which is the distance from the maximum ascender-height to the maximum descender-depth of the glyph-areas of the nominal-font. This depends entirely on the nominal-font and not on which glyphs (or fonts) are actually present in the block-area.
The allocation-rectangle of a block-area has fixed size in the inline-progression-direction, and varies in the line-progression-direction to accommodate its content, though this may not grow outside the content-rectangle of its containing area. (The "overflow" trait does allow the content to exceed the allocation-rectangle under limited circumstances. The overflowing data is considered decoration and is not considered as part of the layout. Overflowing data may be clipped or may overprint content in other areas.)
A block-area may directly contain line-areas, display-spaces, nested block-areas, and nested area-containers. Area-containers that are nested in block-areas are treated as if they were nested block-areas with the traits of a block-area. Block-areas may be directly contained in area-containers and higher-level block-areas.
NOTE: Issue: language to be cleaned up to make clear that areas can "go outside". Also, this still needs work on containment relationships.
There is no formatting-object that directly corresponds to a line-area. Thus, line-areas are always created by the formatter. A line-area does not have borders and padding.
A line-area derives its inline-progression-direction from its containing block-area, and this is used to determine the direction of writing within a line. It also derives its nominal-font-size, line-height, and half-leading from its containing block-area. Its nominal-font-size is used to derive its nominal-glyph-height.
The allocation-rectangle of a line is determined by the value of the line-stacking-strategy trait: if "font-height", the allocation-rectangle is the nominal-requested-line-rectangle; if "max-height", the allocation-rectangle is the maximum-line-rectangle; if "line-height", the allocation-rectangle is the per-inline-height-rectangle.
NOTE: Issue: improve the language and add information about bidi-override
These are defined as follows:
The nominal-requested-line-rectangle for a line-area is the rectangle bounded in the inline-progression-direction by the content-rectangle of the containing block-area, as modified by typographic properties such as indents, and in the line-progression-direction by its nominal-font-size. It has the same height for each line in a block-area.
The maximum-line-rectangle for a line has the same length as the nominal-requested-line-rectangle in the inline-progression-direction. In the line-progression-direction, it is bounded by the maximum ascender-height and the maximum descender-depth for the actual fonts and inline-areas placed on the line, as raised and lowered by "vertical-align" and other adjustments perpendicular to the inline-progression-direction. Its height may vary depending on the contents of the line-area.
Nominal and Maximum Line Rectangles
The nominal-font is always considered to occur on a line, and, therefore, the maximum-line-rectangle is at least as tall as the nominal-font-size so the maximum-line-rectangle always contains the nominal-requested-line-rectangle.
If the value of leading-method is "per-inline", the line-area's placement will be affected by another rectangle, the per-inline-height-rectangle. This rectangle has the same length as the nominal-requested-line-rectangle in the inline-progression-direction. For each inline-area we determine the "line-height" and font-size for that inline-area and call half the difference the half-leading for that area. The expanded-ascender-height is the ascender-height for the inline-area increased by the half-leading, and the expanded-descender-depth is the descender-depth increased in the opposite direction by the half-leading. As in the definition of the maximum-line-rectangle, this is raised or lowered according to mandated adjustments perpendicular to the baseline. The per-inline-height-rectangle extends in the line-progression-direction from the maximum expanded-ascender-height to the maximum expanded-descender-depth over all the inline-areas in the line-area. Its height may vary depending on the contents of the line-area.
Inline-areas are placed within a line-area relative to a placement-point . This varies during the placement process, but initially the placement-point is a point on the start-edge of its content-rectangle, separated from the before-edge of the nominal-requested-line-rectangle by a distance equal to the ascender-height for the nominal-font.
Line-areas may directly contain inline-areas and inline-spaces. They may be directly contained in block-areas.
[Ednote: We may require special-casing rules for the maximum line rectangle in cases such as "accented" strings in mathematics, or ruby or non-spacing superiors.]
The most common inline-area is a glyph-area, which contains the representation for a character in a particular font. Other examples of inline-areas might include portions of inline mathematical expressions.
Inline-areas have borders and padding, specified by the formatter.
The allocation-rectangle for an inline-area has a fixed size in both dimensions, though this may be specified as a range within which the size may be modified by further processes such as justification. An inline-area also has a font, which is derived from the containing area (if not explicitly set on the inline-area).
Each inline-area has a designated position-point on one of the edges of its allocation-rectangle (typically the start-edge). On the opposite edge of the allocation-rectangle there is another point called the escapement-point, and the vector from the position-point to the escapement-point is called the escapement-vector.
The position-point and escapement-point are assigned according to the writing-system in use (e.g., the glyph baseline in European languages) and the current escapement-progression-direction in effect for bidirectional text, and are used to control placement of inline-areas in a line-area (see the following section). These points may be further adjusted in the case of mixed-language formatting.
A glyph-area is atomic and may contain no other areas. An inline-area may be atomic and contain no other areas, or may be non-atomic and contain other inline-areas or area-containers. Area-containers that are contained in line-areas or inline-areas are treated as if they were inline-areas with the traits of an inline-area. Inline-areas may be directly contained only in line-areas or in other inline-areas. An inline-area consisting of a graphic element has fixed size in both directions.
The formatter constructs a series of inline-areas and assigns these to line-areas according to its line-breaking algorithm.
Inline-areas assigned to a line-area are placed in the line-area in their display order (which may be different from the logical order, when writing-systems are mixed).
Before an inline-area is placed, the placement-point of the line-area may be adjusted by shifts perpendicular to the inline-progression-direction (e.g., for subscript and superscript, or to allow for glyphs with a different natural alignment from the line-area's glyph-alignment mode).
Each inline-area is oriented so that the direction of its escapement-vector matches the escapement-progression-direction, and is placed so that its position-point matches the current placement-point of the line-area. The escapement-point of the inline-area then becomes the new placement-point.
Each inline-space is placed so that its start-edge intersects the current placement-point, and the placement-point is translated in the inline-progression-direction, to the end-edge of the inline-space. Adjacent spaces are combined according to the space-resolution-rules. A conditional-space is not placed if it is at the start-edge of the content-rectangle of a line-area, but may be placed if it follows a non-conditional-space there. Similarly a conditional-space is not placed if it is at the end of a line-area, but may be placed if it precedes a non-conditional-space there.
NOTE: In bidirectional text, the display order is generated according to the basic algorithm for display of bidirectional text in the Unicode Standard, version 2.1.
Preceding and following each line-area assigned to a block-area, the formatter assigns display-spaces, whose conditionality and precedence are determined by the generating flow object.
The values of these display-spaces are determined by the presence or absence of the "minimum-leading" trait and the value of the leading-method trait.
If "minimum-leading" is present then the value of each of the display spaces is equal to half the value of "minimum-leading". If not, and leading-method is not "per-inline", then they are each equal to half of the difference between the "line-height" and nominal-glyph-height, as derived from the containing block-area (if not set explicitly on the inline-area).
If leading-method is "per-inline" and "minimum-leading" is not present, then the value of the first of the display spaces is defined to be the difference between the before-edge of the maximum-line-rectangle and the before-edge of the per-inline-height-rectangle, and the value of the second is the difference between the after-edge of the per-inline-height-rectangle and the after-edge of the maximum-line-rectangle.
NOTE: Issue: the above terminology is not current; however, "line-height", "line-stacking-strategy", etc. all have to be reviewed again to make certain the terminology is correct and consistent.
Each display-space is placed so that its before-edge coincides with the after-edge of the allocation-rectangle of the previous block-area or line-area. Adjacent spaces are combined according to the space-resolution-rules. A conditional-space is not placed if it is at the before-edge of the content-rectangle of an area-container, but may be placed if it follows a non-conditional-space there. Similarly a conditional-space is not placed at the after-edge, but may be placed if it precedes a non-conditional-space there.
Each line-area is placed so that the before-edge of its allocation-rectangle matches the after-edge of the previous display-space, line-area, or block-area, or failing these, the before-edge of the content-rectangle of its containing block-area. The start-edge and end-edges of the allocation-rectangle are placed to coincide with the corresponding edges of the content-rectangle of the containing block-area.
Preceding and following each block-area assigned to an area-container, or nested inside another block-area, the formatter assigns display-spaces, whose height, conditionality and precedence are determined in accordance with its space-before and space-after traits, and by other properties of the generating flow object.
Each display-space is placed so that its before-edge coincides with the after-edge of the allocation-rectangle of the previous block-area or line-area. Adjacent spaces are combined according to the space-resolution-rules. A conditional-space is not placed if it is at the before-edge of the content-rectangle of an area-container, but may be placed if it follows a non-conditional-space there, and similarly for the after-edge.
Each block-area is placed so that the before-edge of its allocation-rectangle matches the after-edge of the previous display-space, line-area, or block-area, or failing that, the before-edge of the content-rectangle of the containing area-container or block-area.
The start-edge of its allocation-rectangle is placed parallel to the start-edge of the content-rectangle of the closest containing area-container, and offset from it by a distance equal to the block-area's "start-indent" minus its start-border and start-padding. Similarly, the end-edge of its allocation-rectangle is placed parallel to the end-edge of the content-rectangle of the closest containing area-container, and offset from it by a distance equal to the block-area's "end-indent" minus its end-border and end-padding.
Area-containers are either uncontained (e.g., a page area) or are contained inside other rectangular areas. When an area-container is directly contained by a block-area or an inline-area, it defines the content-rectangle of that area. When it is contained in another area-container, its position is controlled by the x-position and y-position traits, whose values are distances interpreted in the containing area-container's coordinate system. Optionally, the x-position may have a symbolic value "left" or "right", which positions the area-container at the left or right edge of the containing area-container; similarly the y-position may take a symbolic value "top" or "bottom", which positions the area-container at the top or bottom edge.
During the result tree construction most of the computations required to specify the values of properties are performed. There are, however, a small number that can only be performed after the result tree has been constructed. For example, specifying that the value of the "line-height" property should be the value of "font-size" plus 2pt. In order to achieve this, a small subset of the XSLT expression language may be used in the values of the formatting properties.
NOTE: In the template rules for constructing the result tree these expressions are strings.
The the only datatype is a quantity datatype, which represents lengths and quantities derived from lengths such as areas and volumes. The SI meter is used as the base unit for representing quantities. The name of this unit is "m". Any quantity may be represented as the product of a number and the base unit raised to the power of an integer. The dimension of a quantity is the power to which the base unit is raised when the quantity is so represented. A quantity with dimension 0 is dimensionless. A dimensionless quantity corresponds to the number datatype in XSLT.
NOTE: There is no requirement for an implementation to internally represent quantities using the base unit. An implementation is free to choose some other unit.
The following derived units are defined:
"cm" centimeter (0.01m)
"mm" millimeter (0.001m)
"in" inch (0.0254m)
"pt" point(0.0003527778m)
"pica" pica (0.004233333m)
Issue (pix-em): Are we going to handle pixels and ems as the value of a function?
The expressions are a small subset of the XSLT expression language together with a set of functions.
Issue (nf): Do we need a set of productions for this small subset?
The following operators are permitted:
+
-
*
div
The following functions are defined:
inherited-property-value(). The function argument is the name of a property.
label-end(). For definition see Section 5.18.22: provisional-label-separation.
body-start(). For definition see Section 5.18.23: provisional-distance-between-starts.
Certain property values are described in terms of compound datatypes, in terms of restrictions on permitted number values, or strings with particular semantics.
The compound datatypes, such as space, are represented in the result tree as multiple attributes. The names of these attributes consist of the property name, followed by a period, followed by the component name. For example a the "space-before" property may be specified as:
space-before.minimum="2.0pt" space-before.maximum="4.0pt" space-before.optimum="3.0pt" space-before.precedence="0" space-before.conditionality="0"
The following datatypes are defined:
Issue (pes-need-all): Do we really need all of these?
A string of characters conforming to the XML NMTOKEN definition.
A string of characters conforming to the XML NMTOKEN definition that is unique within the stylesheet.
A string of characters conforming to the XML NMTOKEN definition that matches an ID property value used within the stylesheet.
A boolean value where the allowed values are the strings 'true' and 'false'.
A single unicode character value--whitespace is not allowed.
A signed length value where a 'length' is a real number plus a unit qualification. .
An unsigned length value including zero where a 'length' is a real number plus a unit qualification.
A positive length value not including zero where a 'length' is a real number plus a unit qualification.
A signed integer value which consists of an optional '+' or '-' character followed by a sequence of digits.
An unsigned integer value including zero which consists of a sequence of digits.
An unsigned integer value not including zero which consists of a sequence of digits.
A percentage which is a signed real value (e.g. 45.5 is 455/1000).
A color specification where '#xxxxxx' is an RGB value encoded in hexidecimal or a named color.
Ed. Note: How does other color spaces get encoded?
Ed. Note: What set of "named colors" will we use?
A signed real number which consists of an optional '+' or '-' character followed by a sequence of digits followed by an optional '.' character and sequence of digits.
An unsigned real number including zero which consists of a sequence of digits followed by an optional '.' character and sequence of digits.
An unsigned real number not including zero which consists of a sequence of digits followed by an optional '.' character and sequence of digits.
A compound datatype consisting of a minimum, maximum, and optimum length, and values for precedence and conditionality.
A sequence of characters conforming to a URI value as specified in the URI specification.
Ed. Note: This should refer to the proper specification.
A string of characters conforming to the xml:lang attribute value from XML 1.0
Issue (so-639): Should this not be the ISO 639 3 letter code?
A string of characters conforming to an ISO 3166 country code.
A string of characters identifying a font.
Ed. Note: Shouldn't this have a standardized format?
A list of font names separated by whitespace.
A enumerated list of XML NMTOKEN values.
A sequence of characters.
There are two types of pagination and layout structures: page-masters and page-sequences. Page-masters have the role of describing the intended geometry of the pages or subdivisions of the page. Page-sequences have the role of specifying which "chunks" of decorated content are placed into which instances of page-masters and within a page, which regions of the page. The result of formatting a page-sequence is a sequence of pages (page-level areas).
The formatting object result tree will have as top-level elements some number of page-masters, and some number of page-sequences.
Each fo:page-sequence consists of a fo:sequence-specification, a number of fo:static-content formatting objects, and an fo:flow. For conciseness, the collection of fo:static-content and fo:flow formatting objects will be called "flows." Later versions of this specification will include an optional flow-map formatting object and allow for multiple fo:flows.
The fo:sequence-specification contains a specification of which page-masters are to be used and in what order. Each of its children is either a reference to a page-master or a generator of a sequence of references to page-masters. There are two sequence generators: one which identifies a page-master for the first page and a (repeated) page-master for all other pages and a second which identifies separate page-masters to be used for first, even, odd, blank, and final pages of the document.
A page-master contains specifications for a number of regions on a page. Each region is defined by a "region" formatting object. Each region formatting object has an implicit name and a definite width, height, and position.
For the present version of this recommendation, a page-master will consist of up to five regions: "region-body" and four other regions, one on each side of the body. To allow the side regions to correspond to the current writing-mode, these regions are named "region-before" (which corresponds to "header" in lr-tb writing-mode), "region-after" (which corresponds to "footer" in a lr-tb writing-mode), "region-start" (which corresponds to a "left-sidebar" in lr-tb writing-mode) and "region-end" (which corresponds to a "right-sidebar" in lr-tb writing-mode). It is expected, that a future version of the recommendation will introduce a mechanism that allows a page-master to contain an arbitrary number of arbitrarily sized and positioned regions.
Fo:static-content and fo:flow are formatting objects which contain a number of block-level flow objects. Each such flow has a name, and no two fo:flow or fo:static-content formatting objects in the same page-sequence may have the same name.
The flow mapping rules define how one or more fo:static-content or fo:flow formatting objects are associated to one or more regions in the page-masters. The default flow mapping rule (and the only one for the Version 1.0 of this Recommendation) is that a named flow will be bound to the region whose implicit name is the same as the name of the flow.
In later versions, a flow-map object may override the default rule in specified cases, to allow flows to be associated to regions differently, through some syntax and semantics to be designed later. Uniqueness of names guarantees that under the default flow mapping rule, the assignment of fo:flow and fo:static-content formatting objects to regions is one-to-one.
A page-sequence generates a sequence of page-level area-containers. This sequence of area-containers (and nested area-containers and other content) contains block areas resulting from the contents of the various fo:static-content and fo:flow formatting objects which are distributed (efficiently and in order) to appropriate area-containers in accordance with the flow mapping rules. Enough pages are generated to accommodate the content in all active flows; additionally a page may be generated to fill out a sequence.
An overview of the block formatting objects is to be developed.
An overview of the inline formatting objects is to be developed.
An overview of the formatting objects for tables is to be developed.
An overview of the formatting objects for lists is to be developed.
An overview of the link and multi formatting objects is to be developed.
Conditional regions reside within fixed regions, and borrow space from them at either the top or bottom of the region, growing in the block-progression-direction (so that the line-length does not get modified). These regions have a precedence controlling the order of regions coming from the same edge, and limits on how much they can grow, and other rules ("do not push the reference off the page").
Such regions generate an area-container within each area-container generated by the containing region. These "conditional" area-containers will have size zero unless there is an associated flow or special content assignment, in which case block-areas resulting from such content are assigned (efficiently and in order) to these area-containers, along with children of the region itself (e.g., a footnote separator), within the constraints of the generating conditional region.
NOTE: Issue: this language needs to be reviewed and modified.
Otherwise, children of the region-master do not generate rectangular areas.
A zero-sized area-container is not an "intervening" area in the sense of section 3.2.3.
NOTE: Issue: does the containing area-container shrink? I.e. when something is positioned absolutely with regard to an area-container what is it relative to? If there is mixed content, we need to look at the model. If not, what generates the middle area container?)
Some regions will have an implicit conditional float region at the top and conditional footnote region at the bottom.
When an fo:footnote formatting object appears in a flow, it generates at least two areas. One area is an inline-area to accommodate the footnote citation. This inline-area is generated in sequence with the areas generated by the flow-objects preceding and following the fo:footnote flow-object. It is, therefore, assigned to the area-container generated by the region associated to the flow in which the fo:footnote occurs. The second area that is generated by the fo:footnote flow-object is placed in the area-container generated by a footnote region, in particular, the footnote region that is within the region in which the footnote reference was placed. The actual areas generated by the content of the fo:footnote flow-object are determined by the flow objects that comprise that content. For example, if one wanted to format the footnote with a label and an indented body, then one could use the fo:list-block flow-object to format the content of the footnote.
An fo:float formatting object may appear in a flow, and its contents will be assigned to the float region within the same region associated to the flow. The first of the block-areas generated by these contents should occur as a part of the same page-level area-container which contains the rectangular areas generated by formatting objects just before or just after the fo:float formatting object.
NOTE: Future versions will describe these behaviors as special cases of a more general synchronization mechanism using concepts like flows in a manner to be designed later.
The fo:bidi-override inline formatting object is used where it is necessary to override the default Unicode-bidirectionality algorithm writing-direction for different (or nested) inline scripts in mixed-language documents.
The fo:block formatting object is commonly used for formatting paragraphs, titles, headlines, figure and table captions, etc.
The fo:character flow object represents a character that is mapped to a glyph for presentation.
The fo:display-graphic flow object is used for a block-level graphic.
The fo:display-included-container flow object is used to generate a block-level area container.
The fo:display-rule flow object is used for a block-level rule (graphic-line).
The fo:display-sequence formatting object is used to specify inherited properties for a group of block-level formatting objects.
The fo:first-line-marker specifies formatting properties for the first line of an fo:block.
The fo:float flow object is used to gather content of a floating figure, table, or sidebar.
The fo:flow formatting object is used to gather flow objects that form the content that is to be bound to regions on instances of page-masters. Formatting the fo:flow formatting object distributes its content into the instances of page-masters generated by the fo:page-sequence which is the parent of the fo:flow formatting object.
The fo:footnote formatting object is used to gather the components of a floating note.
The fo:footnote-citation formatting object is used to specify the properties that affect the formatting of a footnote citation.
The fo:inline-graphic flow object is used for an inline graphic.
The fo:inline-included-container flow object is used to generate an inline area container.
The fo:inline-rule flow object is used for an inline rule (graphic-line).
The fo:inline-sequence formatting object is used to specify inherited properties for a group of inline formatting objects.
The fo:layout-master-set is a wrapper around all page-masters used in the document.
The fo:list-block flow object is used to format a list item or a list.
The fo:list-item formatting object contains the label and the body of an item in a list.
The fo:list-item-body formatting object contains the content of the body of a list item.
The fo:list-item-label formatting object contains the content of the label of a list item; typically used to either enumerate, identify or adorn the list-item's body.
The fo:multi-case is used to embed flow objects, that the parent fo:multi-switch can choose to either show or hide.
The fo:multi-properties is used to switch between two or more property sets that are associated with a given portion of content.
The fo:multi-property-set is used to specify an alternative set of formatting properties that, dependent on a DOM state, are applied to the content.
The fo:multi-switch is used to switch between two or more sub-trees of formatting objects.
The fo:multi-toggle is used within an fo:multi-case to switch to another fo:multi-case.
The fo:page-number formatting object is used to obtain the current page-number.
The fo:page-number-citation is used to reference the page-number for the page containing the cited formatting object.
The fo:page-sequence formatting object describes the binding of a collection of flows to a sequence of instances of page-masters. Formatting this object generates a sequence of page-level area-containers. The details of the binding depend on the type of flow, whether it is an fo:flow or an fo:static-content. The binding also depends on the overflow properties on the regions on the page-masters.
The fo:region-after formatting object specifies the placement of the region of an fo:simple-page-master that corresponds to the footer in lr-tb writing-mode.
The fo:region-before formatting object specifies the placement of the region of an fo:simple-page-master that corresponds to the header in lr-tb writing-mode.
The fo:region-body specifies the placement of a region within an fo:simple-page-master that corresponds to the body of a page. Typically, the flowing content of an fo:page-sequence is distributed into fo:region-body's of a series of successive instances of page-masters, thereby generating the pages of the fo:page-sequence.
The fo:region-end formatting object specifies the placement of the region of an fo:simple-page-master that corresponds to the right sidebar in lr-tb writing-mode.
The fo:region-start formatting object specifies the placement of the region of an fo:simple-page-master that corresponds to the left sidebar in lr-tb writing-mode.
The fo:root node is the top node of an XSL result tree. This tree is composed of formatting objects.
The fo:sequence-specification formatting object describes a potential sequence of instances of page-masters. The process of formatting the flows that are in the parent fo:page-sequence into these instances of page-masters yields the resulting pages that are generated by the parent fo:page-sequence.
The fo:sequence-specifier-alternating formatting object is used within an fo:sequence-specification to represent a potential subsequence of instantiations of page-masters. It describes a sequence of page-master instances that are common to word processor documents (both print and online). This sequence references different page-masters for the first page, for even pages, for odd pages, for blank even pages and for a last even or odd page.
The fo:sequence-specifier-repeating formatting object is used within an fo:sequence-specification to represent a potential subsequence of instantiations of page-masters. It describes a sequence of page-master instances that are common to word processor documents (both print and online). This sequence references one page-master for the first page followed by a repeating sequence of instances of a second page-master for the remaining pages in the sequence.
The fo:sequence-specifier-single formatting object is used within an fo:sequence-specification to represent a potential instantiation of a single particular page master.
The fo:simple-link is used for representing the start resource of a simple link.
The fo:simple-page-master is a pre-defined page-master for pages that have a simple single or multi-column body and up to four other regions corresponding to headers, footers, a start sidebar and an end sidebar.
The fo:static-content formatting object is used to gather content to be assigned to (placed into) a given area or repeated in a like-named areas on successive pages.
The fo:table flow object is used for formatting the tabular material of a table.
The fo:table-and-caption flow object is used for formatting a table together with its caption.
The fo:table-body formatting object is used to contain the content of the table body.
The fo:table-caption formatting object is used to contain block-level formatting objects containing the caption for the table.
The fo:table-cell formatting object is used to group content to be placed in a table-cell.
The fo:table-column formatting object specifies characteristics applicable to table cells that have the same column and span.
The fo:table-footer formatting object is used to contain the content of the table footer.
The fo:table-header formatting object is used to contain the content of the table header.
The fo:table-row formatting object is used to group table-cells into rows.
Common use:
This is the top node of the formatting object tree. It holds an fo:layout-master-set formatting object (which holds all masters used in the document) and one or more fo:page-sequence objects. Each fo:page-sequence represents a sequence of pages that result from formatting the content within the fo:page-sequence.
NOTE: A document can contain multiple fo:page-sequences. For example, each chapter of a document could be a separate fo:page-sequence; this would allow chapter specific content, such as the chapter title, to be placed within a header or footer.
Area type
This object does not create any areas.
Distribution of content:
The distribution of the contents of the fo:root are described in the descriptions of fo:layout-master-set and fo:page-sequence.
Properties:
Common use:
The fo:page-sequence formatting object is used to specify the binding of a collection of flows to a sequence of instances of page-masters. Formatting this object generates a sequence of page-level area-containers. The sequence of instances of page-masters is generated by the fo:sequence-specification child of the fo:page-sequence. There are two kinds of flows that can be bound to the instances of page-masters: (1) fo:static-content flows which are restarted every time the flow is bound to a new instance of a page master and (2) fo:flow flows which are distributed across a sequence of pages until the flow is exhausted.
The binding of flows to instances of page-masters is specified by the flow-map. In version 1.0 of XSL, the flow map is implicit and the "flow-name" property of the flow specifies to which region that flow is bound. The region names all begin with the prefix, "xsl-" and the suffix corresponds to the suffix of the element name of the region formatting objects. For example, a flow destined for the region that has the element name, "region-body" would have its flow-name property equal to "xsl-body". In future versions of XSL, the flow map is expected to become an explicit formatting object.
Area type
The fo:page-sequence formatting object does not directly generate any areas. It determines the binding of its flow children into the instances of page-master formatting objects that are generated from its fo:sequence-specification child. Both the creation of the instances of the page-masters and the distribution of the content of the flows does generate areas as described by the page-master formatting object and the flow objects which can reside in the flow children of this formatting object.
Distribution of content:
This object has no direct presentation content. The fo:flow and fo:static-content formatting objects hold the content to be placed in the generated pages. This content is distributed into the regions on the instances of page-master formatting objects by the formatter, thereby generating page-level area-containers or pages.
The fo:sequence-specification represents a potential sequence of instances of page masters; how many instances are generated depends on the fo:sequence-specification and the distribution of the flows. Provided that there are enough potential instances of page-masters to hold all the content, the distribution of the content should generate the least number of page instances necessary to hold all the content and to meet the constraints on the distribution of the content. If the fo:sequence-specification generates a bounded sequence of potential instances of page-masters, then as much content as can be shall be distributed into the full possible sequence of instances of page-masters. This distribution shall be consistent with the constraints on the distribution.
Overflow
How much content can be distributed into an instance of a page-master depends on the setting of the "overflow" property on the region of the master to which the given content flow is bound. If the value of the "overflow" property is "scroll", then the entire content of the flow can be distributed into that instance of the region. If the value of the "overflow" property is "visible" or "hidden", then only as much content as fits (in the block progression direction) into the viewport/area-container generated by that region can be distributed into that instance of the page-master. If the value of the "overflow" property is "hidden", any content which extends beyond the viewport/area-container generated by the region will be clipped to the rectangle defined by the "clip" property. If the value of the "overflow" property is "visible", any content which extends beyond the viewport/area-container generated by the region will be clipped to the page size.
The "initial-page-number" property on the fo:page-sequence formatting object is used to determine the page number value for the first page in the page-sequence; subsequent pages are numbered consecutively in increasing order. The "format" property is used to format the number into a string form and this form is used as the default value of the fo:page-number flow object.
Properties:
Common use:
The fo:sequence-specification formatting object is used to specify the generation of a sequence of potential instances of page-masters. This sequence of instances of page-masters are the receptacles into which the flows in the parent fo:page-sequence are bound. Formatting the flows that are in the parent fo:page-sequence into these instances of page-masters yields the resulting pages that are generated by the parent fo:page-sequence.
The fo:sequence-specification contains a sequence of sequence-specifiers. There are sequence-specifiers for instances of a single page-master, and there are sequence-specifiers which generate two kinds of repeating (sub-)sequences of instances of page-masters.
There are several ways of specifying the potential instances of page masters. One can specify a sequence of references to particular, single page-masters. This yields a bounded sequence of potential instances of page-masters. Alternatively, one can specify an unbounded (sub-) sequence of instances of page-masters using one of fo:sequence-specifier-repeating and fo:sequence-specifier-alternating. Finally one can intermix the two kinds of sequence specifiers.
Area type
The fo:sequence-specification formatting object does not directly generate any areas. The fo:sequence-specification is a generator for a potential sequence of instances of page-masters. The fo:page-sequence that is the parent of the fo:sequence-specification determines the binding of the flows that are the children of that fo:page-sequence to the instances of page-masters generated by the fo:sequence-specification.
Distribution of content:
This object has no content. The fo:flow and fo:static-content objects hold the content to be placed in the generated pages. These are held by the fo:page-sequence and are assigned to regions (or region-classes) on the page via an (implicit) fo:flow-map.
Properties:
Common use:
Used to represent an potential instantiation of a single particular page master within the sequence of potential page-master instantiations determined by the fo:sequence-specification in which the fo:sequence-specifier-single occurs.
Area type
The fo:sequence-specifier-single does not directly generate any areas. The fo:sequence-specifier-single is a reference to the fo:simple-page-master which the same master-name as the master-name on the fo:sequence-specifier-single.
If the binding of the flows in the fo:page-sequence which is the ancestor of the fo:sequence-specifier-single causes the fo:sequence-specifier-single to be used, then the referenced fo:simple-page-master is instantiated as described in the definition of the fo:simple-page-master.
Properties:
Common use:
The fo:sequence-specifier-alternating formatting object is used to specify the generation of a sequence instances of page-masters for a typical book chapter (or equivalent). This sequence references different page-masters for the first page, for even pages, for odd pages, for blank even pages and for a last even or odd page.
Area type
The fo:sequence-specifier-alternating does not directly generate any areas. The fo:sequence-specifier-alternating generates a sequence of references to one of six fo:simple-page-masters.
The property "page-master-first" has the name of the page-master formatting object for the first page-master instance in the sequence. The sequence then continues alternating instances of the page-masters named by the "page-master-even" and "page-master-odd" properties. If in the distribution the content in the flows in the fo:page-sequence which is using this fo:sequence-specifier-alternating formatting object causes a page break from an odd page to another odd page, then an instance of the page-masters named by the "page-master-blank-even" property is generated between the two odd pages. For the last page-master instance generated in the sequence, either the page-master named by the "page-master-last-even" and "page-master-last-odd" property is used depending on whether that page is even or odd.
For all the page-master instances that are generated by the binding of the flows in the fo:page-sequence which is the ancestor of the fo:sequence-specifier-alternating, the referenced fo:simple-page-master is instantiated as described in the definition of the fo:simple-page-master.
NOTE: Issue: are all properties required? If not how do they default?
Issue: The way the text is written you don't get a last page master blank even for the last page sequence.
Distribution of content:
This object has no content. The fo:flow and fo:static-content objects that are children of the fo:page-sequence ancestor of the fo:sequence-specifier-alternating hold the content to be placed in the generated pages. These are assigned to regions on the instances of the page-masters via the (implicit) flow-map.
Properties:
Common use:
The fo:sequence-specifier-alternating formatting object is used to specify the generation of a sequence instances of page-master formatting objects for a simple document (such as a memo). This sequence references one page-masters for the first page followed by a repeating sequence of instances of a second page-master for the remaining pages in the sequence.
Area type
The fo:sequence-specifier-repeating formatting object generates no area directly. The fo:sequence-specifier-repeating generates a sequence of references to one of two fo:simple-page-masters.
The property "page-master-first" has the name of the page-master for the first page-master instance in the sequence. The sequence then continues with instances of the page-master named by the "page-master-repeating" property.
For all the page-master instances that are generated by the binding of the flows in the fo:page-sequence which is the ancestor of the fo:sequence-specifier-repeating, the referenced fo:simple-page-master is instantiated as described in the definition of the fo:simple-page-master.
NOTE: Issue: are all properties required? If not how do they default?
Distribution of content:
This object has no content. The fo:flow and fo:static-content objects that are children of the fo:page-sequence ancestor of the fo:sequence-specifier-repeating hold the content to be placed in the generated pages. These are assigned to regions on the instances of the page-masters via the (implicit) flow-map.
Properties:
Common use:
The fo:layout-master-set is a wrapper around all page-masters used in the document.
Area type
This formatting object does not result in any area.
Properties:
Common use:
The simple-page-master defines a bounded plane on which are positioned up to five subsidiary viewports, called regions. These regions correspond to the body of a document, the region-before (or header), the region-after (or footer), the region-start (or left sidebar) and the region-end (or right sidebar.
NOTE: Issue: the last sentence should be made into a note and state that it is an example for left-to-right top-to-bottom writing mode.
It also provides a title, which may, for example, be presented in a browser's title bar.
NOTE: Issue: how is the title produced?
The fo:simple-page-master shall be allowed only within the fo:layout-master-set branch of a formatting object tree.
NOTE: The simple-page-master is intended for systems that wish to provide a simple page layout facility. Future versions of this specification will support more complex page layouts constructed using the fo:page-master formatting object.
Area type
Instantiating a simple-page-master produces an area-container, called a page-level area-container or page, that represents the bounded plane mentioned above. Instantiating the content of the simple-page-master generates up to 5 of the following area-containers: an area-container for region-body, an area-container for region-before, an area-container for region-after, an area-container for region-start, and an area-container for region-end. These are discussed under the appropriate region flow object.
The size of the page-level area-container is determined using the "page-height" and "page-width" properties. Note these properties may be set using the shorthand property, "size". If the "page-height" and "page-width" properties have explicit values, they are used to set the corresponding trait on the page area-container. If the "page-height" and/or "page-width" are set to "auto", the page will attempt to size itself to the media. If the media has a fixed size, then the size of the media is used. If the media is dynamic, such as a browser window, then the current size of the window will be used.
The values of the margin properties determine the size of the content-rectangle within the page-level area-container. "margin-top", "margin-bottom", "margin-left" and "margin-right" are used to indent the page-level area-container content-rectangle from the corresponding edge of the page.
NOTE: Issue: Need to define what "top" etc are in terms of.
Trait derivation
Currently, borders and padding are not allowed with a page area. The remaining traits on the page area are set according to normal rules for determining the values of traits.
Distribution of content:
A simple-page-master does not have any "content in the usual sense" to be distributed. Its content is the formatting objects which specify the regions into which the simple page is divided. Content in the usual sense is placed into instances of a simple-page-master as a result of binding the flows in an fo:page-sequence to the instances of page-master formatting objects generated from the fo:sequence-specification.
Properties:
Common use:
Used in constructing a simple-page-master. This region defines a viewport that is located in the "center" of the fo:simple-page-master. Typically, the flowing content of an fo:page-sequence is distributed by the formatter into a series of successive fo:region-body's in successive instances of page-masters, thereby generating the pages of the fo:page-sequence. The visibility of the content that is bound to the region by an fo:page-sequence is controlled by the overflow property on the region.
NOTE: The body region should be sized and positioned within the content-rectangle of the fo:simple-page-master so that there is room for the content that will be distributed into the body and for any desired side regions, that is, fo:region-before, fo:region-after, fo:region-start and fo:region-end's that are to be placed on the same page. The spacing between the last four regions and the fo:region-body is determined by subtracting the relevant "extent" property on the side regions from the corresponding "margin-x" property on the fo:region-body.
Area type:
The fo:region-body formatting object generates one viewport and one area-container. The position and size of this viewport is determined by the values of the "margin-top", "margin-bottom", "margin-left" and "margin-right" properties relative to content-rectangle of the area-container generated by fo:simple-page-master.
The area-container generated by fo:region-body lies on a canvas underneath the above viewport. The "reference-orientation" property is used to orient the coordinate system of the area-container generated by the fo:region-body relative to the coordinate system of the area-container generated by fo:simple-page-master (and, therefore, the viewport positioned in that latter coordinate system).
The size of the area-container depends on the setting of the "overflow" property on the region. If the value of that property is "auto", "hidden" or "visible" then the size of the area-container is the same as the size of the viewport. If the value of the "overflow" property is "scroll", the size of the area-container is equal to the size of the viewport in the inline-progression-direction in the "writing-mode" for the region and is long enough in the block-progression-direction to hold the distribution of all the content bound to the region.
Types of areas when "column-count" is greater than 1:
If the "column-count" property has a value other than 1, for example, N, then N additional area-containers are generated inside the area-container generated by the fo:region-body. These N area-containers are the "column area-containers." The size of each of these area-containers in the inline-progression-direction is determined by subtracting (N-1) times the computed value of the "column-gap" property from the size of the area-container generated by the fo:region-body in the inline-progression-direction and dividing that result by N. Using 'body-in-size' for the size of the area-container generated by the fo:region-body in the inline-progression-direction and 'column-in-size' the size of the column area-containers in the inline-progression-direction, the formula is:
column-in-size = (body-in-size - (N - 1)*column-gap)/N
The size of the column area-containers in the block-progression-direction is the same as the size of the area-container generated by the fo:region-body in the block-progression-direction.
The column area-containers are positioned within the area-container generated by the fo:region-body as follows: The first column is positioned with its before and start edges coincident with the before and start edges of the area-container generated by the fo:region-body. The Jth column area-container is positioned with its before edge coincident with the before edge of the area-container generated by the fo:region-body and with is start edge at (J times column-in=size plus column-gap) in the inline-direction. This results in the end edge of the Nth column area-container being coincident with the end edge of the area-container generated by the fo:region-body.
NOTE: Issue: Interaction between scroll and column-count > 1.
Distribution of content:
An fo:region-body does not have any "content in the usual sense" to be distributed. Content in the usual sense is placed into instances of an fo:region-body as a result of binding the flows in an fo:page-sequence to the instances of an fo:simple-page-masters which have an fo:region-body. If the body region is subdivided into more than one column, then the distribution of the content is into the column area-containers beginning with the column area-container adjacent to the start edge of the area-container generated by the fo:region-body and continuing, in sequence with the next column area-container in the inline-direction until all the column area-containers have received a distribution consistent with the constraints specified by the properties on the content being distributed. This is sometimes called, "snaking columns".
Properties:
Common use:
Used in constructing a simple-page-master. This region defines a viewport that is located on the "before" side of fo:region-body region. In lr-tb writing-mode, this region corresponds to the header region. The visibility of the content that is bound to the region by an fo:page-sequence is controlled by the "overflow" property on the region.
NOTE: Issue: the "before" side is in terms of the writing mode of the fo:simple-page-master and not fo:region-body.
Area type:
The fo:region-before formatting object generates one viewport and one area-container. This viewport is positioned with its before edge coincident with the before edge of the content-rectangle of the area-container defined by the parent fo:simple-page-master. In the direction perpendicular to the before edge, the size of the viewport is determined by the "extent" property on the fo:region-before formatting object.
In the direction parallel to the before edge, the size of the viewport is determined by the "precedence" properties on the fo:region-before. If the value of the "precedence" property is "true", then the region-before viewport extends up to the start and after edges of the content rectangle of the page-level area-container. In this case, the area generated by the region-before acts like a float into areas generated by the region-start (respectively, the region-end). If the value of the "precedence" property on the fo:region-before is "false", then these adjacent regions float into the area generated by the fo:region-before and the extent of the fo:region-before is (effectively) reduced by the incursions of the adjacent regions.
The area-container generated by fo:region-before lies on a canvas underneath the above viewport. The "reference-orientation" property is used to orient the coordinate system of the area-container generated by the fo:region-before relative to the coordinate system of the area-container generated by fo:simple-page-master (and, therefore, the viewport positioned in that latter coordinate system).
The size of the area-container depends on the setting of the "overflow" property on the region. If the value of that property is "auto", "hidden" or "visible" then the size of the area container is the same as the size of the viewport. If the value of the "overflow" property is "scroll", the size of the area-container is equal to the size of the viewport in the inline-progression-direction in the "writing-mode" for the region and is long enough in the block-progression-direction to hold the distribution of all the content bound to the region.
Distribution of content:
An fo:region-before does not have any "content in the usual sense" to be distributed. Content in the usual sense is placed into instances of an fo:region-before as a result of binding the flows in an fo:page-sequence to the instances of fo:simple-page-masters which have an fo:region-before.
Properties:
Common use:
Used in constructing a simple-page-master. This region defines a viewport that is located on the "after" side of fo:region-body region. In lr-tb writing-mode, this region corresponds to the footer region. The visibility of the content that is bound to the region by an fo:page-sequence is controlled by the "overflow" property on the region.
NOTE: Issue: the "after" side is in terms of the writing-mode of the fo:simple-page-master and not fo:region-body.
Area type:
The fo:region-after formatting object generates one viewport and one area-container. This viewport is positioned with its after edge coincident with the after edge of the content-rectangle of the area-container defined by the parent fo:simple-page-master. In the direction perpendicular to the after edge, the size of the viewport is determined by the "extent" property on the fo:region-after formatting object.
In the direction parallel to the after edge, the size of the viewport is determined by the "precedence" properties on the fo:region-after. If the value of the "precedence" property is "true", then the region-after viewport extends up to the start and after edges of the content rectangle of the page-level area-container. In this case, the area generated by the region-after acts like a float into areas generated by the region-start (respectively, the region-end). If the value of the "precedence" property on the fo:region-after is "false", then these adjacent regions float into the area generated by the fo:region-after and the extent of the fo:region-after is (effectively) reduced by the incursions of the adjacent regions.
The area-container generated by fo:region-after lies on a canvas underneath the above viewport. The "reference-orientation" property is used to orient the coordinate system of the area-container generated by the fo:region-after relative to the coordinate system of the area-container generated by fo:simple-page-master (and, therefore, the viewport positioned in that latter coordinate system).
The size of the area-container depends on the setting of the "overflow" property on the region. If the value of that property is "auto", "hidden" or "visible" then the size of the area-container is the same as the size of the viewport. If the value of the "overflow" property is "scroll", the size of the area-container is equal to the size of the viewport in the inline-progression-direction in the "writing-mode" for the region and is long enough in the block-progression-direction to hold the distribution of all the content bound to the region.
Distribution of content:
An fo:region-after does not have any "content in the usual sense" to be distributed. Content in the usual sense is placed into instances of an fo:region-after as a result of binding the flows in a fo:page-sequence to the instances of fo:simple-page-masters which have an fo:region-after.
Properties:
Common use:
Used in constructing a simple-page-master. This region defines a viewport that is located on the "start" side of fo:region-body region. In lr-tb writing-mode, this region corresponds to a left sidebar. The visibility of the content that is bound to the region by an fo:page-sequence is controlled by the "overflow" property on the region.
NOTE: Issue: the "start" side is in terms of the writing mode of the fo:simple-page-master and not fo:region-body.
Area type:
The fo:region-start formatting object generates one viewport and one area-container. This viewport is positioned with its start edge coincident with the start edge of the content-rectangle of the area-container defined by the parent fo:simple-page-master. In the direction perpendicular to the start edge, the size of the viewport is determined by the "extent" property on the fo:region-start formatting object.
In the direction parallel to the start edge, the size of the viewport is determined by the "precedence" properties on the adjacent fo:region-before and the fo:region-after. If the value of the "precedence" property is "false", then the region-start viewport extends up to the before (or, respectively, after) edge of the content-rectangle of the page-level area-container. In this case, the area generated by the region-start acts like a float into areas generated by the region-before (respectively, the region-after). If the value of the "precedence" property on the adjacent regions is "true", then these adjacent regions float into the area generated by the fo:region-start and the "extent" of the fo:region-start is (effectively) reduced by the incursions of the adjacent regions with the value of the "precedence" property equal to "true".
The area-container generated by fo:region-start lies on a canvas underneath the above viewport. The "reference-orientation" property is used to orient the coordinate system of the area-container generated by the fo:region-start relative to the coordinate system of the area-container generated by fo:simple-page-master (and, therefore, the viewport positioned in that latter coordinate system).
The size of the area-container depends on the setting of the "overflow" property on the region. If the value of that property is "auto", "hidden" or "visible" then the size of the area container is the same as the size of the viewport. If the value of the "overflow" property is "scroll", the size of the area-container is equal to the size of the viewport in the inline-progression-direction in the "writing-mode" for the region and is long enough in the block-progression-direction to hold the distribution of all the content bound to the region.
Distribution of content:
An fo:region-start does not have any "content in the usual sense" to be distributed. Content in the usual sense is placed into instances of an fo:region-start as a result of binding the flows in an fo:page-sequence to the instances of fo:simple-page-masters which have an fo:region-start.
Properties:
Common use:
Used in constructing a simple-page-master. This region defines a viewport that is located on the "end" side of fo:region-body region. In lr-tb writing-mode, this region corresponds to a right sidebar. The visibility of the content that is bound to the region by an fo:page-sequence is controlled by the "overflow" property on the region.
NOTE: Issue: the "end" side is in terms of the writing mode of the fo:simple-page-master and not fo:region-body.
Area type:
The fo:region-end formatting object generates one viewport and one area-container. This viewport is positioned with its end edge coincident with the end edge of the content-rectangle of the area-container defined by the parent fo:simple-page-master. In the direction perpendicular to the end edge, the size of the viewport is determined by the "extent" property on the fo:region-end formatting object.
In the direction parallel to the end edge, the size of the viewport is determined by the "precedence" properties on the adjacent fo:region-before and the fo:region-after. If the value of the "precedence" property is "false", then the region-end viewport extends up to the before (or, respectively, after) edge of the content-rectangle of the page-level area-container. In this case, the area generated by the region-end acts like a float into areas generated by the region-before (respectively, the region-after). If the value of the "precedence" property on the adjacent regions is "true", then these adjacent regions float into the area generated by the region-end and the extent of the region end is (effectively) reduced by the incursions of the adjacent regions with the value of the "precedence" property equal to "true".
The area-container generated by fo:region-end lies on a canvas underneath the above viewport. The "reference-orientation" property is used to orient the coordinate system of the area-container generated by the fo:region-end relative to the coordinate system of the area-container generated by fo:simple-page-master (and, therefore, the viewport positioned in that latter coordinate system).
The size of the area-container depends on the setting of the "overflow" property on the region. If the value of that property is "auto", "hidden" or "visible" then the size of the area-container is the same as the size of the viewport. If the value of the "overflow" property is "scroll", the size of the area-container is equal to the size of the viewport in the inline-progression-direction in the "writing-mode" for the region and is long enough in the block-progression-direction to hold the distribution of all the content bound to the region.
Distribution of content:
An fo:region-end does not have any "content in the usual sense" to be distributed. Content in the usual sense is placed into instances of an fo:region-end as a result of binding the flows in an fo:page-sequence to the instances of fo:simple-page-masters which have an fo:region-end.
Properties:
Common use:
The content of the fo:flow formatting object is a sequence of flow objects that forms one unit of content distribution, such as an article, a chapter, or a section. It is to be presented in a sequence of instances of regions on one or more instances of page-masters generated by an fo:page-sequence.
Area type:
This object does not directly create an area. The formatting of the content of the fo:flow will generate areas that are placed in the areas-containers generated by the formatting of the fo:page-sequence of which this formatting object is a child
Distribution of content:
The (implicit) flow-map determines the binding of the content of the fo:flow to a sequence of instances of regions (or more accurately the area-containers generated by those regions). Those instances of regions with the same name as the value of "flow-name" property of the fo:flow are the targets of the distribution of the content. (The names of the regions specified with the fo:region-X formatting objects are given in the description of the fo:page-sequence formatting object.
The content of the fo:flow formatting object is distributed into the sequence of instances of regions with the same name such that the distribution is consistent with the constraints specified by the flow objects and their properties that make up that content. This sequence of instances of regions are the smallest such sequence that is sufficient to hold the content of the fo:flow formatting object consistent with the constraints on that content. Note that if the fo:sequence-specification on the parent fo:page-sequence generates a bounded sequence of instances of page-masters, then it may not be possible to distribute all the content of the fo:flow formatting object.
The ordering of the instances of regions with the same name is determined by two things: (1) the ordering of the instances of page-masters on which the region instances reside (which is determined by the fo:sequence-specifier of the fo:page-sequence that is the parent of the fo:flow), and (2) the ordering of column area-containers within those instances of regions. The latter ordering is defined by the fo:region-body formatting object.
The content of an fo:flow formatting object is distributed at most once in the formatting of a given fo:page-sequence. It will not be distributed at all if there is no correspondingly named region in any of the instances of page-masters generated by the fo:sequence-specifier in the parent of the fo:flow formatting object.
Properties:
Common use:
The fo:static-content formatting object shall not be allowed within the content of any formatting object except a page-sequence. It must precede all fo:flow objects in a given page-sequence. The fo:static-content formatting object holds a sequence or a tree of formatting objects that is to be presented in a single region or repeated in like-named regions on one or more pages in the page-sequence. Its common use is for repeating or running headers and footers.
The fo:static-content differs from the fo:flow formatting object in only one respect, the content of an fo:flow formatting object is distributed at most once across a sequence of instances of regions but, the content of an fo:static-content formatting object is replayed from the beginning for each target region into which it is distributed and it is distributed into every instance of the region with the same name within a given fo:page-sequence.
Area type:
This object does not directly create an area. The formatting of the content of the fo:flow will generate areas that are placed in the areas-containers generated by the formatting of the fo:page-sequence of which this formatting object is a child
Distribution of content:
The (implicit) flow-map determines the binding of the content of the fo:static-content to a region (or more accurately the area-containers generated by that region). Those instances of regions with the same name as the value of "flow-name" property of the fo:static-content are the targets for the distribution of the content. (The names of the regions specified with the fo:region-X formatting objects are specified in the description of the fo:page-sequence formatting object.
The same content, starting at the beginning of the sequence of content flow objects for each distribution, is distributed to each such instance of regions with the same name. Note that different page-masters may have differently sized (and positioned) variants of the region even though all these regions are given the same name. Hence, the appearance of the content and even which portion of it is visible may differ for these different instances of regions.
The content of the fo:static-content formatting object is distributed into an instance of the region with the same name (or more accurately the area-container generated by that region) such that the distribution is consistent with the constraints specified by the flow objects and the properties applicable to them that make up that content.
Note that if the area-container generated by the instance of the region with the same name is not big enough to hold all areas generated by formatting the content of the fo:static-content formatting object, then some of that content may be truncated.
Properties:
Common use:
The fo:block formatting object is commonly used for formatting paragraphs, titles, headlines, figure and table captions, etc.
Area type
The fo:block formatting object normally causes the formatter to generate one or more block-areas. The height of each such block-area is determined by the heights of the line- and block-areas it contains together with the resolved spaces before, after, and between those areas. The width of the content rectangle is determined in the usual manner for block-level areas.
Content distribution
The content of the fo:block flow object is distributed as a result of distributing the content of the immediately containing flow object (or the fo:static-content formatting object or the fo:flow formatting object.)
The content of the fo:block flow object is distributed into one or more block areas which are generated to hold that content. This distribution will be into the least number of block-areas necessary hold that content, consistent with the constraints defined by the properties applicable to the fo:block flow object. The distribution of the content of an fo:block flow object shall not generate two block areas in the same area-container.
These block-areas are placed in the containing area in the block-progression direction and immediately following any areas (block- or line-) previously generated into that containing area.
Determination of trait values
The nominal-glyph-height trait is set from the computed value of the "font-size" property. The half-leading trait is set to 1/2 the computed value of the "line-height" property minus the "font-size" property.
Properties:
Common use:
The fo:display-graphic flow object is used for a block-level graphic.
Area type:
The fo:display-graphic flow object results in a single block-area.
Content distribution
In the simple case, the "height" and "width" properties are used to set this object's size. If they are not specified, the "min-height" or "max-height" and "min-width" or "max-width" properties and the "scale-graphic" property (combined with any size specified by the content) are used to derive a size between the limits specified.
NOTE: Issue: is this what we want? If so we need to describe the behavior more precisely.
Content distribution:
The fo:display-graphic flow object has no children.
NOTE: Issues: (1)Chris Lilley suggests a separate fo for e.g., SVG and keeping the graphic ones for "images". (2)Do we want this one to be named display-EXTERNAL-graphic? (3)Handling of Alt-text is another issue.
Properties:
Common use:
The fo:display-included-container flow object is used to generate a block-level area container; typically containing text blocks with a different writing-mode.
NOTE: The use of this flow object is not required for changing the inline-progression-direction only; in that case the Unicode bidi algorithm and the fo:bidi-override are sufficient.
Area type:
The fo:display-included-container flow object results in a block-area. If the block-area will not fit in the remaining space in the containing area, one (or more) additional areas may be generated by the formatter, consistent with the constraints given by the properties of the content of this flow object. The area is an area-container.
Content distribution:
The size of the area-container has to be fixed in the inline-progression-direction. It must be specified unless the inline-progression-direction is parallel to the inline-progression-direction of the area-container into which the areas resulting from this flow object are placed.
The size in the block-progression-direction is determined by the content of this flow object.
The fo:display-included-container flow object may have any block-level formatting objects as its children.
Properties:
Common use:
The fo:display-rule flow object is used for a block-level rule (graphic-line). The line may be parallel to or perpendicular to the block-progression-direction that is specified by the writing-mode.
Area type:
The fo:display-rule flow object results in a single block-level area.
Content distribution:
The width of the content-rectangle is determined in the usual manner for block-level areas.
The height of the content-rectangle depends on the rule's orientation:
If the rule is perpendicular to the block-progression-direction it is determined by the rule's thickness.
If the rule is parallel to the block-progression-direction it is determined by the rule's length.
Content and its placement:
The fo:display-rule flow object is atomic and thus has no children.
In the inline-progression-direction the rule is positioned as specified by the "text-align" property.
NOTE: The rule may extend outside the content-rectangle in the inline-progression-direction.
The length and thickness of a rule may be specified to be larger than the area container into which the resulting area is placed. In this case the result is governed by the overflow and clip properties specified for the area-container.
Properties:
Common use:
The fo:display-sequence formatting object is used to specify inherited properties for a group of block-level formatting objects.
It is formatted to produce the concatenation of the block-level areas produced by each of its children.
Area type:
The fo:display-sequence object does not directly produce any area. However, each of its children is individually formatted to produce a series of block-level areas.
Determination of trait values:
The fo:display-sequence 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.
Content and its placement:
The fo:display-sequence flow object may have any block-level formatting objects as its children.
Properties:
Common use:
The fo:bidi-override formatting object is used when the Unicode-bidi algorithm fails. It forces a string of text to be written in a specific direction.
Area type:
The fo:bidi-override formatting object produces an inline-area.
Area size:
The size of the area is determined in the same manner as all other inline areas.
Determination of trait values:
The "direction" property is combined with the "writing-mode" to determine the new writing-direction.
Content:
The fo:bidi-override inline formatting object may contain other inline formatting objects or may directly contain characters.
Properties:
Common use:
The fo:character flow object represents a character that is mapped to a glyph for presentation. It is an atomic unit to the formatter.
When the result tree is interpreted as a tree of formatting objects, a character in the result tree is treated as if it were an empty element of type fo:character with a char attribute equal to the Unicode representation of the character.
NOTE: In a stylesheet the explicit creation of an fo:character may be used to explicitly override this default mapping.
Area type:
The fo:character flow object results in a single inline area.
Content distribution:
The width and height of the area is determined by the font metrics for the glyph.
The fo:character flow object is atomic and thus has no children.
Properties:
Common use:
The fo:first-line-marker specifies formatting properties for the first line of an fo:block.
NOTE: It is analogous to the CSS first-line pseudo-element.
Area type:
The fo:first-line-marker object does not directly produce any area.
Determination of trait values:
The properties specified on the fo:first-line-marker are taken into account as if the inline formatting objects, or parts of them in the case of a line break, that were used in formatting the first line were enclosed by and fo:inline-sequence, as a direct child of the fo:block, with those properties specified.
NOTE: This sentence may need simplification for the casual reader.
Content distribution:
The fo:first-line-marker formatting object is atomic and thus has no children.
Properties:
Common use:
The fo:inline-graphic flow object is used for an inline graphic.
Area type:
The fo:inline-graphic flow object results in a single inline area.
Content distribution:
In the simple case, the "height" and "width" properties are used to set this object's size. If they are not specified, the "min-height" or "max-height" and "min-width" or "max-width" properties and the "scale-graphic" property (combined with any size specified by the content) are used to derive a size between the limits specified.
NOTE: Is this what we want? If so we need to describe the behavior more precisely.
Content and its placement:
The fo:inline-graphic flow object has no children.
NOTE: Issues: Chris Lilley suggests a separate fo for e.g. SVG and keeping the graphic ones for "images". Do we want this one to be named inline-EXTERNAL-graphic? Handling of Alt-text is an issue.
Properties:
Common use:
The fo:inline-included-container flow object is used to generate an inline area container; typically containing text blocks with a different writing-mode.
NOTE: The use of this flow object is not required for bidirectional text; in this case the Unicode bidi algorithm and the fo:bidi-override are sufficient.
Area type:
The fo:inline-included-container flow object results in an inline-area. If the inline area will not fit in the remaining space in the containing area, one (or more) additional areas may be generated by the formatter, consistent with the constraints given by the properties of the content of this flow object. The area is an area-container.
Content distribution:
The size of the area container has to be fixed in the inline-progression-direction; it must be specified.
The size in the block-progression-direction is determined by the content of this flow object.
The fo:inline-included-container flow object may have any block-level formatting objects as its children.
Properties:
Common use:
The fo:inline-rule flow object is used for an inline rule (graphic-line). The line may be parallel to or perpendicular to the line-progression-direction that is specified by the writing-mode.
Area type:
The fo:inline-rule flow object results in a single inline area.
Content distribution:
The size of the content-rectangle depends on the rule's orientation:
If the rule is perpendicular to the line-progression-direction.
The width of the content-rectangle is determined by the rule's thickness.
The height of the content-rectangle is determined by the rule's length.
If the rule is parallel to the line-progression-direction.
The width of the content-rectangle is determined by the rule's length.
The height of the content-rectangle is determined by the rule's thickness.
In the direction perpendicular to the line-progression-direction the position-point and escapement-point are placed on the start-edge and end-edge of the content-rectangle.
In the direction parallel to the line-progression-direction the position-point and escapement-point are placed one the before-edge of the content-rectangle if the shift-direction and line-progression-direction are the same. Otherwise they are placed on the after-edge. The position may be further adjusted, raised or lowered, by a vertical-align specification.
NOTE: Issue: "vertical-align" needs change; we split up this property.
Content and its placement:
The fo:inline-rule flow object is atomic and thus has no children.
Properties:
Common use:
The fo:inline-sequence formatting object is used to specify inherited properties for a group of inline formatting objects.
It is formatted to produce the concatenation of the inline areas produced by each of its children.
Area type:
The fo:inline-sequence object does not directly produce any area. However, each of its children is individually formatted to produce a series of inline areas.
Determination of trait values:
The fo:inline-sequence 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.
Content and its placement:
The fo:inline-sequence flow object may have any inline formatting objects or PCDATA as its children.
Properties:
Common use:
The fo:page-number flow object is used to obtain an inline area whose content is the page number for the page on which the inline area is placed.
Area type:
The fo:page-number flow object results in a single inline area.
NOTE: Alternatively we can say that it produces the sequence of inline areas obtained by formatting the fo:character flow objects.
If so then the only property that applies is the "id".
The content of this inline area is the same as the result of formatting a result-tree fragment consisting of fo:character flow objects; one for each character in the page number string.
The page number string is obtained by converting the page number on which the inline area is placed in accordance with the number to string conversion properties specified on the page master used for instantiating the page.
Content distribution:
Height and width are determined in the usual manner for inline areas.
The content of the fo:page-number flow object is generated by the formatter. It must not contain any children.
Properties:
Common use:
The fo:page-number-citation is used to reference the page-number for the page containing the cited formatting object.
NOTE: It may be used to provide the page numbers in the table of contents, cross-references, and index entries.
Area type:
The fo:page-number-citation flow object results in an inline area in a manner analogous to that of the fo:page-number flow object.
Content distribution:
Height and width are determined in the usual manner for inline areas.
Determination of trait values:
The "ref-id" property is used to locate the item being referenced. The page-number of the page containing the first area resulting from this item is then acquired as an unstyled text string and the character-level properties are applied to that string in the same manner as for fo:character-string.
Content and its placement:
The content of the fo:page-number-citation flow object is generated by the formatter. It must not contain any children.
Properties:
NOTE: This formatting object corresponds to the CSS anonymous box that encloses the table caption and the table.
There is a desire for a more general mechanism to define structural relationships between arbitrary formatting objects.
Common use:
The fo:table-and-caption flow object is used for formatting a table together with its caption.
NOTE: A fo:table-and-caption may be placed inline by enclosing it in an fo:inline-included-container.
Area type:
The fo:table-and-caption flow object results in a block-area. If the block-area will not fit in the remaining space in the containing area, one (or more) additional areas may be generated by the formatter, consistent with the constraints given by the properties of the content, to accommodate the content.
Content distribution:
The width of the content-rectangle of the resulting block-area is the width of the content-rectangle of the containing area-container less than the "start-indent" and "end-indent".
The height is determined by the height of the content.
Content and its placement:
The fo:table-and-caption must have as children, in order:
fo:table-caption (optional)
fo:table
The content of the table-and-caption flow object is one or two areas, acting as area containers; one for the table caption and one for the table itself. These are positioned relative to each other as specified by the "caption-side" property. They are placed relative to the content-area as specified by the "text-align" property.
NOTE: Issue: Do we need a caption-repeat = yes|no property?
NOTE: Issue: Do we need to detail the algorithm of placing these areas?
Properties:
Common use:
The fo:table flow object is used for formatting the tabular material of a table.
The fo:table flow-object and its child flow objects model the visual layout of a table in a "row primary" manner. A complete table may be seen as consisting of a grid of rows and columns where each cell occupies one or more grid units in the row- and column-progression direction.
The table content is divided into a header (optional), footer (optional), and one or more bodies. Properties specify if the headers and footers should be repeated at a break in the table. Each of these parts occupies of one or more rows in the table grid.
Area type:
The fo:table flow object results in a block-area. If the block-area will not fit in the remaining space in the containing area, one (or more) additional areas may be generated by the formatter, consistent with the constraints given by the properties of the rows, cells, and their content.
Content distribution:
The width of the content-rectangle of the table is the sum of the widths of the columns in the table grid. The method used to determine these widths is specified by the "table-layout" property.
NOTE: The CSS2 specification states that a table-width of "auto" should be interpreted as table-layout="auto". It does not say how the width="auto" on a table-column or table-cell should be treated. We should probably assume that it is an error.
The method for determining the height of the table is governed by the 'table-height" property.
NOTE: The CSS2 specification explicitly does not specify what the behavior should be if there is a mismatch between an explicitly specified table height and the height of the content.
Determination of trait values:
The column- and row-progression direction is governed by the "writing-mode" property.
border: the method for deriving the border for a table is specified by the "border-collapse" property.
If the value of the "border-collapse" property is "separate" the border is composed of two components. The first, which is placed with the inside edge coincident with the outermost table grid boundary line, has the width of half the value for the "border-spacing" property. It is filled in accordance with the "background" property of the fo:table. Outside this border is placed, for each side of the table, a border based on a border specified on the table.
If the value of the "border-collapse" property is "collapse" the border is determined, for each segment, at the cell level.
NOTE: By specifying an appropriately high priority on the border specification for the fo:table one may ensure that this specification is the one used on all border segments.
The background color of a cell is determined in accordance with 17.5.1 of the CSS2 specification.
Content and its Placement:
The fo:table must have as children, in order:
fo:table-column (optional)
fo:table-header (optional)
fo:table-footer (optional)
fo:table-body (one or more)
Properties:
Common use:
The fo:table-column formatting object specifies characteristics applicable to table cells that have the same column and span. The most important property is the "column-width" property.
Type of Area:
This formatting object does not directly create any area.
Content and its Placement:
The fo:table-column does not have any children.
Properties:
NOTE: Issue: the order of inheritance needs to be settled and written up.
Common use:
The fo:table-caption formatting object is used to contain block-level formatting objects containing the caption for the table.
Type of Area:
The fo:table-caption generates an area container.
Content Distribution and Size:
For the case when the value of the "caption-side" property is "before" or "after" the width of the area container is equal to the width of the content-area of the area container that encloses it.
When the value is "start" or "end" the width of the area container is given by the "caption-width" property.
Content and its Placement:
The fo:table-caption may have any block-level formatting object as its children.
Properties:
Common use:
The fo:table-header formatting object is used to contain the content of the table header.
Type of Area:
This formatting object does not directly create any area.
Content and its Placement:
The fo:table-header has fo:table rows (one ore more) as its children, or alternatively fo:table-cells (one or more). In the latter case cells are grouped into rows using the starts-row and ends-row properties.
Properties:
Common use:
The fo:table-footer formatting object is used to contain the content of the table footer.
Type of Area:
This formatting object does not directly create any area.
Content and its Placement:
The fo:table-footer has fo:table rows (one ore more) as its children, or alternatively fo:table-cells (one or more). In the latter case cells are grouped into rows using the starts-row and ends-row properties.
Properties:
Common use:
The fo:table-body formatting object is used to contain the content of the table body.
Type of Area:
This formatting object does not directly create any area.
Content and its Placement:
The fo:table-body has fo:table rows (one ore more) as its children, or alternatively fo:table-cells (one or more). In the latter case cells are grouped into rows using the starts-row and ends-row properties.
Properties:
Common use:
The fo:table-row formatting object is used to group table-cells into rows; all table-cells in a table-row start in the same geometric row on the table grid.
Type of Area:
This formatting object does not directly create any area.
Content Distribution and Size:
The method for determining the height of the row in the grid is governed by the "row-height" property.
Content and its Placement:
The fo:table-row has fo:table-cell (one ore more) as its children.
Properties:
Common use:
The fo:table-cell formatting object is used to group content to be placed in a table-cell.
Type of Area:
A table cell occupies one or more grid units in the row- and column-progression direction and acts as an area container. The content-area of the cell is the size of the portion of the grid the cell occupies minus, for each of the four sides:
If the value of the "border-collapse" property is "separate": half the value of the "border-spacing" property; otherwise 0.
If the value of the "border-collapse" property is "separate": the thickness of the cell-border; otherwise half the thickness of the effective border.
The cell padding.
Content Distribution and Size:
The method for determining the height of the cell in the grid is governed by the "row-height" property.
Determination of Trait Values:
background: in accordance with the CSS2 inheritance rules specified in 17.5.1.
NOTE: A cell that is spanned may have a different background in each of the grid units it occupies.
border: the method for deriving the border for a cell is specified by the "border-collapse" property.
If the value of the "border-collapse" property is "separate" the border is composed of two components. The first, which is placed with the outside edge coincident with the table grid boundary line, has the width of half the value for the "border-spacing" property. It is filled in accordance with the "background" property of the fo:table. Inside this border is placed, for each side of the cell, a border based on a border specified on the cell or inherited.
If the value of the "border-collapse" property is "collapse" the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the highest priority. It is an error if there are two such borders that have the same priority but are not identical. Each border segment is placed centered on the table grid boundary line.
NOTE: In future we will need a property specifying the alignment of the border with respect to the boundary line.
padding: the value for the table-cell; either specified or inherited.
Content and its Placement:
The fo:table-caption may have any block-level formatting object as its children.
Properties:
Common use:
The fo:list-block flow object is used to format a list item or a list.
Type of Area:
The fo:list-block flow object results in a block-area. If the block-area will not fit in the remaining space in the containing area, one (or more) additional areas may be generated by the formatter, consistent with the constraints given by the content of the list-block.
Content and its Placement:
The list-block must have as children either:
pairs of fo:list-item-label and fo:list-item-body formatting objects, or
fo:list-item formatting objects.
In the case where the fo:list-block contains fo:list-item objects the areas produced by these are placed one after the other in the block-progression-direction.
In the case where the fo:list-block contains pairs of fo:list-item-label and fo:list-item-body objects, each pair is formatted into one (or more) block-areas. The space-between-list-rows property specifies the separation between each block-area; any space-before or space-after on the edges of blocks contained in the fo:list-item-label and fo:list-item-body formatting objects adjacent to a transition is ignored. The placement of the areas produced by formatting the fo:list-item-label and fo:list-item-body objects are positioned with respect to each other in the following manner:
In the block-progression-direction these areas are positioned according to the "vertical-align" property.
In the inline-progression-direction these areas are positioned according to the start- and end-indent properties of the content of the fo:list-item-label and fo:list-item-body formatting objects. It is an error if the areas overlap.
NOTE: These areas are not area-containers, hence the indents on all objects within them are measured relative to the area-container that holds the content of the fo:list-block.
Properties:
Common use:
The fo:list-item formatting object contains the label and the body of an item in a list.
Type of Area:
The fo:list-item flow object results in a block-area. If the block-area will not fit in the remaining space in the containing area, one (or more) additional areas may be generated by the formatter, consistent with the constraints given by the content of the list-item.
Content Distribution and Size:
The width of the content-area of the block-area is the width of the area container into which it is placed minus the start- and end-indent.
The height is determined by the content of the fo:list-item.
Content and its Placement:
The list-item must have as children:
fo:list-item-label.
fo:list-item-body.
The placement of the areas produced by formatting the fo:list-item-label and fo:list-item-body objects are positioned with respect to each other in the following manner:
In the block-progression-direction these areas are positioned according to the "vertical-align" property.
In the inline-progression-direction these areas are positioned according to the start- and end-indent properties of the content of the fo:list-item-label and fo:list-item-body formatting objects. It is an error if the areas overlap.
NOTE: These areas are not area-containers, hence the indents on all objects within them are measured relative to the area-container that holds the content of the fo:list-block.
Properties:
Common use:
The fo:list-item-body formatting object contains the content of the body of a list item.
Type of Area:
The fo:list-item-body formatting object does not directly create any area.
Content and its Placement:
The fo:list-item-body may have any block-level formatting objects as its children.
Properties:
Common use:
The fo:list-item-label formatting object contains the content of the label of a list item; typically used to either enumerate, identify or adorn the list-item's body.
Type of Area:
The fo:list-item-label formatting object does not directly create any area.
Content and its Placement:
The fo:list-item-label may have any block-level formatting objects as its children.
Properties:
Common use:
The fo:simple-link is used for representing the start resource of a simple one-directional single-target link. The object allows for traversal to the destination resource, typically by clicking on any of the containing areas.
NOTE: An fo:simple-link may be displayed by enclosing it in an fo:block.
Type of Area:
The fo:simple-link flow object results in an inline area. If the inline area will not fit in the remaining space in the containing line area, one (or more) additional areas may be generated by the formatter, consistent with the constraints given by the properties of the content, to accommodate the content.
Content Distribution and Size:
The width is determined by the content. The height is determined by the height of the content.
Content Formatting Objects and Placement of Content:
The fo:simple-link flow object may contain any character, inline formatting objects, as well as block-level formatting objects.
The content is formatted in the general manner of inlines.
Properties:
Common use:
The fo:multi-switch is used to switch between two or more sub-trees of formatting objects.
The direct children of an fo:multi-switch object are fo:multi-case objects. Only a single fo:multi-case may be visible at a single time. The user may switch between the available multi-cases.
Each fo:multi-case may contain one or more fo:multi-toggle objects, which controls the fo:multi-case switching of the fo:multi-switch.
NOTE: An fo:multi-switch can be used for many interactive tasks, such as table-of-content views, embedding link targets, or generalized (even multi-layered hierarchical), prev- next data views. The latter are today normally handled in HTML by prev- next links to other documents, forcing that the whole document to be replaced whenever the users decides to move on.
The fo:multi-switch shall initially display the first fo:multi-case child that has the property "initial" assigned to "true".
Type of Area:
The fo:multi-switch does not directly create any areas, but acts as an transparent container, and is (conceptually) replaced by the currently visible flow objects.
Content Formatting Objects and Placement of Content:
The direct children of an fo:multi-switch object are fo:multi-case objects.
Properties:
NOTE: Issue: In order to make the construction of an expandable/collapsable table of contents easier, should a special purpose "fo:outline" be created?
In order to build a TOC from fo:multi-switch objects, one needs to incorporate the actual "title" twice, once in the "closed" mode (together with an "open" icon), and once in the "open" mode (together with both a "close" icon and all sub-title entries).
Common use:
The fo:multi-case is used to embed flow objects, that the parent fo:multi-switch can choose to either show or hide.
Type of Area:
The fo:multi-case does not directly create any areas, but acts as a transparent container, and is (conceptually) replaced by the flow objects it contains.
Content Formatting Objects and Placement of Content:
The fo:multi-case may contain any formatting objects that are permitted as a replacement of the fo:multi-switch formatting object. In particular, it can contain fo:multi-toggle objects (at any depth), which controls the fo:multi-case switching.
Properties:
Common use:
The fo:multi-toggle is used within an fo:multi-case to switch to another fo:multi-case, typically by clicking on any of the fo:multi-toggle containing areas.
NOTE: Issue: Need to investigate how multi-toggle should relate to the (as yet unspecified) input mechanisms, such as radio-buttons.
Type of Area:
The fo:multi-toggle results in the sequence of areas obtained by formatting the content of the fo:multi-toggle formatting object.
Content Formatting Objects and Placement of Content:
The fo:multi-toggle formatting object may contain any character, inline formatting objects, as well as block-level formatting objects.
Properties:
Common use:
The fo:multi-properties is used to switch between two or more property sets that are associated with a given portion of content. The direct children of an fo:multi-properties formatting object is an ordered set of fo:multi-property-set formatting objects followed by any character, inline, and block-level formatting objects. The specified properties of all fo:multi-property-set formatting objects for states that apply are merged. In this merger, properties specified in later fo:multi-property-set objects replace any values set in earlier fo:multi-property-set objects. This assembled set of property specifications are added to the inheritable properties for all the child formatting objects of the fo:multi-properties formatting object that are not of the class fo:multi-property-set; this has the same effect as if a sequence formatting object with the assembled set of property specifications had enclosed them. If no states apply there is no change to the inheritable properties. The states on the fo:multi-property-set are the states (and events) that are identified by the DOM.
NOTE: Issue: One may well want to change some non-inherited properties, such as background and borders. Therefore, some other mechanism is needed to handle propagation of these properties to the fo:multi-property-set children of the fo:multi-property group.
NOTE: An fo:multi-properties formatting object can be used to give different appearances to a given portion of content. For example, when a link changes from the not-yet-visited state to the visited-state, this could change the set of properties that would be used to format the content. Designers should be careful in choosing which properties they change, because many property changes could cause reflowing of the text which may not be desired in many circumstances. Changing properties such as "color" or "text-decoration" should not require re-flowing the text.
Type of Area:
The fo:multi-properties does not directly result in any areas. Areas may be generated by formatting the content of the fo:multi-properties formatting object.
Properties:
Common use:
The fo:multi-property-set is used to specify an alternative set of formatting properties that can be used to provide an alternate presentation of the children flow objects of the parent of this fo:multi-property-set that are not of the fo:multi-property-set class.
Type of Area:
The fo:multi-property-set does not result in any area, but is simply the place-holder for a set of properties.
Distribution of Content:
The fo:multi-property-set does not have any children, and thus there is no content to distribute.
Properties:
Common use:
The fo:float formatting object holds a sequence formatting objects that is to be presented in a conditional-area at the top of an instance of a region with the same name as the region into which the fo:float flow object is distributed. The content of the fo:float flow object is not placed where the flow object is distributed, but is instead placed, out-of-line, in the next instance of the region with the same name for which there is room for the content of the fo:float. Such content might be a figure, a table or other chunk of content that is to be kept together and need not disrupt the flow of the content around it.
NOTE: Issue: Floating to the top of the same page should not be prohibited for systems that can support it.
Type of area:
The fo:float flow object generates a block-area that is placed in a conditional-area anchored on the before edge of the region into which the fo:float flow object is distributed. The placement of the block-area generated by the fo:float into the conditional regions is called, "out-of-line" placement.
NOTE: Issue: Does it generate a block-area?!
Determination of trait values:
The coordinate system for the conditional-area for floats is set to the same orientation as the coordinate system of the region that contains the conditional-area. The writing-mode for the conditional-area-container is similarly copied from the region which contains it. Currently, there is no way to specify any of the common-border-padding-and-background-properties so the conditional region has no padding, borders or background.
Distribution of content:
The fo:floats which are distributed into a given region all generate a float block-area in a conditional-area for floats in the region into which they are distributed or in some subsequent instance of a region with the same name. That is, the content of the fo:float flow object is not distributed where the fo:float is distributed, but is instead formatted into a block area that is placed, out-of-line, in the same or a subsequent region of the same name as the one in which the fo:float flow object was distributed.
The size of the conditional-area for floats, in the block-progression-direction, shall not exceed the computed value of the "max-height" property on the fo:float flow object.
The content of each fo:float is distributed into a single block-area whose height and width is determined by the common-margin-properties-block and the common-border-padding-and-background-properties. The conditional-area for floats is the area-container into which this block-area is placed. The normal rules for space resolution apply to these blocks. The block-areas for floats are placed in conditional-areas for floats in the order in which the fo:float flow objects were distributed in the content distribution of the flow in which they occur. If a the block-area for a given float will not fit into the current conditional-area for floats, then it will be distributed into a conditional area for floats in a subsequent region of the same name as the current region. Instances of page-masters with a region of the same name will continue to be generated as long as there are float block-areas to be placed.
NOTE: Issue: What is to happen if there is a float that can never fit within the "max-height" of the conditional-area for floats. Should that float be split? Should it be ignored?
Properties:
Common use:
The fo:footnote formatting object represents both the place of occurrence of the footnote reference (or citation) and the content of the footnote itself. The footnote citation occurs where the fo:footnote flow object occurs; that is, the footnote citation is formatted inline. The footnote itself is formatted out of line; it is floated to the bottom of the page on which the footnote citation occurs.
The content of the fo:footnote is structured into two pieces. There is an fo:footnote-citation flow object which is an inline flow object that is used to specify the properties to be used in formatting the footnote citation. The remaining content of the fo:footnote flow object is the content of the footnote itself. If the footnote itself is to have a label and a body, then this content should be structured using the fo:list-block flow object containing an fo:list-label and an fo:list-body.
NOTE: Issue: The last sentence should be moved to a note and also stress that the use of list formatting objects is only when such a layout is desired.
Type of area:
The fo:footnote formatting object generates two areas. The citation generates at least one inline-area into which the content of the fo:footnote-citation is distributed. This distribution into one or more inline-areas shall be consistent with the constraints determined by the properties applicable to the fo:footnote-citation flow object.
The fo:footnote flow object generates a block-area that is placed in a conditional-area anchored on the after edge of the region into which the fo:footnote-citation is distributed. The placement of the block-area generated by the fo:footnote into the conditional regions is called, "out-of-line" placement.
NOTE: Issue: Does it generate a block-area?!
Determination of trait values:
The coordinate system for the conditional-area for footnotes is set to the same orientation as the coordinate system of the region that contains the conditional-area. The writing-mode for the conditional-area-container is similarly copied from the region which contains it. Currently, there is no way to specify any of the common-border-padding-and-background-properties so the conditional region has no padding, borders or background.
NOTE: Issue: Should there be a way to establish borders and/or padding and backgrounds for the conditional footnote areas?
Distribution of content:
The content of the fo:footnote-citation is distributed as specified in the description of the fo:footnote-citation flow object.
The fo:footnotes which have a citation distributed into a given region all generate a footnote block-area in the conditional-area for footnotes for the region into which they are distributed. One condition on the distribution of the footnote-citation inline-areas into a region is that footnote conditional-area for that region is large enough to hold the footnote block-areas for all the footnote-citations distributed to that region. In addition, the size of that conditional-area in the block-progression-direction shall not exceed the computed value of the "max-height" property on the fo:footnote flow object.
The content of each fo:footnote, excluding the fo:footnote-citation, is distributed into a single block-area whose height and width is determined by the common-margin-properties-block and the common-border-padding-and-background-properties. The conditional-area for footnotes is the area-container into which this block-area is placed. The normal rules for space resolution apply to these blocks which are placed in the conditional-area for footnotes in the order in which the fo:footnote flow objects occurred in the content distributed into the region to which the footnote is attached.
Properties:
Common use:
The fo:footnote-citation flow object specifies the properties used format the footnote reference (or citation) itself. The footnote citation occurs where its parent fo:footnote flow object occurs; that is, the footnote citation is formatted inline.
Type of area:
The fo:footnote-citation formatting object generates at least one inline-area into which the content of the fo:footnote-citation is distributed.
Distribution of content:
The content of the fo:footnote-citation is distributed into one or more inline-areas in the current block. If all the content can be distributed into a single line, then only one inline area is generated; otherwise the content of the footnote-citation is split into more than one inline-area provided that the constraints specified by the properties applicable to the fo:footnote-citation are satisfied.
The fo:footnotes which have a citation distributed into a given region all generate a footnote block-area in the conditional-area for footnotes for the region into which they are distributed. One condition on the distribution of the footnote-citation inline-areas into a region is that footnote conditional-area for that region is large enough to hold the footnote block-areas for all the footnote-citations distributed to that region. In addition, the size of that conditional-area in the block-progression-direction shall not exceed the computed value of the "max-height" property on the fo:footnote flow object that is the parent of the fo:footnote-citation flow object.
Properties:
The following sections describe the properties of the XSL formatting objects in greater detail.
The first eight sets of property definitions have been arranged into groups based on similar functionality and the fact that they apply to many formatting objects. In the formatting object descriptions the group name is referred to rather than referring to the individual properties.
Common Absolute Position Properties
This set of properties controls the position and size of formatted areas with absolute or relative positioning (areas displaced from the default positioning in the text block). This property group appears on all formatting objects that produce visible renderings.
NOTE: For XSL the semantics of these properties needs to be developed and written up in the formatting model section and in the formatting object descriptions.
Common Aural Properties
This group of properties controls the aural rendition of the content of a formatting object. They appear on all formatting objects that contain content and other formatting objects that group other formatting objects and where that grouping is necessary for the understanding of the aural rendition. An example of the latter is fo:table-and-caption.
Common Border, Padding, and Background Properties
This set of properties controls the backgrounds and borders on all formatted areas. This property group appears on all formatting objects that produce visible renderings.
Common Font Properties
This set of properties controls the font selection on all formatting objects that can contain text. Appears on fo:block, fo:first-line-marker, and on inline formatting objects that contain or generate text.
Common Hyphenation Properties
Low-level control of line-breaking, including hyphenation and language selection. Appears on fo:block and fo:title.
Common Keeps and Breaks Properties
Controls page/column breaks before/after block-level formatting objects. Appears on most block-level formatting objects.
Common Margin Properties-Block
These properties set the spacing and indents surrounding block-level formatting objects.
Common Margin Properties-Inline
These properties set the spacing surrounding inline formatting objects.
The remaining properties are used on a small number of formatting objects. These are arranged into clusters of similar functionality to organize the property descriptions. In the formatting object description the individual properties are referenced.
Pagination Properties
These properties govern the sequencing, layout, and instantiation of pages, including: the page size and orientation, sizes of regions on the page-master, the identification and selection of page-masters, division of the body region into columns, and the assignment of content flows to layout regions.
Table Properties
Properties governing the layout, and presentation of tables.
Character Properties
Properties governing the presentation of text-characters.
Rule Properties
Properties governing the construction of rules (graphic lines).
Page-related Properties
These properties augment the common-keeps-and-breaks-properties group by adding controls for widows, orphans, and page/column breaks within block-level formatting objects that contain text.
Horizontal Float-related properties
Properties governing the placement of floats and controlling the wrapping (runaround) of text that may be adjacent to the float.
NOTE: Issue: The corresponding formatting objects and model enhancements need to be designed and written up.
Properties for Number-to-String Conversions
Properties used in the construction of page numbers and other formatter-based numbering.
Properties for Links
Properties governing the presentation and actions associated with links.
Miscellaneous Properties
These properties did not reasonably fit into any of the other categories.
One of the following:
static : (Default)
The box is a normal box, laid out according to the normal flow. The "left" and "top" properties do not apply.
relative :
The box's position is calculated according to the normal flow (this is called the position in normal flow). Then the box is offset relative to its normal position. When a box B is relatively positioned, the position of the following box is calculated as though B were not offset.
absolute :
The box's position (and possibly size) is specified with the "left", "right", "top", and "bottom" properties. These properties specify offsets with respect to the box's containing block. Absolutely positioned boxes are taken out of the normal flow. This means they have no impact on the layout of later siblings. Also, though absolutely positioned boxes have margins, they do not collapse with any other margins.
fixed :
The box's position is calculated according to the "absolute" model, but in addition, the box is fixed with respect to some reference. In the case of continuous media, the box is fixed with respect to the viewport (and doesn't move when scrolled). In the case of paged media, the box is fixed with respect to the page, even if that page is seen through a viewport (in the case of a print-preview, for example). Authors may wish to specify "fixed" in a media-dependent way. For instance, an author may want a box to remain at the top the viewport on the screen, but not at the top of each printed page.
Reference to CSS2: position property -- http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-position
Specifies the positioning algorithm to be used.
See definition of property left (Section 5.2.5: left).
See definition of property left (Section 5.2.5: left).
See definition of property left (Section 5.2.5: left).
<length> | <percentage> | auto
Reference to CSS2: left property -- http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-left
Reference to CSS2: right property -- http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-right
Reference to CSS2: top property -- http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-top
Reference to CSS2: bottom property -- http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-bottom
The offset is a fixed distance from the reference edge.
The offset is a percentage of the containing block's width (for "left" or "right") or "height" (for "top" and "bottom"). For "top" and "bottom", if the "height" of the containing block is not specified explicitly (i.e., it depends on content height), the percentage value is interpreted like "auto".
The effect of this value depends on which of related properties have the value "auto" as well. See the sections on the width and height of absolutely positioned, non-replaced elements for details.
For absolutely positioned boxes, the offsets are with respect to the box's containing block. For relatively positioned boxes, the offsets are with respect to the outer edges of the box itself (i.e., the box is given a position in the normal flow, then offset from that position according to these properties).
The "top" property specifies how far a box's top content edge is offset below the top edge of the box's containing block.
The "right" property specifies how far a box's right content edge is offset to the left of the right edge of the box's containing block.
The "bottom" property specifies how far a box's bottom content edge is offset above the bottom of the box's containing block.
The "left" property specifies how far a box's left content edge is offset to the right of the left edge of the box's containing block.
<angle> | [[ left-side | far-left | left | center-left | center | center-right | right | far-right | right-side ] || behind ] | leftwards | rightwards
Reference to CSS2: azimuth property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-azimuth
[ <'cue-before'> || <'cue-after'> ]
Reference to CSS2: cue property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-cue
<uri> | none
Reference to CSS2: cue-after property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-cue-after
<uri> | none
Reference to CSS2: cue-before property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-cue-before
<angle> | below | level | above | higher | lower
Reference to CSS2: elevation -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-elevation
[ [<time> | <percentage>]{1,2} ]
Reference to CSS2: pause property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-pause
<time> | <percentage>
Reference to CSS2: pause-after property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-pause-after
<time> | <percentage>
Reference to CSS2: pause-before property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-pause-before
<frequency> | x-low | low | medium | high | x-high
Reference to CSS2: pitch property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-pitch
<number>
Reference to CSS2: pitch-range property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-pitch-range
<uri> mix? repeat? | auto | none
Reference to CSS2: play-during property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-play-during
<number>
Reference to CSS2: richness property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-richness
normal | none | spell-out
Reference to CSS2: speak property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-speak
once | always
Reference to CSS2: speak-header property -- http://www.w3.org/TR/REC-CSS2/tables.html#propdef-speak-header
digits | continuous
Reference to CSS2: speak-numeral property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-speak-numeral
code | none
Reference to CSS2: speak-punctuation property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-speak-punctuation
<number> | x-slow | slow | medium | fast | x-fast | faster | slower
Reference to CSS2: speech-rate property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-speech-rate
<number>
Reference to CSS2: stress property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-stress
[[<specific-voice> | <generic-voice> ],]* [<specific-voice> | <generic-voice> ]
Reference to CSS2: voice-family property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-voice-family
<number> | <percentage> | silent | x-soft | soft | medium | loud | x-loud
Reference to CSS2: volume property -- http://www.w3.org/TR/REC-CSS2/aural.html#propdef-volume
The following common-border-padding-and-background-properties are taken from CSS2. Those "border", "padding", and "background" properties that have a before, after, start, or end suffix are writing-mode relative and are XSL only properties.
<background-color> || <background-image> || <background-repeat> || <background-attachment> || <background-position>
The "background" property is a shorthand property for setting the individual background properties (i.e., background-color, background-image, background-repeat, background-attachment and background-position) at the same place in the stylesheet.
The "background" property first sets all the individual background properties to their initial values, then assigns explicit values given in the declaration.
One of the following:
scroll : (Default)
The background-image may scroll with the enclosing object.
fixed :
The background-image is to be fixed within the viewable area of the enclosing object/
If a "background-image" is specified, this property specifies whether it is fixed with regard to the viewport (fixed) or scrolls along with the document (scroll).
Even if the image is fixed, it is still only visible when it is in the background or padding area of the element. Thus, unless the image is tiled ("background-repeat: repeat"), it may be invisible.
User agents may treat fixed as scroll. However, it is recommended they interpret fixed correctly, at least for the HTML and BODY elements, since there is no way for an author to provide an image only for those browsers that support fixed. See the section on conformance for details.
One of the following:
transparent : (Default)
The underlying colors will shine through.
-or-
<color> Any valid color specification. See http://www.w3.org/TR/REC-CSS2/colors.html#propdef-color
This property sets the background color of an element, either a <color> value or the keyword transparent, to make the underlying colors shine through.
NOTE: There is work in both the CSS and SVG WGs dealing with ICC color profiles that we wish to reference for XSL. This reference will appear in the next Draft.
One of the following:
none : (Default)
No image is specified.
-or-
<uri> Any valid uri specification. See http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-uri
This property sets the background image of an element. When setting a "background-image", authors should also specify a background-color that will be used when the image is unavailable. When the image is available, it is rendered on top of the background color. (Thus, the color is visible in the transparent parts of the image).
Values for this property are either <uri>, to specify the image, or "none", when no image is used.
One of the following:
repeat : (Default)
The image is repeated both horizontally and vertically.
repeat-x :
The image is repeated horizontally only.
repeat-y :
The image is repeated vertically only.
no-repeat :
The image is not repeated: only one copy of the image is drawn.
If a "background-image" is specified, this property specifies whether the image is repeated (tiled), and how. All tiling covers the content and padding areas of a box.
[<percentage> | <length> ]{1,2} | [[top | center | bottom] || [left | center | right ]]
With a value pair of 0% 0%, the upper left corner of the image is aligned with the upper left corner of the box's padding edge. A value pair of 100% 100% places the lower right corner of the image in the lower right corner of padding area. With a value pair of 14% 84%, the point 14% across and 84% down the image is to be placed at the point 14% across and 84% down the padding area.
With a value pair of 2cm 2cm, the upper left corner of the image is placed 2cm to the right and 2cm below the upper left corner of the padding area.
Same as 0% 0%.
Same as 50% 0%.
Same as 100% 0%.
Same as 0% 50%.
Same as 50% 50%.
Same as 100% 50%.
Same as 0% 100%.
Same as 50% 100%.
Same as 100% 100%.
If a "background-image" has been specified, this property specifies its initial position.
If only one percentage or length value is given, it sets the horizontal position only, the vertical position will be 50%. If two values are given, the horizontal position comes first. Combinations of length and percentage values are allowed, (e.g., 50% 2cm). Negative positions are allowed. Keywords cannot be combined with percentage values or length values (all possible combinations are given above).
If the background image is fixed within the viewport (see the "background-attachment" property), the image is placed relative to the viewport instead of the elements padding area.
One of the following:
transparent :
Border is colorless.
-or-
A color (See Section 3.6.13: Color).
Defaults to value of the 'color' property from the rgb color space.
Specifies the color of the border on the before-edge of a block-area or inline-area.
One of the following:
none : (Default)
No border, forces border-width to 0.
hidden :
Same as "none".
dotted :
The border is a series of dots.
dashed :
The border is a series of short line segments.
solid :
The border is a single line segment.
double :
The border is two solid lines. The sum of the two lines and the space between them equals the value of "border-width".
groove :
The border looks as though it were carved into the canvas
ridge :
The opposite of "groove", the border looks as though it were coming out of the canvas.
inset :
The border makes the entire box look as though it were embedded in the canvas.
outset :
The opposite of "inset": the border makes the entire box look as though it were coming out of the canvas.
Specifies the style of the border on the before-edge of a block-area or inline-area.
One of the following:
medium : (Default)
thin :
thick :
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Specifies the width of the border on the before-edge of a block-area or inline-area.
Values are the same as for border-before-color
Analogous to border-before-color for the after-edge
Values are the same as for border-before-style
Analogous to border-before-style for the after-edge
Values are the same as for border-before-width
Analogous to border-before-width for the after-edge
Values are the same as for border-before-color
Analogous to border-before-color for the start-edge
Values are the same as for border-before-style
Analogous to border-before-style for the start-edge
Values are the same as for border-before-width
Analogous to border-before-width for the start-edge
Values are the same as for border-before-color
Analogous to border-before-color for the end-edge
Values are the same as for border-before-style
Analogous to border-before-style for the end-edge
Values are the same as for border-before-width
Analogous to border-before-width for the end-edge
Values are the same as for border-before-color
Analogous to border-before-color for the top-edge
Values are the same as for border-before-style
Analogous to border-before-style for the top-edge
Values are the same as for border-before-width
Analogous to border-before-width for the top-edge
Values are the same as for border-before-color
Analogous to border-before-color for the bottom-edge
Values are the same as for border-before-style
Analogous to border-before-style for the bottom-edge
Values are the same as for border-before-width
Analogous to border-before-width for the bottom-edge
Values are the same as for border-before-color
Analogous to border-before-color for the left-edge
Values are the same as for border-before-style
Analogous to border-before-style for the left-edge
Values are the same as for border-before-width
Analogous to border-before-width for the left-edge
Values are the same as for border-before-color
Analogous to border-before-color for the right-edge
Values are the same as for border-before-style
Analogous to border-before-style for the right-edge
Values are the same as for border-before-width
Analogous to border-before-width for the right-edge
<'border-top-width'> || <'border-style'>> || <color>
A shorthand property for setting border the properties of a block-area or inline-area.
The "border" property is a shorthand property for setting the same width, color, and style for all four borders, top, bottom, left, and right, of a box. Unlike the shorthand "margin" and "padding" properties, the "border" property cannot set different values on the four borders. To do so, one or more of the other border properties must be used. Since, to some extent, the properties have overlapping functionality, the order in which the rules are specified is important.
<'border-top-width'> || <'border-style'>> || <color>
A shorthand property for setting the width, style, and color of the top of a block-area or inline-area.
Values are the same as for border-top
Analogous to border-top for the bottom border.
Values are the same as for border-top
Analogous to border-top for the left border.
Values are the same as for border-top
Analogous to border-top for the right border.
<color> Any valid color specification.
A shorthand property for setting the color of the top, bottom, right, and left border of a block-area or inline-area.
The "border-color" property can have from one to four values, and the values are set on the different sides as for "border-width".
If an element's border color is not specified with a "border" property, user agents must use the value of the element's "color" property as the computed value for the border color.
NOTE: There is work in both the CSS and SVG WGs dealing with ICC color profiles that we wish to reference for XSL. This reference will appear in the next Draft.
Any valid border-style specification. See the "border-before-style" property.
A shorthand property for setting the border style of the top, bottom, right, and left border of a block-area or inline-area.
The "border-style" property sets the style of the four borders.
It can have from one to four values, and the values are set on the different sides.
Any valid border-width specification. See the "border-before-width" property.
A shorthand property for setting the border width of the top, bottom, right, and left border of a block-area or inline-area.
This property is a shorthand property for setting "border-top-width", "border-right-width", "border-bottom-width", and "border-left-width" at the same place in the stylesheet.
If there is only one value, it applies to all sides. If there are two values, the top and bottom borders are set to the first value and the right and left are set to the second. If there are three values, the top is set to the first value, the left and right are set to the second, and the bottom is set to the third. If there are four values, they apply to the top, right, bottom, and left, respectively.
Specifies the width of the padding on the before-edge of a block-area or inline-area.
Specifies the width of the padding on the after-edge of a block-area or inline-area.
Specifies the width of the padding on the start-edge of a block-area or inline-area.
Specifies the width of the padding on the end-edge of a block-area or inline-area.
Specifies the width of the padding on the top of a block-area or inline-area.
Specifies the width of the padding on the bottom of a block-area or inline-area.
Specifies the width of the padding on the left of a block-area or inline-area.
Specifies the width of the padding on the right of a block-area or inline-area.
<padding-width>{1,4}
A shorthand property for setting padding-top, padding-bottom, padding-left, and padding-right of a block-area or inline-area.
If there is only one value, it applies to all sides. If there are two values, the top and bottom paddings are set to the first value and the right and left paddings are set to the second. If there are three values, the top is set to the first value, the left and right are set to the second, and the bottom is set to the third. If there are four values, they apply to the top, right, bottom, and left, respectively.
The surface color or image of the padding area is specified via the "background" property.
The following common-font-properties all are taken from CSS2. The reference to CSS2 is: http://www.w3.org/TR/REC-CSS2/fonts.html
[[ <'font-style'> || <'font-variant'> || <'font-weight'> ]? <'font-size'> [ / <'line-height'> ]? <'font-family'> ] | caption | icon | menu | message-box | small-caption | status-bar
The "font" property is, except as described below, a shorthand property for setting "font-style", "font-variant", "font-weight", "font-size", "line-height", and "font-family", at the same place in the stylesheet. The syntax of this property is based on a traditional typographical shorthand notation to set multiple properties related to fonts.
All font-related properties are first reset to their initial values, including those listed in the preceding paragraph plus "font-stretch" and "font-size-adjust". Then, those properties that are given explicit values in the "font" shorthand are set to those values. For a definition of allowed and initial values, see the previously defined properties. For reasons of backward compatibility, it is not possible to set "font-stretch" and "font-size-adjust" to other than their initial values using the "font" shorthand property; instead, set the individual properties.
The following values refer to system fonts:
The font used for captioned controls (e.g., buttons, drop-downs, etc.).
The font used to label icons.
The font used in menus (e.g., dropdown menus and menu lists).
The font used in dialog boxes.
The font used for labeling small controls.
The font used in window status bars.
System fonts may only be set as a whole; that is, the "font-family", "size", "weight", "style", etc. are all set at the same time. These values may then be altered individually if desired. If no font with the indicated characteristics exists on a given platform, the user agent should either intelligently substitute (e.g., a smaller version of the "caption" font might be used for the "smallcaption" font), or substitute a user agent default font. As for regular fonts, if, for a system font, any of the individual properties are not part of the operating system's available user preferences, those properties should be set to their initial values.
That is why this property is "almost" a shorthand property: system fonts can only be specified with this property, not with "font-family" itself, so "font" allows authors to do more than the sum of its sub-properties. However, the individual properties such as "font-weight" are still given values taken from the system font, which can be independently varied.
[ <family-name> | <generic-family> ],]* [<family-name> | <generic-family>
The name of a font-family of choice. In the previous example, "Baskerville", "Heisi Mincho W3", and "Symbol" are font families. Font family names containing whitespace should be quoted. If quoting is omitted, any whitespace characters before and after the font name are ignored and any sequence of whitespace characters inside the font name is converted to a single space.
The following generic families are defined: "serif", "sans-serif", "cursive", "fantasy", and "monospace". Please see the section on generic font families for descriptions of these families. Generic font family names are keywords, and therefore must not be quoted.
This property specifies a prioritized list of font family names and/or generic family names. To deal with the problem that a single font may not contain glyphs to display all the characters in a document, or that not all fonts are available on all systems, this property allows authors to specify a list of fonts, all of the same style and size, that are tried in sequence to see if they contain a glyph for a certain character. This list is called a font set.
The generic font family will be used if one or more of the other fonts in a font set is unavailable. Although many fonts provide the "missing character" glyph, typically an open box, as its name implies this should not be considered a match except for the last font in a font set.
<absolute-size> | <relative-size> | <length> | <percentage>
An <absolute-size> keyword refers to an entry in a table of font sizes computed and kept by the user agent. Possible values are:
[ xx-small | x-small | small | medium | large | x-large | xx-large ]
On a computer screen a scaling factor of 1.2 is suggested between adjacent indexes; if the "medium" font is 12pt, the "large" font could be 14.4pt. Different media may need different scaling factors. Also, the user agent should take the quality and availability of fonts into account when computing the table. The table may be different from one font family to another. Note. In CSS1, the suggested scaling factor between adjacent indexes was 1.5 which user experience proved to be too large.
A <relative-size> keyword is interpreted relative to the table of font sizes and the font size of the parent element. Possible values are:
[ larger | smaller ]
For example, if the parent element has a font size of "medium", a value of "larger" will make the font size of the current element be "large". If the parent element's size is not close to a table entry, the user agent is free to interpolate between table entries or round off to the closest one. The user agent may have to extrapolate table values if the numerical value goes beyond the keywords.
A length value specifies an absolute font size (that is independent of the user agent's font table). Negative lengths are illegal.
A percentage value specifies an absolute font size relative to the parent element's font size. Use of percentage values, or values in "em's", leads to more robust and cascadable stylesheets.
This property describes the size of the font when set solid. The actual value of this property may differ from the computed value due a numerical value on "font-size-adjust" and the unavailability of certain font sizes.
One of the following:
ultra-condensed :
extra-condensed :
condensed :
semi-condensed :
normal : (Default)
semi-expanded :
expanded :
extra-expanded :
ultra-expanded :
wider :
The relative keyword "wider" sets the value to the next expanded value above the inherited value (while not increasing it above "ultra-expanded").
narrower :
The relative keyword "narrower" sets the value to the next condensed value below the inherited value (while not decreasing it below "ultra-condensed").
The "font-stretch" property selects a normal, condensed, or extended face from a font family.
One of the following:
none : (Default)
Do not preserve the font's x-height.
-or-
An positive real value (See Section 3.6.16: Positive Real).
<number>
Specifies the aspect value. The number refers to the aspect value of the first choice font. The scaling factor for available fonts is computed according to the following formula:
y(a/a') = c
where:
y = "font-size" of first-choice font
a' = aspect value of available font
c = "font-size" to apply to available font
In bicameral scripts, the subjective apparent size and legibility of a font are less dependent on their "font-size" value than on the value of their "x-height", or, more usefully, on the ratio of these two values, called the aspect value (font size divided by x-height). The higher the aspect value, the more likely it is that a font at smaller sizes will be legible. Inversely, faces with a lower aspect value will become illegible more rapidly below a given threshold size than faces with a higher aspect value. Straightforward font substitution that relies on font size alone may lead to illegible characters.
For example, the popular font Verdana has an aspect value of 0.58; when Verdana's font size 100 units, its x-height is 58 units. For comparison, Times New Roman has an aspect value of 0.46. Verdana will therefore tend to remain legible at smaller sizes than Times New Roman. Conversely, Verdana will often look "too big" if substituted for Times New Roman at a chosen size.
This property allows authors to specify an aspect value for an element that will preserve the x-height of the first choice font in the substitute font.
Font size adjustments take place when computing the actual value of "font-size". Since inheritance is based on the computed value, child elements will inherit unadjusted values.
One of the following:
normal : (Default)
Specifies a font that is classified as "normal" in the UA's font database.
oblique :
Specifies a font that is classified as "oblique" in the UA's font database. Fonts with Oblique, Slanted, or Incline in their names will typically be labeled "oblique" in the font database. A font that is labeled "oblique" in the UA's font database may actually have been generated by electronically slanting a normal font.
italic :
Specifies a font that is classified as "italic" in the UA's font database, or, if that is not available, one labeled 'oblique'. Fonts with Italic, Cursive, or Kursiv in their names will typically be labeled "italic".
The "font-style" property requests normal (sometimes referred to as "roman" or "upright"), italic, and oblique faces within a font family.
One of the following:
normal : (Default)
Specifies a font that is not labeled as a small-caps font.
small-caps :
Specifies a font that is labeled as a small-caps font. If a genuine small-caps font is not available, user agents should simulate a small-caps font, for example by taking a normal font and replacing the lowercase letters by scaled uppercase characters. As a last resort, unscaled uppercase letter glyphs in a normal font may replace glyphs in a small-caps font so that the text appears in all uppercase letters.
In a small-caps font, the glyphs for lowercase letters look similar to the uppercase ones, but in a smaller size and with slightly different proportions. The "font-variant" property requests such a font for bicameral (having two cases, as with Latin script). This property has no visible effect for scripts that are unicameral (having only one case, as with most of the world's writing systems).
Insofar as this property causes text to be transformed to uppercase, the same considerations as for "text-transform" apply.
One of the following:
normal :
Same as "400".
bold :
Same as "700".
bolder :
Specifies the next weight that is assigned to a font that is darker than the inherited one. If there is no such weight, it simply results in the next darker numerical value (and the font remains unchanged), unless the inherited value was "900", in which case the resulting weight is also "900".
lighter :
Specifies the next weight that is assigned to a font that is lighter than the inherited one. If there is no such weight, it simply results in the next lighter numerical value (and the font remains unchanged), unless the inherited value was "100", in which case the resulting weight is also "100".
-or-
An positive integer value (See Section 3.6.11: Positive Integer).
The "font-weight" property specifies the weight of the font.
<number>: 100 to 900. These values form an ordered sequence, where each number indicates a weight that is at least as dark as its predecessor.
One of the following:
none : (Default)
Indicates the country is unknown or is not significant to the proper formatting of this object.
use-document :
Indicates the country specified for the document (or derived from the xml:lang attribute) should be used in formatting this object.
-or-
A country code (See Section 3.6.20: Country).
XSL only
Specifies the country to be used by the formatter in linguistic services (such as hyphenation) and in the determination of line breaks. This affects line composition in a system-dependent way.
The country-specifier may be any ISO 3166 country code.
NOTE: In general, linguistic services depend on the "language", "script", and "country" properties.
XSL only
Specifies whether hyphenation is allowed during line-breaking when the formatter is formatting this flow object. Applies to inline and block-level objects.
A character (See Section 3.6.5: Char).
XSL only
Specifies the character to be (synthetically) inserted by the formatter when a hyphenation break occurs. This determines the glyph that is inserted when hyphenation is performed. The styling properties of this character are those inherited from its containing flow object.
NOTE: Issue: how shall we specify that styling and formatting occurs as if the character were present in the result tree?
An positive integer value (See Section 3.6.11: Positive Integer).
Defaults to 2.
XSL only
The hyphenation-push-character-count is a positive integer specifying the minimum number of characters in a hyphenated word after the hyphenation character. This is the minimum number of characters in the word pushed to the next line after the line ending with the hyphenation character.
An positive integer value (See Section 3.6.11: Positive Integer).
Defaults to 2.
XSL only
The hyphenation-remain-character-count is a positive integer specifying the minimum number of characters in a hyphenated word before the hyphenation character. This is the minimum number of characters in the word left on the line ending with the hyphenation character.
One of the following:
none : (Default)
Indicates the language is unknown or is not significant to the proper formatting of this object.
use-document :
Indicates the language specified for the document (or derived from the xml:lang attribute) should be used in formatting this object.
-or-
A country code (See Section 3.6.20: Country).
XSL only
Specifies the language to be used by the formatter in linguistic services (such as hyphenation) and in the determination of line breaks. This affects line composition in a system-dependent way.
The language-specifier may be any ISO 639 language code.
NOTE: In general, linguistic services depend on the language, script, and country properties.
One of the following:
none : (Default)
Indicates the script is unknown or is not significant to the proper formatting of this object.
use-document :
Indicates the script specified for the document (or derived from the xml:lang attribute) should be used in formatting this object.
-or-
A string (See Section 3.6.24: String).
XSL only
The script specifier is a string specifying the text's script. The following script public identifiers are defined in ISO/IEC 10179:
ISO/IEC 10179:1996//Script::Latin
ISO/IEC 10179:1996//Script::Greek
ISO/IEC 10179:1996//Script::Cyrillic
ISO/IEC 10179:1996//Script::Arabic
ISO/IEC 10179:1996//Script::Hebrew
ISO/IEC 10179:1996//Script::Armenian
ISO/IEC 10179:1996//Script::Georgian
ISO/IEC 10179:1996//Script::Devanagari
ISO/IEC 10179:1996//Script::Gujarati
ISO/IEC 10179:1996//Script::Gurmukhi
ISO/IEC 10179:1996//Script::Bengali
ISO/IEC 10179:1996//Script::Oriya
ISO/IEC 10179:1996//Script::Telugu
ISO/IEC 10179:1996//Script::Tamil
ISO/IEC 10179:1996//Script::Kannada
ISO/IEC 10179:1996//Script::Malayalam
ISO/IEC 10179:1996//Script::Thai
ISO/IEC 10179:1996//Script::Lao
ISO/IEC 10179:1996//Script::Han
ISO/IEC 10179:1996//Script::Bopomofo
ISO/IEC 10179:1996//Script::Hiragana
ISO/IEC 10179:1996//Script::Katakana
ISO/IEC 10179:1996//Script::Hangul
ISO/IEC 10179:1996//Script::Burmese
ISO/IEC 10179:1996//Script::Khmer
ISO/IEC 10179:1996//Script::Mongolian
ISO/IEC 10179:1996//Script::Ethiopian
ISO/IEC 10179:1996//Script::Sinhala
ISO/IEC 10179:1996//Script::Tibetan
ISO/IEC 10179:1996//Script::Punctuation
ISO/IEC 10179:1996//Script::Symbol
ISO/IEC 10179:1996//Script::Digit
NOTE: In general, linguistic services depend on the language, script, and country properties.
NOTE: Issue: Shall we create a set of URI's for these scripts? There is an ISO/Unicode project for identifying scripts.
One of the following:
auto : (Default)
No break shall be forced.
NOTE: Page breaks may occur as determined by the formatter's widow, orphan, keep-with-next, keep-with-previous, and page-break-inside processing rules.
column :
The last area generated by formatting this formatting object shall be the last one placed in this column.
page :
The last area generated by formatting this formatting object shall be the last one placed in this page.
even-page :
The area generated by formatting this formatting object shall be the last one in this page. The first area generated by formatting the next formatting object shall begin a new even-numbered page (a blank page may be inserted if necessary).
odd-page :
The last area generated by formatting this formatting object shall be the last one placed in this page. The first area generated by formatting the next formatting object shall begin a new odd-numbered page (a blank page may be inserted if necessary).
XSL only
Inherited: no
Specifies that the last area generated by formatting this formatting object shall be the last one placed in a particular type of area container. For the "odd-page" and "even-page" property values, it also specifies where the first area generated by formatting the next formatting object in the result tree shall be placed.
One of the following:
auto : (Default)
No break shall be forced.
NOTE: Page breaks may occur as determined by the widow, orphan, keep-with-next, keep-with-previous, and page-break-inside properties.
column :
Specifies that the first area generated by formatting this formatting object shall be the first one placed in a column.
page :
Specifies that the first area generated by formatting this formatting object shall be the first one placed in a page.
even-page :
Specifies that the first area generated by formatting this formatting object shall be the first one placed in an even-numbered page (a blank page may be inserted if necessary).
odd-page :
Specifies that the first area generated by formatting this formatting object shall be the first one placed in an odd-numbered page (a blank page may be inserted if necessary).
XSL only
Inherited: no
Specifies that the first area generated by formatting this formatting object shall be the first one placed in a particular type of area container.
XSL only
Is a Boolean specifying whether the areas generated by formatting this formatting object shall be placed in the same area as those created by formatting the next formatting object in the result tree.
XSL only
Is a Boolean specifying whether the areas generated by formatting this formatting object shall be placed in the same area as those created by formatting the previous formatting object in the result tree.
This property is not inherited.
The default value is false.
One of the following:
auto :
See the CSS2 section on computing widths and margins for behavior.
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Defaults to 0.0pt.
A percentage (See Section 3.6.12: Percent).
Margin-top is provided for compatibility with CSS.
Details on the mapping of CSS "margin" properties for XSL are given in the description of how the area traits are computed from the property values.
One of the following:
auto :
See the CSS2 section on computing widths and margins for behavior.
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Defaults to 0.0pt.
A percentage (See Section 3.6.12: Percent).
Margin-bottom is provided for compatibility with CSS. Details on the mapping of CSS "margin" properties for XSL are given in the description of how the area traits are computed from the property values.
One of the following:
auto :
See the CSS2 section on computing widths and margins for behavior.
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Defaults to 0.0pt.
A percentage (See Section 3.6.12: Percent).
Margin-left is provided for compatibility with CSS. Details on the mapping of CSS "margin" properties for XSL are given in the description of how the area traits are computed from the property values.
One of the following:
auto :
See the CSS2 section on computing widths and margins for behavior.
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Defaults to 0.0pt.
A percentage (See Section 3.6.12: Percent).
Margin-right is provided for compatibility with CSS. Details on the mapping of CSS "margin" properties for XSL are given in the description of how the area traits are computed from the property values.
Any valid padding-width (sic.) specification. See padding-before.
A shorthand property for setting margin-top, margin-right, margin-bottom, and margin-left of a block-area or inline-area.
If there is only one value, it applies to all sides. If there are two values, the top and bottom margins are set to the first value and the right and left margins are set to the second. If there are three values, the top is set to the first value, the left and right are set to the second, and the bottom is set to the third. If there are four values, they apply to the top, right, bottom, and left, respectively.
A space specification (See Section 3.6.17: Space Specifier).
0.0pt
0.0pt
0.0pt
0
0
Specifies additional space that is to be inserted preceding a block-area.
This space may be conditional at the start of an area-container via the conditionality sub-property.
Space-after on one area and space-before on the subsequent area are merged in the manner described in the formatting model.
Space-before specifies the following values as a set:
The optimum (or preferred) amount of space to be inserted.
The minimum amount of space to be inserted. "min" must be less than or equal to Opt (optimum).
The maximum amount of space to be inserted. "max" must be greater than or equal to Opt (optimum).
Controls the merging of space between blocks.
This property may be set to:
This space will be retained and not merged with other space preceding this object.
This space will be merged with other space preceding this object in accordance with the space-merging rules specified in the formatting model.
The default precedence is 0.
Controls the space-before on the first block-area placed in an area-container.
This property may be set to:
This space will be discarded at the start of an area-container.
This space will be retained at the start of an area-container.
The default conditionality is discard.
This property is not inherited and defaults to (Opt=0.0pt, min=0.0pt, max=0.0pt, precedence=0, conditionality=discard).
A space specification (See Section 3.6.17: Space Specifier).
0.0pt
0.0pt
0.0pt
0
0
Specifies additional space that is to be inserted following a block-area.
This space may be conditional at the end of an area-container via the conditionality sub-property.
Space-after on one area and space-before on the subsequent area are merged in the manner described in the formatting model.
Space-after specifies the following values as a set:
The optimum (or preferred) amount of space to be inserted.
The minimum amount of space to be inserted. "min" must be less than or equal to Opt (optimum).
The maximum amount of space to be inserted. "max" must be greater than or equal to Opt (optimum).
Controls the merging of space between blocks.
This property may be set to:
This space will be retained and not merged with other space following this object.
This space will be merged with other space following this object in accordance with the space merging rules specified in the formatting model.
The default precedence is 0.
Controls the space-after on the last block-area placed in an area-container.
This property may be set to:
This space will be discarded at the end of an area-container.
This space will be retained at the end of an area-container.
The default conditionality is discard.
This property is not inherited and defaults to (Opt=0.0pt, min=0.0pt, max=0.0pt, precedence=0, conditionality=discard).
Sets the start-indent for all block-areas and/or line-areas generated by this block-level formatting object as described in the formatting model.
This property may have a negative value, which indicates an outdent.
Sets the end-indent for all block-areas and/or line-areas generated by this block-level formatting object as described in the formatting model.
This property may have a negative value, which indicates an outdent.
This group also includes all the properties in the common-margin-properties-block group except end-indent, space-after, space-before, and start-indent
A space specification (See Section 3.6.17: Space Specifier).
0.0pt
0.0pt
0.0pt
0
0
Specifies additional space that is to be inserted following an inline-area.
This space may be conditional at the end of a line via the conditionality sub-property.
Space-end on one area and space-start on the subsequent area are merged in the manner described in the formatting model.
Space-end specifies the following values as a set:
The optimum (or preferred) amount of space to be inserted.
The minimum amount of space to be inserted. "min" must be less than or equal to Opt (optimum).
The maximum amount of space to be inserted. "max" must be greater than or equal to Opt (optimum).
Controls the merging of space between inlines.
This property may be set to:
This space will be retained and not merged with other space following this object.
This space will be merged with other space following this object in accordance with the space merging rules specified in the formatting model.
The default precedence is 0.
Controls the space-end on the last inline-area placed in a line.
This property may be set to:
This space will be discarded at the end of a line.
This space will be retained at the end of a line.
The default conditionality is discard.
This property is not inherited and defaults to (Opt=0.0pt, min=0.0pt, max=0.0pt, precedence=0, conditionality=discard).
A space specification (See Section 3.6.17: Space Specifier).
0.0pt
0.0pt
0.0pt
0
0
Specifies additional space that is to be inserted preceding an inline-area.
This space may be conditional at the start of a line via the conditionality sub-property.
Space-end on one area and space-start on the subsequent area are merged in the manner described in the formatting model.
Space-start specifies the following values as a set:
The optimum (or preferred) amount of space to be inserted.
The minimum amount of space to be inserted. "min" must be less than or equal to Opt (optimum).
The maximum amount of space to be inserted. "max" must be greater than or equal to Opt (optimum).
Controls the merging of space between inlines.
This property may be set to:
This space will be retained and not merged with other space preceding this object.
This space will be merged with other space preceding this object in accordance with the space merging rules specified in the formatting model.
The default precedence is 0.
Controls the space-start on the first inline-area placed in a line.
This property may be set to:
This space will be discarded at the start of a line.
This space will be retained at the start of a line.
The default conditionality is discard.
This property is not inherited and defaults to (Opt=0.0pt, min=0.0pt, max=0.0pt, precedence=0, conditionality=discard).
The following pagination and layout properties are all XSL only.
An positive integer value (See Section 3.6.11: Positive Integer).
Defaults to 1.
Specifies the number of columns in the region.
Does not inherit. The default value is 1, indicating that this is not a multi-column region.
Specifies the width of the gutter separation between adjacent columns in a multi-column region.
Specifies the width of the region-start or region-end or the height of the region-before or region-after. If the corresponding content in an fo:flow formatting object is absent, this space will still be reserved.
A name (See Section 3.6.1: Name).
Defines the name of the flow.
The flow-name and region-name are used to assign the flow's content to a specific region or series of regions in the layout. In this version of XSL this is done by mapping the name of a flow to a region or series of regions that have the same name and lie within the pages of the page-sequence.
NOTE: In future versions this can be overridden via a flow-map, which will allow more complex assignments.
An unsigned integer value (See Section 3.6.10: Unsigned Integer).
Defaults to no.
Sets the initial page number to be used on this page sequence.
NOTE: Issue: How can an integer default to "No"? How about a default of 1 for the first page-sequence and one more than the last page number of the previous page-sequence for the others?
A name (See Section 3.6.1: Name).
Specifies the name of the page master to be used to as the blank, even-phased filler page at the end of an alternating (odd/even) sequence of pages generated by this sequence-specifier.
A name (See Section 3.6.1: Name).
Specifies the name of the page-master to be used to construct the even-phased-pages of the sequence of pages generated by this sequence-specifier.
A name (See Section 3.6.1: Name).
Specifies the name of the page-master to be used to construct the first page of the sequence of pages generated by this sequence-specifier.
A name (See Section 3.6.1: Name).
Specifies the name of the page-master to be used to as the even-phased final content page of an alternating (odd/even) sequence of pages generated by this sequence-specifier.
A name (See Section 3.6.1: Name).
Specifies the name of the page-master to be used to as the odd-phased final content page of an alternating (odd/even) sequence of pages generated by this sequence-specifier.
This page may be followed by a filler (blank) page selected using the "page-master-blank-even" property if the next section of the document starts on an odd page.
A name (See Section 3.6.1: Name).
If this property is specified on a page-master, it provides an identifying name of the page-master. This name is subsequently referenced as the value of properties on the following formatting objects: fo:sequence-specifier-single, fo:sequence-specifier-repeating, and fo:sequence-specifier-alternating to request the use of this master to create a page instance.
A page-master-name must be unique across all page-masters.
If this property is specified on the fo:sequence-specifier-single, it specifies the name of the singleton page-master to be used.
A name (See Section 3.6.1: Name).
Specifies the name of the page-master to be used to construct the odd-phased pages of the sequence of pages generated by this sequence-specifier.
A name (See Section 3.6.1: Name).
Specifies the name of the page-master to be used to construct the non-first pages of the sequence of pages generated by this sequence-specifier.
One of the following:
auto : (Default)
The "page-height" shall be determined by the formatter from the height of the media or browser window. If media information is not available this dimension shall default to 11.0 inches (allowing it to fit on both 8+1/2x11 and A4 pages).
indefinite :
The height of the page is determined from the size of the laid-out content.
NOTE: Page-width and page-height may not both be set to indefinite. Should that occur, page-width will revert to auto and page-height will remain indefinite.
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Defaults to no.
XSL only
Specifies the height of a page area.
NOTE: Issue: the default value description needs to be reviewed.
One of the following:
auto : (Default)
The "page-width" shall be determined by the formatter from the width of the media or browser window. If media information is not available this dimension shall default to 8.0 inches (allowing it to fit on both 8+1/2x11 and A4 pages).
indefinite :
The width of the page is determined from the size of the laid-out content.
NOTE: "Page-width" and "page-height" properties may not both be set to indefinite. Should that occur, "page-width will" revert to "auto" and "page-height" will remain indefinite.
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Defaults to no.
XSL only
Specifies the width of a page area. (Size is a shorthand property to set both "page-width" and "page-height" properties simultaneously.)
The "page-width" property may be set directly or may be set via the "size" shorthand property.
NOTE: Issue: the default value descriptions need to be reviewed.
Specifies which region (i.e., region-before, region-after, region-start, or region-end) takes precedence in terms of which may extend into the corners of the simple-page-master.
A value of true specifies that this region takes precedence and extends across the full size of the page or view.
A value of false specifies that this region does not extend to the page margins. This region has the same width or height as the body.
One of the following:
before : (Default)
Positions the caption box before the table in the block-progression-direction.
after :
Positions the caption box after the table in the block-progression-direction.
start :
Positions the caption box before the table in the inline-progression-direction.
end :
Positions the caption box after the table in the inline-progression-direction.
top :
Positions the caption box above the table box.
bottom :
Positions the caption box below the table box.
left :
Positions the caption box to the left of the table box.
right :
Positions the caption box to the right of the table box.
Reference to CSS2: caption-side property -- http://www.w3.org/TR/REC-CSS2/tables.html#q6
This property specifies the position of the caption box with respect to the table box.
Captions above or below a "table" element are formatted very much as if they were a block element before or after the table, except that (1) they inherit inheritable properties from the table, and (2) they are not considered to be a block box for the purposes of any "compact" or "run-in" element that may precede the table.
A caption that is above or below a table box also behaves like a block box for width calculations; the width is computed with respect to the width of the table box's containing block.
For a caption that is on the left or right side of a table box, on the other hand, a value other than "auto" for "width" sets the width explicitly, but "auto" tells the user agent to chose a "reasonable width". This may vary between "the narrowest possible box" to "a single line", so we recommend that users do not specify "auto" for left and right caption widths.
To align caption content horizontally within the caption box, use the "text-align" property. For vertical alignment of a left or right caption box with respect to the table box, use the "vertical-align" property. The only meaningful values in this case are "top", "middle", and "bottom". All other values are treated the same as "top".
One of the following:
fixed :
Use the fixed table layout algorithm
auto : (Default)
Use any automatic table layout algorithm
Reference to CSS2: table-layout property -- http://www.w3.org/TR/REC-CSS2/tables.html#propdef-table-layout
The "table-layout" property controls the algorithm used to lay out the table cells, rows, and columns.
One of the following:
collapse : (Default)
The value "collapse" selects the collapsing borders model.
separate :
The value "separate" selects the separated borders border model.
Reference to CSS2: border-collapse property -- See http://www.w3.org/TR/REC-CSS2/tables.html#propdef-border-collapse
This property selects a table's border model. The value "separate" selects the separated borders border model. The value "collapse" selects the collapsing borders model.
A positive length (See Section 3.6.8: Positive Length).
Reference to CSS2: border-spacing property -- See http://www.w3.org/TR/REC-CSS2/tables.html#propdef-border-spacing
The lengths specify the distance that separates adjacent cell borders. If one length is specified, it gives both the horizontal and vertical spacing. If two are specified, the first gives the horizontal spacing and the second the vertical spacing. Lengths may not be negative.
In the separate borders model, each cell has an individual border. The "border-spacing" property specifies the distance between the borders of adjacent cells. This space is filled with the background of the table element. Rows, columns, row groups, and column groups cannot have borders (i.e., user agents must ignore the border properties for those elements).
NOTE: Issue: We need to decide what to do with composite properties, i.e., those values that have sub-structure.
One of the following:
show : (Default)
When this property has the value "show", borders are drawn around empty cells (like normal cells).
hide :
A value of "hide" means that no borders are drawn around empty cells. Furthermore, if all the cells in a row have a value of "hide" and have no visible content, the entire row behaves as if it had "display: none".
Reference to CSS2: empty-cells property -- See http://www.w3.org/TR/REC-CSS2/tables.html#propdef-empty-cells
In the separated borders model, this property controls the rendering of borders around cells that have no visible content. Empty cells and cells with the "visibility" property set to "hidden" are considered to have no visible content. Visible content includes " " (non-breaking-space) and other whitespace except ASCII CR ("\0D"), LF ("\0A"), tab ("\09"), and space ("\20").
See definition of property width (Section 5.18.30: width).
See definition of property height (Section 5.18.17: height).
One of the following:
yes :
This property specifies that the header should be omitted.
no : (Default)
This property specifies that the header should not be omitted.
The "table-omit-middle-header" property specifies if a table whose first area is not at the beginning of an area produced by the table should start with the content of the fo:table-header formatting object or not.
One of the following:
yes :
This property specifies that the footer should be omitted.
no : (Default)
This property specifies that the footer should not be omitted.
The "table-omit-middle-footer" property specifies if a table whose last area is not at the end of an area produced by the table should end with the content of the fo:table-header formatting object or not.
An positive integer value (See Section 3.6.11: Positive Integer).
For an fo:table-column formatting object, it specifies the column number of the table cells that are to inherit their characteristics from this fo:table-column formatting object. The default value is 1 plus the column-number of the previous table-column, if there is a previous table-column, and otherwise 1
For an fo:table-cell it specifies the number of the first column to be spanned by the table-cell. The default value is the current column-number. For the first table-cell in a table row, the current column number is 1. For other table-cells, the current column-number is the column-number of the previous table-cell in the row plus the number of columns spanned by that previous cell.
An positive integer value (See Section 3.6.11: Positive Integer).
Defaults to 1.
For an fo:table-column the "n-columns-spanned" property specifies the number of columns spanned by table-cells that are to inherit their column characteristics from this fo:table-column formatting object.
For an fo:table-cell the "n-columns-spanned" property specifies the number of columns which this cell spans in the column-progression-direction starting with the current column.
An positive integer value (See Section 3.6.11: Positive Integer).
Defaults to 1.
The "n-rows-spanned" property specifies the number of rows which this cell spans in the row-progression-direction starting with the current row.
An unsigned length (See Section 3.6.7: Unsigned Length).
The "column-width" property specifies the width of the column whose value is given by the "column-number" property. This property, if present, is ignored if the "n-columns-spanned" property is greater than 1. The "width" property must be specified for every column, unless the "table-width" property has the value "auto".
NOTE: Issue: Are the various possible specifications - fixed length, x*, % etc covered in the datatype? Do we need to specify it here?
An positive integer value (See Section 3.6.11: Positive Integer).
Defaults to 1.
The "n-columns-repeated" property specifies the repetition of a table-column specification n times; with the same effect as if the fo:table-column formatting object had been repeated n times in the result tree. The "column-number" property, for all but the first, is the column-number of the previous one plus its value of the "n-columns-spanned" property.
NOTE: This handles HTML's "colgroup" element.
See definition of property width (Section 5.18.30: width).
See definition of property height (Section 5.18.17: height).
One of the following:
yes :
The table may be broken after this row.
no : (Default)
The table may not be broken after this row.
Specifies if the table may be broken after this row.
One of the following:
yes :
The table may be broken before this row.
no : (Default)
The table may not be broken before this row.
Specifies if the table may be broken after this row.
One of the following:
yes :
This cell ends a row.
no : (Default)
This cell does not end a row.
Specifies whether this cell ends a row. This is only allowed for table-cells that are not in table-rows.
One of the following:
yes :
This cell starts a row.
no : (Default)
This cell does not start a row.
Specifies whether this cell starts a row. This is only allowed for table-cells that are not in table-rows.
See definition of property height (Section 5.18.17: height).
A string (See Section 3.6.24: String).
Specifies the Unicode character(s) to be substituted/presented.
NOTE: This property would usually hold only an individual character and the other properties of the fo:character object apply to a single character.
In order to support ligatures and composite characters (including surrogates and accented characters that are specified via a sequence of multiple Unicode code points), it is necessary to allow this property to hold a string. However, the result is a single glyph (or an overstrike composite of glyphs that behaves as if it were a single glyph) so the other properties of the fo:character object behave as if they were acting on a single character.
NOTE: XSL only property
Issue: Relationship of this property to CSS? XSL makes this property "required".
normal | <length>
Reference to CSS: letter-spacing property -- http://www.w3.org/TR/REC-CSS2/text.html#propdef-letter-spacing
This property specifies spacing behavior between text characters.
This value indicates inter-character space in addition to the default space between characters. Values may be negative, but there may be implementation-specific limits. User agents may not further increase or decrease the inter-character space in order to justify text.
Character-spacing algorithms are user agent-dependent. Character spacing may also be influenced by justification (see the "text-align" property).
Word-spacing algorithms are user agent-dependent. Word spacing is also influenced by justification (see the "text-align" property).
When the resultant space between two characters is not the same as the default space, user agents should not use ligatures.
NOTE: XSL Note: The length specifier is converted into a space-specifier with min=opt=max=<length>. This has the same effect as specifying a length in CSS.
In addition, if the user sets min<=opt<max, a combination of an initial letter-spacing adjustment and letter-spacing for justification can be performed. (This overrides the CSS restriction: "User agents may not further increase or decrease the inter-character space in order to justify text.")
normal | <length>
Reference to CSS: word-spacing property -- http://www.w3.org/TR/REC-CSS2/text.html#propdef-word-spacing
This property specifies spacing behavior between words.
none | [ underline || overline || line-through || blink ]
Reference to CSS: text-decoration property -- http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-decoration
This property describes decorations that are added to the text of an element. If the property is specified for a block-level element, it affects all inline-level descendants of the element. If it is specified for (or affects) an inline-level element, it affects all boxes generated by the element. If the element has no content or no text content (e.g., the IMG element in HTML), user agents must ignore this property.
The color(s) required for the text decoration should be derived from the "color" property value.
This property is not inherited, but descendant boxes of a block box should be formatted with the same decoration (e.g., they should all be underlined). The color of decorations should remain the same even if descendant elements have different "color" values.
Definition in CSS:
Initial: none
Applies to: all elements
Inherited:no
This property describes decorations that are added to the text of an element. If the property is specified for a block-level element, it affects all inline-level descendants of the element. If it is specified for (or affects) an inline-level element, it affects all boxes generated by the element. If the element has no content or no text content (e.g., the IMG element in HTML), user agents must ignore this property.
The color(s) required for the text decoration should be derived from the "color" property value.
This property is not inherited, but descendant boxes of a block box should be formatted with the same decoration (e.g., they should all be underlined). The color of decorations should remain the same even if descendant elements have different "color" values.
NOTE: XSL Note: XSL makes this property inherited. The initial value is still "none".
none | [<color> || <length> <length> <length>? ,]* [<color> || <length> <length> <length>?]
Reference to CSS: text-shadow property -- http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-shadow
This property accepts a comma-separated list of shadow effects to be applied to the text of the element. The shadow effects are applied in the order specified and may thus overlay each other, but they will never overlay the text itself. Shadow effects do not alter the size of a box, but may extend beyond its boundaries. The stack level of the shadow effects is the same as for the element itself.
Each shadow effect must specify a shadow offset and may optionally specify a blur radius and a shadow color.
A shadow offset is specified with two "length" values that indicate the distance from the text. The first length value specifies the horizontal distance to the right of the text. A negative horizontal length value places the shadow to the left of the text. The second length value specifies the vertical distance below the text. A negative vertical length value places the shadow above the text.
A blur radius may optionally be specified after the shadow offset. The blur radius is a length value that indicates the boundaries of the blur effect. The exact algorithm for computing the blur effect is not specified.
A color value may optionally be specified before or after the length values of the shadow effect. The color value will be used as the basis for the shadow effect. If no color is specified, the value of the "color" property will be used instead.
NOTE: XSL Note: XSL makes this property inherited. The initial value is still "none".
One of the following:
none : (Default)
No capitalization effects.
NOTE: XSL Note: Specifies that the text shall be presented in the case in which it was provided.
capitalize :
Puts the first character of each word in uppercase.
NOTE: XSL Note: Specifies that the first letter of each word shall be transformed to uppercase and all remaining letters shall be transformed to lowercase.
uppercase :
Puts all characters of each word in uppercase.
lowercase :
Puts all characters of each word in lowercase.
Reference to CSS: text-transform property -- http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-transform
The actual transformation in each case is written language dependent. See RFC 2070 ([RFC2070]) for ways to find the language of an element.
Conforming user agents may consider the value of "text-transform" to be "none" for characters that are not from the Latin-1 repertoire and for elements in languages for which the transformation is different from that specified by the case-conversion tables of ISO 10646 ([Reference to ISO10646]).
NOTE: XSL Note: No general changes from CSS definition, see specific usage of this property. However, there are severe internationalization issues with the use of this property. It has been retained for CSS compatibility, but its use is not recommended.
One of the following:
escapement : (Default)
The orientation of the rule is parallel to the escapement-progression-direction, based on the current writing-mode.
horizontal :
The orientation of the rule is horizontal (ignores writing-mode).
line-progression : (Default)
The orientation of the rule is parallel to the escapement-progression-direction, based on the current writing-mode.
vertical :
The orientation of the rule is horizontal (ignores writing-mode).
Specifies orientation of a rule.
Rules that are used to separate two phrases or rules that are placed between blocks to indicate a break in the content are generally oriented in the escapement-progression-direction.
An inline-rule with orientation-escapement will begin at the position-point for the inline (baseline-aligned) and extend along the baseline for the distance specified by its "length" property in the escapement-progression-direction (as specified by the current writing-mode).
An inline-rule with "rule-orientation" property with the value of "line-progression" will begin at the position-point for the inline area (baseline-aligned) and extend perpendicular to the baseline for the distance specified by its "length" property in the line-progression-direction (as specified by the current writing-mode).
Interaction between properties on a rule:
length
The length of a rule is always specified in the direction of the rule's orientation.
position
The position of a rule specifies the centerline of the graphical line it generates.
For inline-rules, this position can be adjusted by the "vertical-align" property.
For display-rules, this position can be adjusted by the "text-align" property.
rule-thickness
A rule's "rule-thickness" is always perpendicular to its "orientation". The rule is thickened equally on both sides of the centerline.
XSL only property
Specifies the style of the rule.
NOTE: Issue: how to reference SVG stroke properties and values?
To use rule styles, such as solid, dotted, dashed, etc. specified via SVG's stroke properties.
Specifies the thickness of the rule.
Interaction between properties on a rule:
length
The length of a rule is always specified in the direction of the rule's orientation.
position
The position of a rule specifies the centerline of the graphical line it generates.
For inline-rules, this position can be adjusted by the "vertical-align" property.
For display-rules, this position can be adjusted by the "text-align" property.
line-thickness
A rule's "rule-thickness" is always perpendicular to its "orientation". The rule is thickened equally on both sides of the centerline.
One of the following:
auto : (Default)
The length of the rule shall expand to fill any free space that remains on the current line.
-or-
An unsigned length (See Section 3.6.7: Unsigned Length).
Defaults to No.
Specifies the length of a rule.
The following are page-related properties that are not common to all formatting objects. See common-keep-and-breaks-properties.
One of the following:
auto :
Neither force nor forbid a page break before (after, inside) the generated box.
avoid :
Avoid a page break before (after, inside) the generated box.
Reference to CSS2: page-break-inside -- http://www.w3.org/TR/REC-CSS2/page.html#propdef-page-break-inside
NOTE: XSL Note:
Issue: A general "keep" mechanism is needed with the following values:
- force
the areas produced by this formatting object shall be kept together within the smallest possible area.
- page
indicating that the areas produced by the formatting object shall lie within the same page.
- column
indicating that the areas produced by the formatting object shall lie within the same column.
Issue: how to specify this properly since we do not have a column formatting object.
- none
indicating that this property is to be ignored.
See definition of property widows (Section 5.14.3: widows).
An unsigned integer value (See Section 3.6.10: Unsigned Integer).
Defaults to 2.
Reference to CSS2: "widows" property -- http://www.w3.org/TR/REC-CSS2/page.html#propdef-widows
Reference to CSS2: "orphans" property -- http://www.w3.org/TR/REC-CSS2/page.html#propdef-orphans
The "orphans" property specifies the minimum number of lines of a paragraph that must be left at the bottom of a page. The "widows" property specifies the minimum number of lines of a paragraph that must be left at the top of a page.
The following properties are all taken from CSS2. The reference is: http://www.w3.org/TR/REC-CSS2/visuren.html#floats
One of the following:
left :
The element generates a block box that is floated to the left. Content flows on the right side of the box, starting at the top (subject to the "clear" property). The "display" is ignored, unless it has the value "none".
right :
Same as "left", but content flows on the left side of the box, starting at the top.
none : (Default)
The box is not floated.
This property specifies whether a box should float to the left, right, or not at all. It may be set for elements that generate boxes that are not absolutely positioned.
See http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-float
One of the following:
left :
The top margin of the generated box is increased enough that the top border edge is below the bottom outer edge of any left-floating boxes that resulted from elements earlier in the source document.
right :
The top margin of the generated box is increased enough that the top border edge is below the bottom outer edge of any right-floating boxes that resulted from elements earlier in the source document.
both :
The generated box is moved below all floating boxes of earlier elements in the source document.
none : (Default)
No constraint on the box's position with respect to floats.
This property indicates which sides of an element's box(es) may not be adjacent to an earlier floating box. (It may be that the element itself has floating descendants; the "clear" property has no effect on those.)
This property may only be specified for block-level elements (including floats). For compact and run-in boxes, this property applies to the final block box to which the compact or run-in box belongs.
See http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-clear
See XSL Transformation
This property is defined in XSL Transformation: Number to String Conversion Attributes.
See XSL Transformation
This property is defined in XSL Transformation: Number to String Conversion Attributes.
See XSL Transformation
This property is defined in XSL Transformation: Number to String Conversion Attributes.
See XSL Transformation
This property is defined in XSL Transformation: Number to String Conversion Attributes.
See XSL Transformation
This property is defined in XSL Transformation: Number to String Conversion Attributes.
A URI (See Section 3.6.18: URI).
NOTE: Issue: This definition may be too restrictive when XSL is adapted for general (extended) links.
Specifies the destination resource of an fo:simple-link. The URI part specifies the destination document. If the URI is unspecified, the destination document defaults to the current source document.
NOTE: In this context, a "document" is any resource that can be identified by a URI.
The fragment identifier (portion of the URI following the # symbol) specifies the destination node. If the fragment identifier is unspecified, the destination node defaults to the root node of the destination document.
NOTE: Issue: The details of this must still be worked out. The concept of a "destination node" assumes that the destination is an XML document, or something that can be "viewed" as an XML document (for example, by supplying a DOM interface to it). If the target cannot be viewed as an XML document, the concept of a "target node" is not really applicable. The target, and the representation of it, is then system dependent. Examples: graphics, hotspots in graphics, sound, sound sequences, video, video clips, etc.
The destination node has to be mapped to objects in the result tree.
NOTE: Issue: should XSL 1.0 define the behavior of activating a link?
The destination flow objects are the nodes in the result tree that were generated when the destination node was processed, including all descendant flow objects.
NOTE: This will give target objects even if no flow objects were directly created when processing the destination node.
If the node never was processed, the system should inform the user.
If the node was processed, but no areas were created, the target is the (empty) point in the flow object tree where the destination node was processed.
If the node was processed at several places in the flow object tree, the system may choose any of them.
NOTE: Issue: How can we restrict this, to avoid the selection of bad nodes? Should the DSSSL approach, of taking the target that was processed without a mode before any nodes processed with a mode, be adopted? Can the target be restrained any further? Should we provide certain pages/regions/flows precedence?
The areas created from the destination flow object are the destination areas.
NOTE: If the target representation is not a node, but system dependent, the whole mapping from the target down to the display areas is system dependent.
At least one of the external-destination and internal-destination properties should be assigned. If both are assigned, the system may either report the error, or use the internal-destination property.
Default value: Unassigned
An idref value (See Section 3.6.3: IDREF).
Specifies the destination flow object of an an fo:simple-link. This property allows the destination flow object node to be explicitly specified.
At least one of the external-destination and internal-destination properties should be assigned. If both are assigned, the system may either report the error, or use the internal-destination property.
Default value: Unassigned
One of the following:
replace : (Default)
The current document view should be replaced. However, if the destination area(s) are already available in a page/region, those areas should simply be moved/scrolled "into sight".
new :
A new (additional) document view should always be opened.
Specifies where the destination resource should be displayed.
NOTE: Issue: Except for "new" and "replace", XLink also specifies "embed", where the target should be embedded in the document. This does not require an fo:simple-link object. If the embedding should be automatic, the destination node should automatically be inserted. If the embedding should be on the users demand, an fo:multi-switch formatting object should be used instead.
I believe the show-destination property on simple-link may need (at least) one additional value: "reuse".
If the "indicate-destination" property value is true, the system should, in a system-dependent manner, indicate which areas belong to the link target when traversed to it.
NOTE: This could be indicated in any feasible way, e.g., by reversed video, etc.
See definition of property space-above-destination-block (Section 5.17.6: space-above-destination-block).
An unsigned length (See Section 3.6.7: Unsigned Length).
The "space-above-destination-start" property specifies the distance from the beginning (top) of the page to the innermost line-area that contains the first destination area. If the first destination area is not contained in a line-area, the "space-above-destination-start" property instead directly specifies the distance to the top of the destination area.
The space-above-destination-block specifies the distance from the beginning (top) of the page to the innermost displayed area that contains the first destination area.
NOTE: The destination area can itself be the innermost displayed area.
If the specification of space-above-destination-start or space-above-destination-block would result in a distance longer than the distance from the start of the document, the distance from the start of the document should be used.
If both space-above-destination-start and space-above-destination-block are specified, the system should select the one that results in the minimum distance.
NOTE: Why? Assume the user wants to see 1 inch above the destination line, and nothing above the destination "block". That is, (s)he wants to see 1 inch of the before lines of the target paragraph, but doesn't care about any preceding paragraphs. Then, if the target line is also the first line of the paragraph, no context is needed, and line can be put at the top of the page.
NOTE: Issue: Define "first destination area"? Should it be possible to specify the distance relatively to the page height? "One third of the page above the target"? Should it be possible to say "show 3 lines before the target"? If so, what if a preceding line is very high, e.g. because it contains a huge graphic? See the "rule" below:
If the specified distance would push the first destination area below the page area, the distance should be decreased so the whole first destination area becomes visible, if possible. If the first destination area is higher than the page, the top of the area should be aligned with the top of the page.
If both space-above-destination-start and space-above-destination-block are unspecified, any place on the page that allows the user to immediately see the first destination area is acceptable.
NOTE: In particular, scrolling is not necessary if the target is already visible. (However, see the property "indicate-destination".)
Issue: But what if only the first area(s) are visible, but all destination areas could be made visible by scrolling the page? Should we then require scrolling?
Default value: Unspecified.
Specifies if the initial fo:multi-case should be restored when the fo:multi-switch gets hidden by an ancestor fo:multi-switch.
If the "auto-restore" property value is true, and this fo:multi-switch is contained in another fo:multi-switch, and that fo:multi-switch changes the active fo:multi-case (hiding this fo:multi-switch), then this fo:multi-switch should restore its initial fo:multi-case.
If "auto-restore" property value is false, this fo:multi-switch should retain its current fo:multi-case.
NOTE: Consider the case when several nested fo:multi-switch objects builds an expandable/collapsable table-of-contents view. If the table-of-contents is expanded far down the hierarchy, and an (far above) ancestor is closed, we (probably) want all sub-titles to have restored to their original state when that ancestor is opened again.
Specifies if the fo:multi-case can be initially displayed.
The parent fo:multi-switch shall choose the first fo:multi-case child where the property "initial" has the value equal to "true".
NOTE: Any number of the fo:multi-case objects may assign "initial" to true.
If no fo:multi-case has "initial" property value of true, the contents of any fo:multi-case should not be displayed.
NOTE: If no multi-case is displayed, the entire fo:multi-switch will effectively be hidden.
A name (See Section 3.6.1: Name).
Specifies a name for an fo:multi-case. The name must be unique among the current fo:multi-case siblings, i.e., in the scope of the fo:multi-switch object that (directly) contains them. Other instances of fo:multi-switch objects may well use the same names for its fo:multi-case objects.
The purpose of this property is to allow fo:multi-toggle objects to select fo:multi-case objects to switch to.
Default value: Unassigned
A string (See Section 3.6.24: String).
Specifies a descriptive title for the fo:multi-case. The title can be displayed in a menu to represent this fo:multi-case when an fo:multi-toggle object names several fo:multi-case objects as allowed destinations.
Default value: Unassigned
One of the following:
#preceding :
Activating the switch should result in that the current fo:multi-case is replaced by its preceding sibling.
NOTE: The current fo:multi-case is the closest ancestor fo:multi-case.
In other words, the current fo:multi-switch should switch to the previous sibling of the fo:multi-case that is currently selected.
NOTE: The current fo:multi-switch is the closest ancestor fo:multi-switch.
It the current fo:multi-case is the first sibling, #preceding should switch to the last fo:multi-case sibling.
#following :
Activating the switch should result in that the current fo:multi-case is replaced by its next sibling.
It the current fo:multi-case is the last sibling, #following should switch to the first fo:multi-case sibling.
#any : (Default)
Activating the switch should allow the user to select any other fo:multi-case sibling.
NOTE: Issue: How to actually select the multi-case is system dependent. (See the "title" property on the fo:multi-case.)
If there is only a single other fo:multi-case, the toggle should immediately switch to it (and not show that single choice to the user).
-or-
A name list (a list of names separated by white space.)
Specifies what fo:multi-case object(s) this fo:multi-toggle shall switch to.
If switch-to is a name list, the user can switch to any of the named multi-case objects. If a multi-toggle with a single name is activated, it should immediately switch to the named multi-case.
a DOM state (or event)
XSL only
The "state" property is used to control which of the fo:multi-property-sets are used to format the child flow-objects within an fo:multi-properties formatting object. The states (or at least the events that cause the state to be entered) are defined by the DOM.
One of the following:
auto :
The clipping region has the same size and location as the element's box(es).
a_shape :
In CSS2, the only valid <shape> value is: rect (<top> <right> <bottom> <left>) where <top>, <bottom> <right>, and <left> specify offsets from the respective sides of the box.
Reference to CSS2: "clip" property -- http://www.w3.org/TR/REC-CSS2/visufx.html#propdef-clip
<top>, <right>, <bottom>, and <left> may either have a <length> value or "auto". Negative lengths are permitted. The value "auto" means that a given edge of the clipping region will be the same as the edge of the element's generated box (i.e., "auto" means the same as "0".)
When coordinates are rounded to pixel coordinates, care should be taken that no pixels remain visible when <left> + <right> is equal to the element's width (or <top> + <bottom> equals the element's height), and conversely that no pixels remain hidden when these values are 0.
The "clip" property applies to elements that have a "overflow" property with a value other than "visible".
The element's ancestors may also have clipping regions (in case their "overflow" property is not "visible"); what is rendered is the intersection of the various clipping regions.
If the clipping region exceeds the bounds of the UA's document window, content may be clipped to that window by the native operating environment.
<color> Any valid color specification.
Reference to CSS2: "color" property -- See http://www.w3.org/TR/REC-CSS2/colors.html#propdef-color
This property describes the foreground color of an element's text content.
NOTE: There is work in both the CSS and SVG WGs dealing with ICC color profiles that we wish to reference for XSL. This reference will appear in the next Draft.
One of the following:
ltr :
Left to right direction.
rtl :
Right to left direction.
btt :
Added for XSL
Bottom to top direction.
ttb :
Added for XSL
Top to bottom direction.
Reference to CSS2: "direction" property -- http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-direction
This property specifies the base writing direction of blocks and the direction of embedded objects and overrides (see "unicode-bidi") for the Unicode bidirectional algorithm. In addition, it specifies the direction of table column layout, the direction of horizontal overflow, and the position of an incomplete last line in a block in case of "text-align: justify".
For the "direction" property to have any effect on inline-level elements, the "unicode-bidi" property's value must be "embed" or "override".
NOTE: The "direction" property, when specified for table column elements, is not inherited by cells in the column since columns don't exist in the document tree. Thus, CSS cannot easily capture the "dir" attribute inheritance rules described in [HTML40], section 11.3.2.1.
NOTE: XSL Note: The "direction" property only applies to the fo:bidi-override formatting object.
One of the following:
use-font-metrics : (Default)
Uses the font's value for the height of the font below the baseline.
-or-
A signed length (See Section 3.6.6: Signed Length).
Defaults to no.
Specifies the height to be used for line-spacing that lies below/after the fonts reference-position (baseline).
NOTE: Issue: this definition should be specified in terms of the agreed terminology of either "line-stacking-strategy" or as the term used in the model description "leading-method". This note also applies to the "font-height-override-before" property.
One of the following:
use-font-metrics : (Default)
Use the font's value for the height of the font above the baseline.
-or-
A signed length (See Section 3.6.6: Signed Length).
Defaults to No.
Specifies the height to be used for line-spacing that lies above/before the fonts reference-position (baseline).
One of the following:
none : (Default)
No URL is specified.
-or-
A URI (See Section 3.6.18: URI).
Specifies the URL to locate a link destination or the image/graphic data to be included as the content of this object.
One of the following:
column :
Both parts of a hyphenated word shall lie within a single column.
none :
No restriction applies. The word may be hyphenated at the end of any region.
page :
Both parts of a hyphenated word shall lie within a single page.
spread :
Both parts of a hyphenated word shall lie within a single spread.
NOTE: Issue: how are we going to define a "spread" semantically?
XSL only property
Controls whether hyphenation can be performed on the last line that fits in a given area-container.
One of the following:
none : (Default)
Any number of successive lines may be hyphenated.
-or-
An unsigned integer value (See Section 3.6.10: Unsigned Integer).
Defaults to No.
Limits the number of successive hyphenated line areas the formatter may generate in a block-area.
An id(See Section 3.6.2: ID).
An identifier unique within all objects in the result tree with the fo: namespace. It that allows references to this formatting object by other objects.
XSL only property
True indicates line breaks shall be inhibited within the inline area produced by this formatting object. This applies only to line breaks introduced by the formatter to make line areas fit in the available space.
False indicates that breaks are allow within the inline area.
Nested inlines may allow breaks, which would cause a break in the containing inline.
Specifies an indent to be applied to the last line of a block area.
This is most commonly used with a negative value specified for generating a table-of-contents with the page number hanging in an "outdent" and in similar semi-tabular material.
One of the following:
consider-shifts :
In determining the line-height, include the adjusted top-edge and bottom-edge of any characters that have a position-point-shift.
disregard-shifts :
In determining the line-height, include the unshifted top-edge and bottom-edge of any characters that have a position-point-shift.
This property is used to control if the line-height is adjusted for content that has a position-point-shift.
NOTE: This property can be used to prevent superscript and subscript characters from disrupting the line spacing.
normal | <length> | <number> | <percentage>
Tells user agents to set the computed value to a "reasonable" value based on the font size of the element. The value has the same meaning as <number>. We recommend a computed value for "normal" between 1.0 to 1.2.
The box height is set to this length. Negative values are illegal.
The computed value of the property is this number multiplied by the element's font size. Negative values are illegal. However, the number, not the computed value, is inherited.
The computed value of the property is this percentage multiplied by the element's computed font size. Negative values are illegal.
Reference to CSS2: line-height property -- http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height
If the property is set on a block-level element whose content is composed of inline-level elements, it specifies the minimal height of each generated inline box.
If the property is set on an inline-level element, it specifies the exact height of each box generated by the element. (Except for inline replaced elements, where the height of the box is given by the "height" property.)
When an element contains text that is rendered in more than one font, user agents should determine the "line-height" value according to the largest font size.
Generally, when there is only one value of "line-height" for all inline boxes in a paragraph (and no tall images), the above will ensure that baselines of successive lines are exactly "line-height" apart. This is important when columns of text in different fonts have to be aligned, for example in a table.
Note that replaced elements have a "font-size" and a "line-height" property, even if they are not used directly to determine the height of the box. The "font-size" is, however, used to define the "em" and "ex" units, and the "line-height" has a role in the "vertical-align" property.
One of the following:
line-height : (Default)
Matches CSS's line height and positioning strategy. (Uses the per-inline-height-rectangle as described in the formatting-model.)
font-height :
Uses the block's font height as adjusted by the font-height-override-before and font-height-override-after properties. (Uses the nominal-requested-line-rectangle as described in the formatting-model.)
max-height :
Uses the adjusted maximum ascender-heights and maximum descender-depth for the actual fonts and inline-areas placed on the line. This value may be further influenced by the line-height-shift-adjustment property. (Uses the maximal-line-rectangle as described in the formatting-model).
Selects the strategy for positioning adjacent lines, relative to each other.
NOTE: See issue recorded for font-height-override-before and font-height-override-after properties
See definition of property max-width (Section 5.18.16: max-width).
<length> | <percentage>
These two properties allow authors to constrain box widths to a certain range.
Specifies a fixed minimum or maximum computed width.
Specifies a percentage for determining the computed value. The percentage is calculated with respect to the width of the generated box's containing block.
(Only on "max-width") No limit on the width of the box.
See http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-min-width
See http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-max-width
<length> | <percentage> | auto
Specifies a fixed height.
Specifies a percentage height. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like "auto".
The height depends on the values of other properties.
This property specifies the content height of boxes generated by block-level and replaced elements.
This property does not apply to non-replaced inline-level elements. The height of a non-replaced inline element's boxes is given by the element's (possibly inherited) "line-height" value.
Negative values for 'height' are illegal.
For a discussion on tables see http://www.w3.org/TR/REC-CSS2/tables.html
See definition of property max-height (Section 5.18.19: max-height).
<length> | <percentage>
These two properties allow authors to constrain box heights to a certain range.
Specifies a fixed minimum or maximum computed height.
Specifies a percentage for determining the computed value. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), the percentage value is interpreted like "auto".
(Only on "max-height") No limit on the height of the box.
See http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-min-height
See http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-max-height
One of the following:
visible : (Default)
This value indicates that content is not clipped, i.e., it may be rendered outside the block box.
hidden :
This value indicates that the content is clipped and that no scrolling mechanism should be provided to view the content outside the clipping region; users will not have access to clipped content. The size and shape of the clipping region is specified by the "clip" property.
scroll :
This value indicates that the content is clipped and that if the user agent uses scrolling mechanism that is visible on the screen (such as a scroll bar or a panner), that mechanism should be displayed for a box whether or not any of its content is clipped. This avoids any problem with scrollbars appearing and disappearing in a dynamic environment. When this value is specified and the target medium is "print" or 'projection', overflowing content should be printed.
auto :
The behavior of the "auto" value is user agent-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes.
Reference to CSS2: "overflow" property -- http://www.w3.org/TR/REC-CSS2/visufx.html#propdef-overflow
This property specifies whether the content of a block-level element is clipped when it overflows the element's box (which is acting as a containing block for the content).
Even if "overflow" is set to "visible", content may be clipped to a UA's document window by the native operating environment.
An idref value (See Section 3.6.3: IDREF).
Reference to the object having the specified unique identifier.
If the "ref-id" property is not specified, it defaults to a reference to self (the current formatting object).
NOTE: Used for fo:page-number-citations and future cross-reference services.
Specifies the, provisional, distance between the end of the list-item-label and the start of the list-item-body. The value is not directly used during formatting, but is used in the computation of the value of the label-end variable.
NOTE: label-end = width of the content-area of the area-container into which the list-block is placed - (the value of the provisional-distance-between-starts + the value of the start-indent - the value of the provisional-label-separation) of the closest ancestor fo:list-block.
Specifies the, provisional, distance between the start-indents of the list-item-label and the list-item-body. The value is not directly used during formatting, but is used in the computation of the value of the body-start variable.
NOTE: body-start = the value of the start-indent + the value of the provisional-distance-between-starts of the closest ancestor fo:list-block.
A space specification (See Section 3.6.17: Space Specifier).
0.0pt
0.0pt
0.0pt
0
0
Specifies the space between items in a list, where the list-items are not grouped by fo:list-item formatting objects.
One of the following:
0 : (Default)
The reference-orientation of this area-container has the same reference-orientation (direction) as the containing area-container.
90 :
The reference-orientation of this area-container is rotated 90 degrees counter-clockwise from the reference-orientation of the containing area-container.
180 :
The reference-orientation of this area-container is rotated 180 degrees counter-clockwise from the reference-orientation of the containing area-container.
270 :
The reference-orientation of this area-container is rotated 270 degrees counter-clockwise from the reference-orientation of the containing area-container.
-90 :
The reference-orientation of this area-container is rotated 270 degrees counter-clockwise from the reference-orientation of the containing area-container.
NOTE: This is equivalent to specifying "270".
-180 :
The reference-orientation of this area-container is rotated 180 degrees counter-clockwise from the reference-orientation of the containing area-container.
-270 :
XSL only
The reference-orientation of this area-container is rotated 90 degrees counter-clockwise from the reference-orientation of the containing area-container.
The reference-orientation specifies the direction for "top" for the content-rectangle of the area-container. This is used as the reference for deriving directions, such as the block-progression-direction, line-progression direction, inline-progression direction, etc. as specified by the writing-mode property.
The "reference-orientation" property on a page-master, which has no containing area-container, is interpreted as follows: "0" specifies that "top" is the top of the page, "90" that "top" is the left edge of the page etc.
NOTE: Issue: Do the CSS2 "absolute" (top, bottom, left, right) directions change if the reference-orientation is not 0?
XSL only
Sets the scale factor for an embedded graphic or for a nested container. (Need datatype for scale-specifier: one or 2 reals: if 1--sets both x&y to same value ; if 2--sets each individually.)
scale (graphic flow object)
is either a number or a list of two numbers or one of the values max or max-uniform. If it is a number, then the graphic shall be scaled by that factor in both the horizontal and vertical directions. If it is a list of two numbers, then the graphic shall be scaled by the factor specified by the first number in the horizontal direction and by the factor specified by the second number in the vertical direction. If it is the value max-uniform, then it shall be scaled uniformly in the horizontal and vertical directions so that its size in either the horizontal or vertical direction is as large as allowed. If it is the symbol max, then it shall be scaled in the horizontal and vertical directions so that its size in the horizontal and vertical directions is as large as allowed.
This property is not inherited.
The default value is max-uniform.
NOTE: Issue: this property is written as it was taken from DSSSL. It needs to be reviewed for inclusion in XSL or removed.
scale (included-container)
is a number specifying a scaling factor to be applied to the content of the area. Numbers less than 1 shall make the content smaller. Numbers greater than 1 shall make it larger.
This property is not inherited.
If not specified, it shall default to 1.
NOTE: Issue: do we want the "scale" property on the included-container flow object?
Specifies whether the scoring shall be applied to spaces. A value of true means that scoring will be applied to spaces.
The default value is true.
<length>{1,2} | auto | landscape | portrait
Reference to CSS2: -- "size" property http://www.w3.org/TR/REC-CSS2/page.html#propdef-size
Any valid <length> specification.
The page box will be set to the size and orientation of the target sheet.
Overrides the target's orientation. The page box is the same size as the target, and the longer sides are horizontal.
Overrides the target's orientation. The page box is the same size as the target, and the shorter sides are horizontal.
This property specifies the size and orientation of a page box.
The size of a page box may either be "absolute" (fixed size) or "relative" (scalable, i.e., fitting available sheet sizes). Relative page boxes allow user agents to scale a document and make optimal use of the target size.
Length values for the "size" property create an absolute page box. If only one length value is specified, it sets both the width and height of the page box (i.e., the box is a square). Since the page box is the initial containing block, percentage values are not allowed for the "size" property.
NOTE: XSL Note: CSS composite property that is mapped to XSL's "page-height" and "page-width" properties.
One of the following:
none : (Default)
This object does not span multiple columns.
all :
XSL only
The areas resulting from this flow object shall span all the columns of a multi-column region.
Specifies if a block-level object should be placed in the current column or should span all columns of a multi-column region.
<length> | <percentage> | auto
Specifies a fixed width.
Specifies a percentage width. The percentage is calculated with respect to the width of the generated box's containing block.
The width depends on the values of other properties.
Reference to CSS2: "width" property -- http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-width
This property specifies the content width of boxes generated by block-level and replaced elements.
This property does not apply to non-replaced inline-level elements. The width of a non-replaced inline element's boxes is that of the rendered content within them (before any relative offset of children). Recall that inline boxes flow into line boxes. The width of line boxes is given by the their containing block, but may be shorted by the presence of floats.
The width of a replaced element's box is intrinsic and may be scaled by the user agent if the value of this property is different than "auto".
Negative values for "width" are illegal.
One of the following:
start : (Default)
XSL writing-mode variant of CSS property: Specifies that the contents is to be start-aligned in the inline-/escapement-progression-direction. Any excess is placed onto the end edge of the contents.
centered :
Specifies that the contents is to be centered in the inline-/escapement-progression-direction. Any excess is distributed equally onto the start and end edges of the contents.
end :
XSL writing-mode variant of CSS property: Specifies that the contents is to be end-aligned in the inline-/escapement-progression-direction. Any excess placed onto the start edge of the contents.
justified :
Specifies that the contents is to be expanded to fill the available width in the inline-/escapement-progression-direction. Any excess is distributed internally, within the contents.
page-inside :
XSL extension: If the page binding edge is the start-side, the alignment will be start. If the binding-edge is the end-side, the alignment will be end. If neither, use start-side.
NOTE: Issue: how is binding edge defined semantically?
page-outside :
XSL extension: If the page binding edge is the start-side, the alignment will be end. If the binding-edge is the end-side the alignment will be start. If neither, use end alignment.
Reference to CSS2: "text-align" property -- See http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-align.
Definition in CSS: Left, right, center, and double justify text, respectively.
<string>
Specifies a string on which cells in a table column will align (see the section on horizontal alignment in a column for details and an example). This value applies only to table cells. If set on other elements, it will be treated as "left" or "right", depending on whether "direction" is "ltr", or "rtl", respectively.
Initial: depends on user agent and writing direction
Applies to: block-level elements
Inherited:yes
This property describes how inline content of a block is aligned.
A block of text is a stack of line boxes. In the case of "left", "right" and "center", this property specifies how the inline boxes within each line box align with respect to the line box's left and right sides; alignment is not with respect to the viewport. In the case of "justify", the UA may stretch the inline boxes in addition to adjusting their positions. (See also "letter-spacing" and "word-spacing".)
NOTE: XSL Note: As with CSS Margins, the "reference-orientation" and "writing-mode" properties are used to convert "left", "center" "right", or "justify" to one of the following: "start", "centered", "end", or "justified" (note the -ed suffixes).
In addition, XSL supports the following alignments: "page-inside" and "page-outside".
The default value is start.
One of the following:
relative : (Default)
If text-align is justify, then the alignment of the last line will be start. If text-align is not justify, text-align-last will use the value of text-align.
start :
Specifies that the contents is to be start-aligned in the inline-/escapement-progression-direction. Any excess is placed onto the end edge of the contents.
end :
Specifies that the contents is to be end-aligned in the inline-/escapement-progression-direction. Any excess placed onto the start edge of the contents.
justified :
Specifies that the contents is to be expanded to fill the available width in the inline-/escapement-progression-direction. Any excess is distributed internally, within the contents.
XSL only property
Specifies the alignment of the last textline in the block in the line-progression-direction determined by the writing-mode.
A value of relative specifies that the value of the text-align property shall be used, except when that value is justify or justify-force, in which case, a value of start shall be used.
A signed length (See Section 3.6.6: Signed Length).
Reference to CSS2: "text-indent" property -- See http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-indent.
This property specifies the indentation of the first line of text in a block. More precisely, it specifies the indentation of the first box that flows into the block's first line box. The box is indented with respect to the left (or right, for right-to-left layout) edge of the line box. User agents should render this indentation as blank space.
NOTE: XSL Note: The "text-indent" property specifies an adjustment to the start-indent of the first line of text in a block-area. This indent is added to the block's start-indent.
A negative value specifies a hanging indent (outdent) on the first line.
baseline | middle | sub | super | text-top | text-bottom | <percentage> | <length> | top | bottom
Align the baseline of the box with the baseline of the parent box. If the box doesn't have a baseline, align the bottom of the box with the parent's baseline.
Align the vertical midpoint of the box with the baseline of the parent box plus half the x-height of the parent.
Lower the baseline of the box to the proper position for subscripts of the parent's box. (This value has no effect on the font size of the element's text.)
Raise the baseline of the box to the proper position for superscripts of the parent's box. (This value has no effect on the font size of the element's text.)
Align the top of the box with the top of the parent element's font.
Align the bottom of the box with the bottom of the parent element's font.
Raise (positive value) or lower (negative value) the box by this distance (a percentage of the "line-height" value). The value "0%" means the same as "baseline".
Raise (positive value) or lower (negative value) the box by this distance. The value "0cm" means the same as "baseline".
The remaining values refer to the line box in which the generated box appears:
Align the top of the box with the top of the line box.
Align the bottom of the box with the bottom of the line box.
Reference to CSS2: "vertical-align" property -- http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-vertical-align
This property affects the vertical positioning inside a line box of the boxes generated by an inline-level element. The following values only have meaning with respect to a parent inline-level element, or to a parent block-level element, if that element generates anonymous inline boxes; they have no effect if no such parent exists.
Note. Values of this property have slightly different meanings in the context of tables. Please consult the section on table height algorithms for details.
For a discussion on tables (baseline) see http://www.w3.org/TR/REC-CSS2/tables.html
One of the following:
visible :
The generated box is visible.
hidden :
The generated box is invisible (fully transparent), but still affects layout.
collapse :
Please consult the section on dynamic row and column effects in tables. If used on elements other than rows or columns, "collapse" has the same meaning as "hidden".
Reference to CSS2: "visibility" property -- http://www.w3.org/TR/REC-CSS2/visufx.html#propdef-visibility
The "visibility" property specifies whether the boxes generated by an element are rendered. Invisible boxes still affect layout (set the "display" property to "none" to suppress box generation altogether).
NOTE: Changes for XSL:
Changed to inherited and initial value=visible.
One of the following:
no-wrap :
No line-wrapping will be performed.
NOTE: In the case when lines are longer than the available width of the content-rectangle, the overflow will be treated in accordance with the "overflow" property specified on the area container.
wrap : (Default)
Line-breaking will occur if the line overflows the available block width. No special markers or other treatment will occur.
Specifies how line-wrapping (line-breaking) of the content of the formatting object is to be handled.
NOTE: Issue: do we want the CSS "white-space" property as a shorthand for specifying wrap-option and whitespace-treatment?
One of the following:
preserve : (Default)
Specifies no special action.
collapse :
Specifies that any character flow object whose character is of the Unicode character class "whitespace" shall be ignored if the preceding flow object was a character flow object also with a character of class whitespace.
ignore :
Specifies that any character flow object whose character is of Unicode character class "whitespace" should be discarded.
The "white-space-treatment" property specifies the treatment of whitespace.
One of the following:
use-page-writing-mode : (Default)
Use the writing-mode set by the page's "writing-mode" property for this region.
On a page, the writing-mode defaults to "lr-tb".
lr-tb :
Text within a line is written left-to-right and lines are placed top-to-bottom.
NOTE: Typically, this is the writing-mode for normal Latin text.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to right-to-left
inline-progression-direction to right-to-left
column-progression-direction to right-to-left
line-progression-direction to top-to-bottom
block-progression-direction to top-to-bottom
row-progression-direction to top-to-bottom
shift-direction to bottom-to-top
up-direction to bottom-to-top
rl-tb :
Text within a line is written right-to-left and lines are placed top-to-bottom.
NOTE: Typically, this writing mode is used in Arabic and Hebrew text.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to right-to-left
inline-progression-direction to right-to-left
column-progression-direction to right-to-left
line-progression-direction to top-to-bottom
block-progression-direction to top-to-bottom
row-progression-direction to top-to-bottom
shift-direction to bottom-to-top
up-direction to bottom-to-top
tb-rl :
Text within a line is written top-to-bottom and lines are placed right-to-left.
NOTE: Typically, this writing mode is used in Chinese and Japanese text.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to top-to-bottom
inline-progression-direction to top-to-bottom
column-progression-direction to top-to-bottom
line-progression-direction to right-to-left
block-progression-direction to right-to-left
row-progression-direction to right-to-left
shift-direction to left-to-right
up-direction to left-to-right
tb-lr :
Text within a line is written top-to-bottom and lines are placed left-to-right.
NOTE: This writing mode is used in Mongolian, and may be used in Western advertising and vertically written signs.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to top-to-bottom
inline-progression-direction to top-to-bottom
column-progression-direction to top-to-bottom
column-progression-direction to bottom-to-top
line-progression-direction to left-to-right
block-progression-direction to left-to-right
row-progression-direction to left-to-right
shift-direction to right-to-left
up-direction to right-to-left
bt-lr :
Text within a line is written bottom-to-top and lines are placed left-to-right.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to bottom-to-top
inline-progression-direction to bottom-to-top
column-progression-direction to bottom-to-top
line-progression-direction to left-to-right
block-progression-directionto left-to-right
row-progression-direction to left-to-right
shift-direction to right-to-left
up-direction to right-to-left
bt-rl :
Text within a line is written bottom-to-top and lines are placed right-to-left.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to bottom-to-top
inline-progression-direction to bottom-to-top
column-progression-direction to bottom-to-top
line-progression-direction to right-to-left
block-progression-direction to right-to-left
row-progression-direction to right-to-left
shift-direction to left-to-right
up-direction to left-to-right
lr-bt :
Text within a line is written left-to-right and lines are placed bottom-to-top.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to left-to-right
inline-progression-direction to left-to-right
column-progression-direction to left-to-right
line-progression-direction to top-to-bottom
block-progression-direction to top-to-bottom
row-progression-direction to top-to-bottom
shift-direction to bottom-to-top
up-direction to bottom-to-top
rl-bt :
Text within a line is written right-to-left and lines are placed bottom-to-top.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction to right-to-left
inline-progression-direction to right-to-left
column-progression-direction to right-to-left
line-progression-direction to bottom-to-top
block-progression-direction to bottom-to-top
row-progression-direction to bottom-to-top
shift-direction to top-to-bottom
up-direction to top-to-bottom
lr-alternating-rl-bt :
Text within the first line is written left-to-right, the second line is written right-to-left (continuing in alternation) and lines are placed bottom-to-top.
NOTE: Some of the less common writing modes are used for languages of scholarly interest.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction:
odd-numbered lines are left-to-right
even-numbered lines are right-to-left
inline-progression-direction:
odd-numbered lines are left-to-right
even-numbered lines are right-to-left
column-progression-direction is assumed left-to-right
line-progression-direction to bottom-to-top
block-progression-direction to bottom-to-top
row-progression-direction to bottom-to-top
shift-direction to top-to-bottom
up-direction to top-to-bottom
lr-alternating-rl-tb :
Text within the first line is written left-to-right, the second line is written right-to-left (continuing in alternation) and lines are placed top-to-bottom.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction:
odd-numbered lines are left-to-right
even-numbered lines are right-to-left
inline-progression-direction:
odd-numbered lines are left-to-right
even-numbered lines are right-to-left
column-progression-direction is assumed left-to-right
line-progression-direction to bottom-to-top
block-progression-direction to bottom-to-top
row-progression-direction to bottom-to-top
shift-direction to top-to-bottom
up-direction to top-to-bottom
lr-inverting-rl-bt :
Text within the first line is written left-to-right, the second line is written inverted and from right-to-left (continuing in alternation) and lines are placed bottom-to-top.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction:
odd-numbered-line are left-to-right
even-numbered-line are inverted and set right-to-left
inline-progression-direction:
odd-numbered-line are left-to-right
even-numbered-line are inverted and set right-to-left
column-progression-direction assumed left-to-right
line-progression-direction to bottom-to-top
block-progression-direction to bottom-to-top
row-progression-direction to bottom-to-top
shift-direction to top-to-bottom
up-direction to top-to-bottom
lr-inverting-rl-tb :
Text within the first line is written left-to-right, the second line is written inverted and from right-to-left (continuing in alternation) and lines are placed top-to-bottom.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction:
odd-numbered-line are left-to-right
even-numbered-line are inverted and set right-to-left
inline-progression-direction:
odd-numbered-line are left-to-right
even-numbered-line are inverted and set right-to-left
column-progression-direction assumed left-to-right
line-progression-direction to top-to-bottom
block-progression-direction to top-to-bottom
row-progression-direction to top-to-bottom
shift-direction to bottom-to-top
up-direction to bottom-to-top
tb-rl-in-rl-pairs :
Text is written in 2 character, right-to-left pairs.
The pairs are then stacked top-to-bottom to form a line.
The lines are placed right-to-left.
Establishes the following traits on the area to be generated by the formatter:
escapement-progression-direction: Two characters are placed right-to-left, then the pairs are placed top-to-bottom. If there are an odd number of characters in the line or inline, any single remaining character is placed in the right-hand position of the incomplete pair.
inline-progression-direction to top-to-bottom
column-progression-direction to top-to-bottom
line-progression-direction to right-to-left
block-progression-direction to right-to-left
row-progression-direction to right-to-left
shift-direction to left-to-right
up-direction to left-to-right
NOTE: This writing mode may be used for selected Korean texts.
XSL only
Writing-mode sets all the progression directions (see the formatting model). "Top", "bottom", "left", and "right" are always relative to the reference-orientation.
Block-level flow objects placed in an area-container may have the "writing-mode" property specified.
NOTE: Issue: how to restrict specified writing-modes to be "compatible" with the writing-mode of the area container?
NOTE: For arbitrary changes to the writing-mode, either the display-included-container flow object or the inline-included-container flow object, as appropriate may be used.
The bidi-override flow object may also be used to modify the writing-mode.
NOTE: Issue: the shift-direction and up-direction of the various writing-mode values need to be verified. Do we want page-writing-mode as a value?
One of the following:
auto : (Default)
The stack level of the generated box in the current stacking context is the same as its parent's box. The box does not establish a new local stacking context.
-or-
An signed integer value (See Section 3.6.9: Signed Integer).
Reference to CSS2: "z-index" property -- http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-z-index
For a positioned box, the "z-index" property specifies:
1.The stack level of the box in the current stacking context.
2.Whether the box establishes a local stacking context.
<integer>: This integer is the stack level of the generated box in the current stacking context. The box also establishes a local stacking context in which its stack level is "0".
This is a the local origin point of an area. It is the point in the area that is used as the positioning reference for placement within a parent or for aligning multiple areas.
The boundary of the portion of an area which is deemed to take up room when placing the area inside a larger area.
A "region" is a specification (in a formatting object) instructing the formatter to create one or more areas. An "area" is the result of formatting.
(See the "Formatting Model" section of this specification for more complete descriptions of all types of areas.)
Area-containers are the highest level objects in the formatted result. They specify portions of a page or portions of another area-container.
Area containers are always placed objects. (They have an x-y coordinate specifying their placement or they are attached to a designated edge of a parent area-container.)
Area-containers may set a local coordinate space and always set a local writing-mode (which inherits to all areas contained in the container.
(See the "Formatting Model" section of this specification for more complete descriptions of all types of areas.)
Area-containers contain a set of block-areas. Block areas are stacked (placed sequentially and adjacent to one another) within the area-container.
Block-areas are always stacked objects. They are stacked within the area-container or within another block-area in the direction specified by the block-progression-direction (as derived from the active writing-mode). The initial edge of one block-area is normally placed touching the final-edge of the preceding block-area. However, if space-before/space-after is specified or if the parent object has a spread or a space-out property, then space may be inserted between the block-areas in the stack.
Block-areas may be nested, however, the start-indent and end-indent of a block is measured from the area-container, not from the parent-block.
Blocks may NOT set a local coordinate space nor set a local writing-mode.
(See the "Formatting Model" section of this specification for more complete descriptions of all types of areas.)
Line-areas are stacked (placed sequentially and adjacent to one another) inside block-areas. They are always the full width of the block-area (except when adjusted by the text-indent and last-line-indent properties.
Line-areas are always stacked objects. They are stacked within the block-area in the direction specified by the active line-progression-direction (as derived from the active writing-mode). The initial edge of one line-area is normally placed touching the final-edge of the preceding line-area. However, if line-spacing is specified or if the parent object has a spread or a space-out property, then space may be inserted between the line-areas in the stack.
Line-areas are always generated by the formatter (there is no formatting object that corresponds directly to a line-area.) Line-areas may not be nested.
Line-areas may not set a local coordinate space or set a local writing-mode; however, the direction of inline-progression-direction, escapement-progression-direction, shift-direction, and up-direction may change from line-to-line on an algorithmic basis.
(See the "Formatting Model" section of this specification for more complete descriptions of all types of areas.)
Inline-areas are stacked (placed sequentially and adjacent to one another) inside line-areas or inside other inline-areas.
Inline-areas are always stacked objects. They are stacked within the line-area in the direction specified by the active inline-progression-direction (as derived from the active writing-mode). The start-edge of one inline-area is normally placed touching the end-edge of the preceding inline-area.
An inline-area is created for each inline formatting object. Additional line areas may be generated when an inline-area must be split for line-breaking or hyphenation and may be split for Unicode bidi support. Inline-areas may be nested.
Inline-areas may notset a local coordinate space or set a local writing-mode; however, the direction of inline-progression-direction and escapement-progression-direction may be changed on an algorithmic basis (for Unicode bidi) or by setting the direction property on the inline formatting object.
(See the "Formatting Model" section of this specification for more complete descriptions of all types of areas.)
Each character (glyph) generates its own inline area.
Glyph-areas are always stacked (placed sequentially and adjacent to one another) objects. They are stacked within the inline-area in the direction specified by the active escapement-progression-direction (as derived from the active writing-mode). The start-edge of one glyph-area is normally placed touching the end-edge of the preceding glyph-area. However, if letter-spacing or kerning is specified, then space may be inserted between the glyph-areas.
A glyph-area is created for each glyph (including space glyphs). Several characters may be merged into a single glyph. (This occurs when a ligature or a composite accented character can be substituted for a multi-character sequence. Glyph-areas are the lowest-level text areas and may not be nested.
(See the "Formatting Model" section of this specification for more complete descriptions of all types of areas.)
The distance from an glyph-area's position point to its nominally greatest extent in the direction opposite the line-progression-direction. This is a property of the glyph's font as a whole and not of the individual glyph represented.
A solid open rectangle surrounding an area's content-rectangle, possibly separated by padding.
A Boolean property indication if the display-space should be suppressed if it appears first or last in an area-container.
The boundary of the portion of the area in which the content of the area appears, including the allocation-rectangles of smaller areas.
The distance from an glyph-area's position point to its nominally greatest extent in the line-progression-direction. This is a property of the glyph's font as a whole and not of the individual glyph represented.
XSL uses absolute-direction-specifiers for page layout and for explicit placement of regions/area-containers.
XSL uses relative-direction-specifiers for all stacked (placed sequentially and adjacent to one another) areas (block-level and inline areas).
It also uses consistent and specific definitions for: start, end, before, after, initial, final, middle, midpoint, center, centered, justify, justified, distribute, distributed, spread, and space-out.
It should be noted that areas may have either absolute position and alignment specifiers or they may have relative position and alignment specifiers, but they may not have both.
These terms are values to properties that specify the position of one object within another or adjacent to another or the relative positioning of two aligned objects. This set of values are used only when absolute directions are applicable.
(From CSS, except as noted.)
One of the following:
the bottom-edge of
In positions: the bottom edge of an area.
In alignments: the bottommost edge of an area is aligned with the alignment-point of the referenced object, usually the bottommost edge of the container.
Used only when absolute directions are applicable.
(CSS uses center, which must be resolved based on the context of usage. XSL uses middle.)
In positions: the position halfway between top and bottom.
In alignments: the middle of an area is aligned with the alignment-point of the referenced object, usually the middle of the container.
Used only when absolute directions are applicable.
In positions: the top edge of an area.
In alignments: the topmost edge of an area is aligned with the alignment-point of the referenced object, usually the topmost edge of the container.
Used only when absolute directions are applicable.
One of the following:
In positions: the position halfway between left and right.
In alignments: the center of an area is aligned with the alignment-point of the referenced object, usually the center of the container.
Used only when absolute directions are applicable.
In positions: this term should not be used.
In alignments: the contents of the area are stretched or spaced so that it fills the available left-right width, however, additional space is also inserted at the left-edge and right-edge of the area.
Used only when absolute directions are applicable.
In positions: this term should not be used.
In alignments: the contents of the area are stretched or spaced so that it fills the available left-right width.
Used only when absolute directions are applicable.
In positions: the left edge of an area.
In alignments: the leftmost edge of an area is aligned with the alignment-point of the referenced object, usually the leftmost edge of the container.
Used only when absolute directions are applicable.
In positions: the right edge of an area.
In alignments: the rightmost edge of an area is aligned with the alignment-point of the referenced object, usually the rightmost edge of the container.
Used only when absolute directions are applicable.
These terms are values to properties that specify the position of one object within another or adjacent to another or the relative positioning of two aligned objects. This set of values are used only when relative directions are applicable.
One of the following:
In positions: The last-edge of an area in the line-/block-progression-direction, or the space-after that edge. (If the writing-mode is lr-tb, this would be the bottom edge).
In alignments: The item is placed outside the area adjacent to the last-edge (after-edge) of the area.
Used only when relative directions are applicable.
In positions: The first-edge of an area in the line-/block-progression-direction, or the space before that edge. (If the writing-mode is lr-tb, this would be the top edge).
In alignments: The item is placed outside the area adjacent to the first-edge (before-edge) of the area.
Used only when relative directions are applicable.
In positions: The last position (closest to the after-edge) that an area can be placed within its parent container.
In alignments: The object's alignment-point of the referenced object is aligned with the alignment-point of the referenced object (usually the baseline) of the last item placed within the area.
Used only when relative directions are applicable.
In positions: The first position (closest to the before-edge) that an area can be placed within its parent container.
In alignments: The object's alignment-point of the referenced object is aligned with the alignment-point of the referenced object (usually the baseline) of the first item placed within the area.
Used only when relative directions are applicable.
In positions: the position halfway between before-edge and after-edge.
In alignments: the center of an area is aligned with the alignment-point of the referenced object, usually the center of the container.
Used only when relative directions are applicable.
(Note midpoint vs. middle.)
In positions: this term should not be used.
In alignments: the contents of the area are stretched or spaced so that it fills the available initial-final height, however, additional space is also inserted at the initial-edge and final-edge of the area.
Used only when relative directions are applicable.
(Note past tense.)
In positions: this term should not be used.
In alignments: the contents of the area are stretched or spaced so that it fills the available initial-final height.
Used only when relative directions are applicable.
One of the following:
In positions: the position halfway between start and end.
In alignments: the centered point of an area is aligned with the alignment-point of the referenced object, usually the centered point of the container.
Used only when relative directions are applicable.
In positions: the edge of an area closest to the end edge indicated by the first term of the writing-mode that applies to the area. (If the writing-mode is lr-tb, this would be the right edge).
In alignments: the end edge of an area is aligned with the alignment-point of the referenced object, usually the end edge of the container.
Used only when relative directions are applicable.
In positions: this term should not be used.
In alignments: the contents of the area are stretched or spaced so that it fills the available start-end width, however, additional space is also inserted at the start-edge and end-edge of the area.
Used only when relative directions are applicable.
(Note past tense.)
In positions: the edge of an area closest to the start edge indicated by the first term of the writing-mode that applies to the area. (If the writing-mode is lr-tb, this would be the left edge).
In alignments: the start edge of an area is aligned with the alignment-point of the referenced object, usually the start edge of the container.
Used only when relative directions are applicable.
In positions: this term should not be used.
In alignments: the contents of the area are stretched or spaced so that it fills the available start-end width.
Used only when relative directions are applicable.
The term "direction" should be qualified as described in the following list. All relative positions and progressions in XSL are specified in terms of one or more of these direction-specifiers.
The "writing-mode" property is used to set these values as a set.
For some formatting objects, the "direction" property can override one of these (or the subset of the direction-specifiers that would be parallel -- for example, it may set both the block-progression-direction and the line-progression-direction or override both the inline-progression-direction and the escapement-progression-direction).
The direction of progression of sequential block-level area placements as specified by the last term of the writing-mode. (If the writing-mode is lr-tb, the block-progression-direction is top-to-bottom.)
Always perpendicular to the inline-progression-direction.
The direction of progression of sequential column area placements as specified by the first term of the writing-mode. (If the writing-mode is lr-tb, the column-progression-direction is left-to-right.)
For writing-modes that have alternating or inverting first terms, this direction does not reverse.
The direction of progression of sequential glyph area placements along the placement-path as specified by the character/glyph information. May be overridden by the direction property. May be the same as or the reverse of the inline-progression-direction. (If the writing-mode is lr-tb, the escapement-progression-direction is left-to-right.)
If unspecified, use the inline-progression-direction specified by the first term of the writing-mode.
For writing-modes that have alternating or inverting first terms, this direction reverses accordingly.
The direction of progression of sequential inline areas as specified by the first term of the writing-mode. (If the writing-mode is lr-tb, the inline-progression-direction is left-to-right.)
Usually the same direction as the escapement direction.
Perpendicular to the block-progression direction and the line-progression direction.
For writing-modes that have alternating or inverting first terms, this direction reverses accordingly.
Perpendicular to the inline-progression-direction, the direction of successive textline placements as specified by the last term of the writing-mode. (If the writing-mode is lr-tb, the line-progression-direction is top-to-bottom.)
Usually the same as the block-progression-direction.
The direction of progression of sequential row area placements as specified by the last term of the writing-mode. (If the writing-mode is lr-tb, the row-progression-direction is top-to-bottom.)
The direction of positive shift when characters, inline areas, or scores are shifted perpendicular to the inline-progression-direction. Usually the reverse of the line-progression-direction. (If the writing-mode is lr-tb, the shift-direction is bottom-to-top.)
For writing-modes that have inverting first terms, this direction reverses accordingly.
The direction of the character's up-vector.
For mixed-width-non-joining text, this is usually the same as the shift-direction.
For vertically-written ideographic text, the up-vector is the reverse of the first-term of the writing-mode. (If the writing-mode is tb-lr, the up-vector is bottom-to-top.)
For Roman text in vertically written ideographic text, the up-vector is specified by the vertical-roman-orientation property. (If the writing-mode is tb-lr: and vertical-roman-orientation=vertical then the up-direction for roman text is bottom-to-top, however, if the vertical-roman-orientation=perpendicular then the up-direction for roman-text is right-to-left.)
The term "edge" specifies each of the sides of any area, based on writing-mode. "Edge" should be qualified as follows:
The area following the current area in the direction specified by the last term of the writing-mode. (Also the edge of the current area toward the area following the current area in the direction specified by the last term of the writing-mode.)
The edge of the current area toward the area following the current area in the direction specified by the last term of the writing-mode.
The area prior to the current area in the direction specified by the last term of the writing-mode. (Also the edge of the current area toward the area prior to the current area in the direction specified by the last term of the writing-mode.)
The edge of the current area toward the area prior to the current area in the direction specified by the last term of the writing-mode.
The area following the current area in the direction specified by the first term of the writing-mode. (Also the edge of the current area toward the area following the current area in the direction specified by the first term of the writing-mode.)
For writing-modes that have alternating or inverting first terms, this direction reverses accordingly.
The area prior to the current area in the direction specified by the first term of the writing-mode. (Also the edge of the current area toward the area prior to the current area in the direction specified by the first term of the writing-mode.)
For writing-modes that have alternating or inverting first terms, this direction reverses accordingly.
A designated point of an inline-area which, when the area is placed, is used in determining the containing line-area's new placement-point. It is always on the edge opposite the position-point.
The vector from the placement-point of an inline-area to its escapement-point.
Since we have many kinds of lines, the term will be qualified as follows:
This definition needs to be written.
The rectangle associated with a line-area which is
as wide
as the content-rectangle in the inline-progression-direction, and
which in the perpendicular direction stretches from the maximum ascender-height to the
maximum descender-depth for
the actual fonts and inline-areas
placed on the line, as raised and lowered by vertical-align and
other adjustments perpendicular to the inline-progression-direction.
Used for placing the line.
The default font associated with an area. This consists of a fully qualified nominal-font name and font size.
The height from the descender-depth to the ascender-height of the default font associated with this line-area or inline-area area.
The rectangle associated with a line-area which is as wide as the content-rectangle in the inline-progression direction, and which in the perpendicular direction stretches from the ascender-height to the descender-depth of the nominal-font. Used for placing the line.
A fixed height/width adjustment that occurs between two objects within an area.
In the absence of future qualification in the property definition, if this adjustment is positive, the offset object will be displaced in the shift-direction by the distance specified.
Similarly, if this adjustment is negative, the offset object will be displaced in the reverse of shift-direction by the distance specified.
(See also: "space" and "separation".)
The open space between an area's content-rectangle and its border.
During the filling of a line-area, the point at which the next inline-area will be placed.
A designated point on one edge of an inline-area, which is used to align inline-areas along a common placement-path.
An indication of the importance of one value over another. Display-space and inline-space values with greater precedence take effect over those with lower precedence.
An attribute of a formatting object.
The specification, in a formatting object, directing/controlling the creation of an area. (Specifically an area-container.)
An attribute of a character. Usually derived through system-dependent font metric and classification services.
A fixed height/width adjustment that occurs between two areas.
If this adjustment is positive, the two areas will be separated by the resultant distance.
If this adjustment is negative, the two areas will overlap by the resultant distance.
(See also: "space" and "offset".)
A variable height/width adjustment that occurs between two areas.
If this adjustment is positive, the two areas will be separated by the resultant distance.
If this adjustment is negative, the two areas will overlap by the resultant distance.
(See also: "separation" and "offset".)
The rules used to resolve how several adjacent display spaces or inline spaces are combined into a single display space or inline space.
The following DTD documents the permitted structure of a result tree containing formatting objects that are part of the formatting object vocabulary as specified in this recommendation. It also documents the properties that apply to each formatting object.
NOTE: In an actual result tree instance any inherited property may be specified on a formatting object, but only certain properties apply to each formatting object.
<!--
Entity definitions for groups of formatting objects
-->
<!ENTITY % block-level "
fo:block
| fo:display-sequence
| fo:display-graphic
| fo:display-included-container
| fo:display-rule
| fo:table-and-caption
| fo:list-block
| fo:table
| fo:multi-switch
| fo:multi-properties
">
<!ENTITY % out-of-lines "
fo:footnote
| fo:float
">
<!ENTITY % basic-inlines "
fo:inline-sequence
| fo:character
| fo:page-number
| fo:page-number-citation
| fo:inline-graphic
| fo:inline-rule
| fo:simple-link
| fo:bidi-override
| fo:inline-included-container
">
<!ENTITY % inlines " %basic-inlines; | %out-of-lines; ">
<!--
Entity definitions for groups of properties
-->
<!ENTITY % common-aural-properties "
azimuth CDATA #IMPLIED
cue CDATA #IMPLIED
cue-after CDATA #IMPLIED
cue-before CDATA #IMPLIED
cursor CDATA #IMPLIED
elevation CDATA #IMPLIED
pause CDATA #IMPLIED
pause-after CDATA #IMPLIED
pause-before CDATA #IMPLIED
pitch CDATA #IMPLIED
pitch-range CDATA #IMPLIED
play-during CDATA #IMPLIED
richness CDATA #IMPLIED
speak CDATA #IMPLIED
speak-header CDATA #IMPLIED
speak-numeral CDATA #IMPLIED
speak-punctuation CDATA #IMPLIED
speech-rate CDATA #IMPLIED
stress CDATA #IMPLIED
voice-family CDATA #IMPLIED
volume CDATA #IMPLIED
">
<!ENTITY % common-absolute-position-properties "
bottom CDATA #IMPLIED
left CDATA #IMPLIED
position CDATA #IMPLIED
right CDATA #IMPLIED
top CDATA #IMPLIED
">
<!ENTITY % common-border-padding-and-background-properties "
background CDATA #IMPLIED
background-attachment CDATA #IMPLIED
background-color CDATA #IMPLIED
background-image CDATA #IMPLIED
background-position CDATA #IMPLIED
background-repeat CDATA #IMPLIED
border CDATA #IMPLIED
border-after-color CDATA #IMPLIED
border-after-style CDATA #IMPLIED
border-after-width CDATA #IMPLIED
border-before-color CDATA #IMPLIED
border-before-style CDATA #IMPLIED
border-before-width CDATA #IMPLIED
border-bottom CDATA #IMPLIED
border-bottom-color CDATA #IMPLIED
border-bottom-style CDATA #IMPLIED
border-bottom-width CDATA #IMPLIED
border-color CDATA #IMPLIED
border-end-color CDATA #IMPLIED
border-end-style CDATA #IMPLIED
border-end-width CDATA #IMPLIED
border-left CDATA #IMPLIED
border-left-color CDATA #IMPLIED
border-left-style CDATA #IMPLIED
border-left-width CDATA #IMPLIED
border-right CDATA #IMPLIED
border-right-color CDATA #IMPLIED
border-right-style CDATA #IMPLIED
border-right-width CDATA #IMPLIED
border-start-color CDATA #IMPLIED
border-start-style CDATA #IMPLIED
border-start-width CDATA #IMPLIED
border-style CDATA #IMPLIED
border-top CDATA #IMPLIED
border-top-color CDATA #IMPLIED
border-top-style CDATA #IMPLIED
border-top-width CDATA #IMPLIED
border-width CDATA #IMPLIED
padding CDATA #IMPLIED
padding-after CDATA #IMPLIED
padding-before CDATA #IMPLIED
padding-bottom CDATA #IMPLIED
padding-end CDATA #IMPLIED
padding-left CDATA #IMPLIED
padding-right CDATA #IMPLIED
padding-start CDATA #IMPLIED
padding-top CDATA #IMPLIED
">
<!ENTITY % common-keeps-and-breaks-properties "
break-after CDATA #IMPLIED
break-before CDATA #IMPLIED
keep-with-next CDATA #IMPLIED
keep-with-previous CDATA #IMPLIED
">
<!ENTITY % common-font-properties "
font CDATA #IMPLIED
font-family CDATA #IMPLIED
font-size CDATA #IMPLIED
font-size-adjust CDATA #IMPLIED
font-stretch CDATA #IMPLIED
font-style CDATA #IMPLIED
font-variant CDATA #IMPLIED
font-weight CDATA #IMPLIED
">
<!ENTITY % common-hyphenation-properties "
country CDATA #IMPLIED
hyphenate CDATA #IMPLIED
hyphenation-char CDATA #IMPLIED
hyphenation-push-char-count CDATA #IMPLIED
hyphenation-remain-char-count CDATA #IMPLIED
language CDATA #IMPLIED
script CDATA #IMPLIED
">
<!ENTITY % common-margin-properties-block "
margin CDATA #IMPLIED
margin-bottom CDATA #IMPLIED
margin-left CDATA #IMPLIED
margin-right CDATA #IMPLIED
margin-top CDATA #IMPLIED
end-indent CDATA #IMPLIED
space-after CDATA #IMPLIED
space-before CDATA #IMPLIED
start-indent CDATA #IMPLIED
">
<!ENTITY % common-margin-properties-inline "
margin CDATA #IMPLIED
margin-bottom CDATA #IMPLIED
margin-left CDATA #IMPLIED
margin-right CDATA #IMPLIED
margin-top CDATA #IMPLIED
space-after CDATA #IMPLIED
space-before CDATA #IMPLIED
space-end CDATA #IMPLIED
space-start CDATA #IMPLIED
">
<!--
Element structure and attributes
-->
<!ELEMENT fo:root (
fo:layout-master-set,
fo:page-sequence+
)
>
<!ATTLIST fo:root
id CDATA #IMPLIED
>
<!ELEMENT fo:layout-master-set (
fo:simple-page-master
)+
>
<!ATTLIST fo:layout-master-set
id CDATA #IMPLIED
>
<!ELEMENT fo:simple-page-master (
fo:title?,
fo:region-body,
fo:region-before?,
fo:region-after?,
fo:region-start?,
fo:region-end?
)
>
<!ATTLIST fo:simple-page-master
%common-margin-properties-block;
id CDATA #IMPLIED
page-master-name CDATA #IMPLIED
page-height CDATA #IMPLIED
page-width CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
size CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:title
(#PCDATA)
>
<!ATTLIST fo:title
%common-hyphenation-properties;
id CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:region-body EMPTY>
<!ATTLIST fo:region-body
clip CDATA #IMPLIED
column-count CDATA #IMPLIED
column-gap CDATA #IMPLIED
%common-border-padding-and-background-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
overflow CDATA #IMPLIED
vertical-align CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:region-before EMPTY>
<!ATTLIST fo:region-before
clip CDATA #IMPLIED
%common-border-padding-and-background-properties;
extent CDATA #IMPLIED
id CDATA #IMPLIED
overflow CDATA #IMPLIED
precedence CDATA #IMPLIED
vertical-align CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:region-after EMPTY>
<!ATTLIST fo:region-after
clip CDATA #IMPLIED
%common-border-padding-and-background-properties;
extent CDATA #IMPLIED
id CDATA #IMPLIED
overflow CDATA #IMPLIED
precedence CDATA #IMPLIED
vertical-align CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:region-start EMPTY>
<!ATTLIST fo:region-start
clip CDATA #IMPLIED
%common-border-padding-and-background-properties;
extent CDATA #IMPLIED
id CDATA #IMPLIED
overflow CDATA #IMPLIED
precedence CDATA #IMPLIED
vertical-align CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:region-end EMPTY>
<!ATTLIST fo:region-end
clip CDATA #IMPLIED
%common-border-padding-and-background-properties;
extent CDATA #IMPLIED
id CDATA #IMPLIED
overflow CDATA #IMPLIED
precedence CDATA #IMPLIED
vertical-align CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:page-sequence
(
fo:sequence-specification,
fo:static-content*,
fo:flow
)
>
<!ATTLIST fo:page-sequence
format CDATA #IMPLIED
id CDATA #IMPLIED
initial-page-number CDATA #IMPLIED
letter-value CDATA #IMPLIED
digit-group-sep CDATA #IMPLIED
n-digits-per-group CDATA #IMPLIED
sequence-src CDATA #IMPLIED
>
<!ELEMENT fo:sequence-specification (
(
fo:sequence-specifier-single
| fo:sequence-specifier-repeating
| fo:sequence-specifier-alternating
)+
)
>
<!ATTLIST fo:sequence-specification
id CDATA #IMPLIED
>
<!ELEMENT fo:sequence-specifier-single EMPTY>
<!ATTLIST fo:sequence-specifier-single
id CDATA #IMPLIED
page-master-name CDATA #IMPLIED
>
<!ELEMENT fo:sequence-specifier-repeating EMPTY>
<!ATTLIST fo:sequence-specifier-repeating
id CDATA #IMPLIED
page-master-first CDATA #IMPLIED
page-master-repeating CDATA #IMPLIED
>
<!ELEMENT fo:sequence-specifier-alternating EMPTY>
<!ATTLIST fo:sequence-specifier-alternating
id CDATA #IMPLIED
page-master-blank-even CDATA #IMPLIED
page-master-even CDATA #IMPLIED
page-master-first CDATA #IMPLIED
page-master-last-even CDATA #IMPLIED
page-master-last-odd CDATA #IMPLIED
page-master-odd CDATA #IMPLIED
>
<!ELEMENT fo:static-content (
%block-level;
)+
>
<!ATTLIST fo:static-content
flow-name CDATA #IMPLIED
id CDATA #IMPLIED
>
<!ELEMENT fo:flow (
%block-level;
)+
>
<!ATTLIST fo:flow
flow-name CDATA #IMPLIED
id CDATA #IMPLIED
>
<!ELEMENT fo:block (
fo:first-line-marker?,
(
#PCDATA
| %inlines;
| %block-level;
)+
)
>
<!ATTLIST fo:block
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-font-properties;
%common-hyphenation-properties;
%common-keeps-and-breaks-properties;
%common-margin-properties-block;
font-height-override-after CDATA #IMPLIED
font-height-override-before CDATA #IMPLIED
hyphenation-keep CDATA #IMPLIED
hyphenation-ladder-count CDATA #IMPLIED
id CDATA #IMPLIED
last-line-end-indent CDATA #IMPLIED
line-stacking-strategy CDATA #IMPLIED
orphans CDATA #IMPLIED
page-break-inside CDATA #IMPLIED
span CDATA #IMPLIED
text-align CDATA #IMPLIED
text-align-last CDATA #IMPLIED
text-indent CDATA #IMPLIED
whitespace-treatment CDATA #IMPLIED
widows CDATA #IMPLIED
wrap-option CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:first-line-marker EMPTY>
<!ATTLIST fo:first-line-marker
color CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-font-properties;
id CDATA #IMPLIED
letter-spacing CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
score-spaces CDATA #IMPLIED
text-decoration CDATA #IMPLIED
text-shadow CDATA #IMPLIED
text-transform CDATA #IMPLIED
word-spacing CDATA #IMPLIED
>
<!ELEMENT fo:display-sequence (
%block-level;
)+
>
<!ATTLIST fo:display-sequence
id CDATA #IMPLIED
>
<!ELEMENT fo:inline-sequence (
#PCDATA
| %inlines;
| %block-level;
)+
>
<!ATTLIST fo:inline-sequence
id CDATA #IMPLIED
>
<!ELEMENT fo:list-block (
fo:list-item+
| ( fo:list-item-label, fo:list-item-body )+
)
>
<!ATTLIST fo:list-block
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-keeps-and-breaks-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
provisional-distance-between-starts CDATA #IMPLIED
provisional-label-separation CDATA #IMPLIED
space-between-list-rows CDATA #IMPLIED
>
<!ELEMENT fo:list-item (
fo:list-item-label, fo:list-item-body
)
>
<!ATTLIST fo:list-item
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-keeps-and-breaks-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
>
<!ELEMENT fo:list-item-label (
%block-level;
)+
>
<!ATTLIST fo:list-item-label
id CDATA #IMPLIED
>
<!ELEMENT fo:list-item-body (
%block-level;
)+
>
<!ATTLIST fo:list-item-body
id CDATA #IMPLIED
>
<!ELEMENT fo:display-rule EMPTY >
<!ATTLIST fo:display-rule
color CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-keeps-and-breaks-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
length CDATA #IMPLIED
rule-orientation CDATA #IMPLIED
rule-style CDATA #IMPLIED
rule-thickness CDATA #IMPLIED
span CDATA #IMPLIED
text-align CDATA #IMPLIED
>
<!ELEMENT fo:inline-rule EMPTY >
<!ATTLIST fo:inline-rule
color CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-margin-properties-inline;
id CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
length CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
rule-orientation CDATA #IMPLIED
rule-style CDATA #IMPLIED
rule-thickness CDATA #IMPLIED
vertical-align CDATA #IMPLIED
>
<!ELEMENT fo:display-graphic EMPTY >
<!ATTLIST fo:display-graphic
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-keeps-and-breaks-properties;
%common-margin-properties-block;
height CDATA #IMPLIED
href CDATA #IMPLIED
id CDATA #IMPLIED
max-height CDATA #IMPLIED
max-width CDATA #IMPLIED
min-height CDATA #IMPLIED
min-width CDATA #IMPLIED
scale CDATA #IMPLIED
span CDATA #IMPLIED
width CDATA #IMPLIED
>
<!ELEMENT fo:inline-graphic EMPTY >
<!ATTLIST fo:inline-graphic
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-margin-properties-inline;
height CDATA #IMPLIED
href CDATA #IMPLIED
id CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
max-height CDATA #IMPLIED
max-width CDATA #IMPLIED
min-height CDATA #IMPLIED
min-width CDATA #IMPLIED
scale CDATA #IMPLIED
vertical-align CDATA #IMPLIED
width CDATA #IMPLIED
>
<!ELEMENT fo:display-included-container (
%block-level;
)+
>
<!ATTLIST fo:display-included-container
clip CDATA #IMPLIED
%common-absolute-position-properties;
%common-border-padding-and-background-properties;
%common-keeps-and-breaks-properties;
%common-margin-properties-block;
height CDATA #IMPLIED
id CDATA #IMPLIED
overflow CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
span CDATA #IMPLIED
width CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:inline-included-container (
%block-level;
)+
>
<!ATTLIST fo:inline-included-container
clip CDATA #IMPLIED
%common-absolute-position-properties;
%common-border-padding-and-background-properties;
%common-margin-properties-inline;
height CDATA #IMPLIED
id CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
overflow CDATA #IMPLIED
reference-orientation CDATA #IMPLIED
vertical-align CDATA #IMPLIED
width CDATA #IMPLIED
writing-mode CDATA #IMPLIED
>
<!ELEMENT fo:table-and-caption (
fo:table-caption?,
fo:table
)
>
<!ATTLIST fo:table-and-caption
caption-side CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
>
<!ELEMENT fo:table-caption (
%block-level;
)+
>
<!ATTLIST fo:table-caption
caption-width CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
id CDATA #IMPLIED
>
<!ELEMENT fo:table (
fo:table-column*,
fo:table-header?,
fo:table-footer?,
fo:table-body+
)
>
<!ATTLIST fo:table
border-collapse CDATA #IMPLIED
border-spacing CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-keeps-and-breaks-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
table-height CDATA #IMPLIED
table-layout CDATA #IMPLIED
table-omit-middle-footer CDATA #IMPLIED
table-omit-middle-header CDATA #IMPLIED
table-width CDATA #IMPLIED
>
<!ELEMENT fo:table-column EMPTY >
<!ATTLIST fo:table-column
column-number CDATA #IMPLIED
column-width CDATA #IMPLIED
%common-border-padding-and-background-properties;
id CDATA #IMPLIED
n-columns-repeated CDATA #IMPLIED
n-columns-spanned CDATA #IMPLIED
visibility CDATA #IMPLIED
>
<!ELEMENT (fo:table-header | fo:table-footer | fo:table-body)
(
fo:table-row+
| fo:table-cell+
)
>
<!ATTLIST (fo:table-header | fo:table-footer | fo:table-body)
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
id CDATA #IMPLIED
>
<!ELEMENT fo:table-row
(
fo:table-cell+
)
>
<!ATTLIST fo:table-row
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
id CDATA #IMPLIED
may-break-after-row CDATA #IMPLIED
may-break-before-row CDATA #IMPLIED
row-height CDATA #IMPLIED
>
<!ELEMENT fo:table-cell (
%block-level;
)+
>
<!ATTLIST fo:table-cell
cell-height CDATA #IMPLIED
column-number CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
empty-cells CDATA #IMPLIED
ends-row CDATA #IMPLIED
id CDATA #IMPLIED
n-columns-spanned CDATA #IMPLIED
n-rows-spanned CDATA #IMPLIED
starts-row CDATA #IMPLIED
>
<!ELEMENT fo:float (
%block-level;
)+ -(%out-of-lines)
>
<!ATTLIST fo:float
clip CDATA #IMPLIED
%common-border-padding-and-background-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
max-height CDATA #IMPLIED
overflow CDATA #IMPLIED
span CDATA #IMPLIED
visibility CDATA #IMPLIED
z-index CDATA #IMPLIED
>
<!ELEMENT fo:footnote (
fo:footnote-citation?,
(%block-level;)+
) -(%out-of-lines)
>
<!ATTLIST fo:footnote
clip CDATA #IMPLIED
%common-border-padding-and-background-properties;
%common-margin-properties-block;
id CDATA #IMPLIED
max-height CDATA #IMPLIED
overflow CDATA #IMPLIED
span CDATA #IMPLIED
visibility CDATA #IMPLIED
z-index CDATA #IMPLIED
>
<!ELEMENT fo:footnote-citation (
#PCDATA
| %inlines;
)+
>
<!ATTLIST fo:footnote-citation
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-font-properties;
%common-margin-properties-inline;
id CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
letter-spacing CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
score-spaces CDATA #IMPLIED
text-decoration CDATA #IMPLIED
text-shadow CDATA #IMPLIED
text-transform CDATA #IMPLIED
vertical-align CDATA #IMPLIED
word-spacing CDATA #IMPLIED
>
<!ELEMENT fo:character EMPTY>
<!ATTLIST fo:character
character CDATA #IMPLIED
color CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-font-properties;
%common-margin-properties-inline;
font-height-override-after CDATA #IMPLIED
font-height-override-before CDATA #IMPLIED
id CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
letter-spacing CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
score-spaces CDATA #IMPLIED
text-decoration CDATA #IMPLIED
text-shadow CDATA #IMPLIED
text-transform CDATA #IMPLIED
vertical-align CDATA #IMPLIED
word-spacing CDATA #IMPLIED
>
<!ELEMENT fo:page-number EMPTY>
<!ATTLIST fo:page-number
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-font-properties;
%common-margin-properties-inline;
id CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
letter-spacing CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
score-spaces CDATA #IMPLIED
text-decoration CDATA #IMPLIED
text-shadow CDATA #IMPLIED
text-transform CDATA #IMPLIED
vertical-align CDATA #IMPLIED
word-spacing CDATA #IMPLIED
>
<!ELEMENT fo:page-number-citation EMPTY>
<!ATTLIST fo:page-number-citation
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-font-properties;
%common-margin-properties-inline;
id CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
letter-spacing CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
ref-id CDATA #IMPLIED
score-spaces CDATA #IMPLIED
text-decoration CDATA #IMPLIED
text-shadow CDATA #IMPLIED
text-transform CDATA #IMPLIED
vertical-align CDATA #IMPLIED
word-spacing CDATA #IMPLIED
>
<!ELEMENT fo:bidi-override (
#PCDATA
| %inlines;
)+
>
<!ATTLIST fo:bidi-override
color CDATA #IMPLIED
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-font-properties;
direction CDATA #IMPLIED
id CDATA #IMPLIED
letter-spacing CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
score-spaces CDATA #IMPLIED
text-decoration CDATA #IMPLIED
text-shadow CDATA #IMPLIED
text-transform CDATA #IMPLIED
word-spacing CDATA #IMPLIED
>
<!ELEMENT fo:simple-link (
#PCDATA
| %inlines;
| %block-level;
)+
>
<!ATTLIST fo:simple-link
%common-absolute-position-properties;
%common-aural-properties;
%common-border-padding-and-background-properties;
%common-margin-properties-inline;
external-destination CDATA #IMPLIED
id CDATA #IMPLIED
indicate-destination CDATA #IMPLIED
inhibit-line-breaks CDATA #IMPLIED
internal-destination CDATA #IMPLIED
line-height CDATA #IMPLIED
line-height-shift-adjustment CDATA #IMPLIED
show-destination CDATA #IMPLIED
space-above-destination-start CDATA #IMPLIED
space-above-destination-block CDATA #IMPLIED
vertical-align CDATA #IMPLIED
>
<!ELEMENT fo:multi-switch (
fo:multi-case
)+
>
<!ATTLIST fo:multi-switch
auto-restore CDATA #IMPLIED
id CDATA #IMPLIED
>
<!ELEMENT fo:multi-case (
#PCDATA
| %inlines;
| %block-level;
)+ +(fo:multi-toggle)
>
<!ATTLIST fo:multi-case
id CDATA #IMPLIED
initial CDATA #IMPLIED
name CDATA #IMPLIED
title CDATA #IMPLIED
>
<!ELEMENT fo:multi-toggle (
#PCDATA
| %inlines;
)+
>
<!ATTLIST fo:multi-toggle
id CDATA #IMPLIED
switch-to CDATA #IMPLIED
>
<!ELEMENT fo:multi-properties (
fo:multi-property-set+,
(
#PCDATA
| %inlines;
| %block-level;
)+
)
>
<!ATTLIST fo:multi-properties
id CDATA #IMPLIED
>
<!ELEMENT fo:multi-property-set EMPTY>
<!ATTLIST fo:multi-property-set
id CDATA #IMPLIED
state CDATA #IMPLIED
>
The following have contributed to authoring and editing this draft:
This specification was developed and approved for publication by the W3C XSL Working Group (WG). WG approval of this specification does not necessarily imply that all WG members voted for its approval. The current members of the XSL WG are:
Sharon Adler, Inso (Co-Chair); Anders Berglund, Inso; Scott Boag, Lotus; Jeff Caruso, Bitstream; James Clark; Peter Danielsen, Bell Labs; Don Day, IBM; Stephen Deach, Adobe; Angel Diaz, IBM; Dwayne Dicks, SoftQuad; Andrew Greene, Bitstream; Paul Grosso, ArborText; Eduardo Gutentag, Sun; Mickey Kimchi, Enigma; Chris Lilley, W3C; Daniel Lipkin, Oracle; Chris Maden, O'Reilly; Jonathan Marsh, Microsoft; Alex Milowski, CommerceOne; Boris Moore, RivCom; Steve Muench, Oracle; Carolyn Pampino, Interleaf; Scott Parnell, Xerox; Vincent Quint, W3C; Gregg Reynolds, Datalogics; Jonathan Robie, Software AG; Henry Thompson, University of Edinburgh; Philip Wadler, Bell Labs; Randy Waki, Novell; Norm Walsh, ArborText; Sanjiva Weerawarana, IBM; Umit Yalcinalp, Sun; Steve Zilles, Adobe (Co-Chair)