Extensible Stylesheet Language (XSL) Version 1.1

Extensible Stylesheet Language (XSL) Version 1.1
Extensible Stylesheet Language (XSL) Version 1.1
W3C Recommendation 05 December 2006
This version:
Latest version:
Previous version:
Editor:
Anders Berglund, IBM

Please refer to the
errata
for this document, which may
include normative corrections.
See also
translations
This document is also available in these non-normative formats:
PDF by RenderX
and
XML file
W3C
MIT
ERCIM
Keio
), All Rights Reserved. W3C
liability
trademark
and
document use
rules apply.
Abstract
This specification defines the features and syntax for
the Extensible Stylesheet Language (XSL),
a language for expressing stylesheets. It consists of two
parts:
a language for transforming XML documents (XSLT), 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.
Status of this Document
This section describes the status of this document at the time of its publication.
Other documents may supersede this document.
A list of current W3C publications and the latest revision of this technical report can be found
in the
W3C technical reports index
at
Please see the Working Group's
implementation report
This Recommendation supersedes
[XSL 1.0]
, which was published 15 October 2001.
New functionality has been added to support
change marks,
indexes,
multiple flows,
and bookmarks.
Existing functionality has been extended in the areas of
graphics scaling,
"markers" and their retrieval in tables to support e.g. partial sums,
and
page number referencing.
The changes made in this document are
intended to meet the requirements for XSL 1.1 described
in
[XSL 1.1 Requirements]
A number of errata have been incorporated into the text.
See
E Changes from XSL 1.0
This document has been produced as part of the
W3C XML Activity
by
the
XSL Working Group
Please send comments about this document
to
xsl-editors@w3.org
(with
public archive
).
General public discussion of XSL takes place
on the
XSL-List
and
on the
www-xsl-fo
mailing lists.
This document has been reviewed by W3C Members,
by software developers, and by other W3C groups and interested parties,
and is endorsed by the Director as a W3C Recommendation.
It is a stable document and may be used as reference material or
cited from another document. W3C's role in making the Recommendation
is to draw attention to the specification and to promote
its widespread deployment. This enhances the functionality
and interoperability of the Web.
This document was produced by a group operating under the
5 February 2004 W3C Patent Policy
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of the group;
that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the
individual believes contains
Essential Claim(s)
must disclose the information in accordance with section
6 of the W3C Patent Policy
Table of Contents
Introduction and Overview
1.1
Processing a Stylesheet
1.1.1
Tree Transformations
1.1.2
Formatting
1.2
Benefits of XSL
1.2.1
Paging and Scrolling
1.2.2
Selectors and Tree Construction
1.2.3
An Extended Page Layout Model
1.2.4
A Comprehensive Area Model
1.2.5
Internationalization and Writing-Modes
1.2.6
Linking
XSL Transformation
2.1
Tree Construction
2.2
XSL Namespace
Introduction to Formatting
3.1
Conceptual Procedure
Area Model
4.1
Introduction
4.2
Rectangular Areas
4.2.1
Area Types
4.2.2
Common Traits
4.2.3
Geometric Definitions
4.2.4
Tree Ordering
4.2.5
Stacking Constraints
4.2.6
Font Baseline Tables
4.3
Spaces and Conditionality
4.3.1
Space-resolution Rules
4.3.2
Overconstrained space-specifiers
4.4
Block-areas
4.4.1
Stacked Block-areas
4.4.2
Intrusion Adjustments
4.5
Line-areas
4.6
Inline-areas
4.6.1
Stacked Inline-areas
4.6.2
Glyph-areas
4.7
Ordering Constraints
4.7.1
General Ordering Constraints
4.7.2
Line-building
4.7.3
Inline-building
4.8
Keeps and Breaks
4.9
Rendering Model
4.9.1
Geometry
4.9.2
Viewport Geometry
4.9.3
Visibility
4.9.4
Border, Padding, and Background
4.9.5
Intrinsic Marks
4.9.6
Layering and Conflict of Marks
4.10
Sample Area Tree
Property Refinement / Resolution
5.1
Specified, Computed, and Actual Values, and Inheritance
5.1.1
Specified Values
5.1.2
Computed Values
5.1.3
Actual Values
5.1.4
Inheritance
5.2
Shorthand Expansion
5.3
Computing the Values of Corresponding Properties
5.3.1
Border and Padding Properties
5.3.2
Margin, Space, and Indent Properties
5.3.3
Height, and Width Properties
5.3.4
Overconstrained Geometry
5.4
Simple Property to Trait Mapping
5.4.1
Background-position-horizontal and background-position-vertical Properties
5.4.2
Column-number Property
5.4.3
Text-align Property
5.4.4
Text-align-last Property
5.4.5
z-index Property
5.4.6
Language Property
5.5
Complex Property to Trait Mapping
5.5.1
Word spacing and Letter spacing Properties
5.5.2
Reference-orientation Property
5.5.3
Writing-mode and Direction Properties
5.5.4
Absolute-position Property
5.5.5
Relative-position Property
5.5.6
Text-decoration Property
5.5.7
Font Properties
5.6
Non-property Based Trait Generation
5.7
Property Based Transformations
5.7.1
Text-transform Property
5.8
Unicode BIDI Processing
5.9
Expressions
5.9.1
Property Context
5.9.2
Evaluation Order
5.9.3
Basics
5.9.4
Function Calls
5.9.5
Numerics
5.9.6
Absolute Numerics
5.9.7
Relative Numerics
5.9.7.1
Percents
5.9.7.2
Relative Lengths
5.9.8
Strings
5.9.9
Colors
5.9.10
Keywords
5.9.10.1
inherit
5.9.11
Lexical Structure
5.9.12
Expression Value Conversions
5.9.13
Definitions of Units of Measure
5.9.13.1
Pixels
5.10
Core Function Library
5.10.1
Number Functions
5.10.2
Color Functions
5.10.3
Font Functions
5.10.4
Property Value Functions
5.11
Property Datatypes
Formatting Objects
6.1
Introduction to Formatting Objects
6.1.1
Definitions Common to Many Formatting Objects
6.2
Formatting Object Content
6.3
Formatting Objects Summary
6.4
Declarations and Pagination and Layout Formatting Objects
6.4.1
Introduction
6.4.1.1
Page-sequence-masters
6.4.1.2
Page-masters
6.4.1.3
Page Generation
6.4.1.4
Flows and Flow Mapping
6.4.1.5
Constraints on Page Generation
6.4.1.6
Pagination Tree Structure
6.4.1.7
Example Flow Maps
6.4.1.7.1
Two flows mapping into their own regions
6.4.1.7.2
A flow mapping into two regions
6.4.1.7.3
Two flows mapping into a region
6.4.1.7.4
Two flows mapping into two regions
6.4.2
fo:root
6.4.3
fo:declarations
6.4.4
fo:color-profile
6.4.5
fo:page-sequence
6.4.6
fo:page-sequence-wrapper
6.4.7
fo:layout-master-set
6.4.8
fo:page-sequence-master
6.4.9
fo:single-page-master-reference
6.4.10
fo:repeatable-page-master-reference
6.4.11
fo:repeatable-page-master-alternatives
6.4.12
fo:conditional-page-master-reference
6.4.13
fo:simple-page-master
6.4.14
fo:region-body
6.4.15
fo:region-before
6.4.16
fo:region-after
6.4.17
fo:region-start
6.4.18
fo:region-end
6.4.19
fo:flow
6.4.20
fo:static-content
6.4.21
fo:title
6.4.22
fo:flow-map
6.4.23
fo:flow-assignment
6.4.24
fo:flow-source-list
6.4.25
fo:flow-name-specifier
6.4.26
fo:flow-target-list
6.4.27
fo:region-name-specifier
6.5
Block-level Formatting Objects
6.5.1
Introduction
6.5.1.1
Example
6.5.2
fo:block
6.5.3
fo:block-container
6.6
Inline-level Formatting Objects
6.6.1
Introduction
6.6.1.1
Examples
6.6.1.1.1
First Line of Paragraph in Small-caps
6.6.1.1.2
Figure with a Photograph
6.6.1.1.3
Page numbering and page number reference
6.6.1.1.4
Table of Contents with Leaders
6.6.2
fo:bidi-override
6.6.3
fo:character
6.6.4
fo:initial-property-set
6.6.5
fo:external-graphic
6.6.6
fo:instream-foreign-object
6.6.7
fo:inline
6.6.8
fo:inline-container
6.6.9
fo:leader
6.6.10
fo:page-number
6.6.11
fo:page-number-citation
6.6.12
fo:page-number-citation-last
6.6.13
fo:folio-prefix
6.6.14
fo:folio-suffix
6.6.15
fo:scaling-value-citation
6.7
Formatting Objects for Tables
6.7.1
Introduction
6.7.1.1
Examples
6.7.1.1.1
Simple Table, Centered and Indented
6.7.1.1.2
Simple Table with Relative Column-width Specifications
6.7.2
fo:table-and-caption
6.7.3
fo:table
6.7.4
fo:table-column
6.7.5
fo:table-caption
6.7.6
fo:table-header
6.7.7
fo:table-footer
6.7.8
fo:table-body
6.7.9
fo:table-row
6.7.10
fo:table-cell
6.8
Formatting Objects for Lists
6.8.1
Introduction
6.8.1.1
Examples
6.8.1.1.1
Enumerated List
6.8.1.1.2
HTML-style "dl" lists
6.8.2
fo:list-block
6.8.3
fo:list-item
6.8.4
fo:list-item-body
6.8.5
fo:list-item-label
6.9
Dynamic Effects: Link and Multi Formatting Objects
6.9.1
Introduction
6.9.1.1
Examples
6.9.1.1.1
Expandable/Collapsible Table of Contents
6.9.1.1.2
Styling an XLink Based on the Active State
6.9.2
fo:basic-link
6.9.3
fo:multi-switch
6.9.4
fo:multi-case
6.9.5
fo:multi-toggle
6.9.6
fo:multi-properties
6.9.7
fo:multi-property-set
6.10
Formatting Objects for Indexing
6.10.1
Introduction
6.10.1.1
Example
6.10.1.1.1
Associating Index Keys with Formatting Objects
6.10.1.1.2
Building the Index
6.10.1.2
Processing the Example Index
6.10.1.2.1
merge-pages-across-index-key-references="leave-separate"
6.10.1.2.2
merge-pages-across-index-key-references="merge"
6.10.1.3
Example Index
6.10.2
fo:index-page-number-prefix
6.10.3
fo:index-page-number-suffix
6.10.4
fo:index-range-begin
6.10.5
fo:index-range-end
6.10.6
fo:index-key-reference
6.10.7
fo:index-page-citation-list
6.10.8
fo:index-page-citation-list-separator
6.10.9
fo:index-page-citation-range-separator
6.11
Formatting Objects for Bookmarks
6.11.1
fo:bookmark-tree
6.11.2
fo:bookmark
6.11.3
fo:bookmark-title
6.12
Out-of-Line Formatting Objects
6.12.1
Introduction
6.12.1.1
Floats
6.12.1.2
Footnotes
6.12.1.3
Conditional Sub-Regions
6.12.1.4
Examples
6.12.1.4.1
Floating Figure
6.12.1.4.2
Footnote
6.12.2
fo:float
6.12.3
fo:footnote
6.12.4
fo:footnote-body
6.13
Other Formatting Objects
6.13.1
Introduction
6.13.1.1
Examples
6.13.1.1.1
Wrapper
6.13.1.1.2
Table Markers
6.13.2
fo:change-bar-begin
6.13.3
fo:change-bar-end
6.13.4
fo:wrapper
6.13.5
fo:marker
6.13.6
fo:retrieve-marker
6.13.7
fo:retrieve-table-marker
Formatting Properties
7.1
Description of Property Groups
7.2
XSL Areas and the CSS Box Model
7.3
Reference Rectangle for Percentage Computations
7.4
Additional CSS Datatypes
7.5
Common Accessibility Properties
7.5.1
source-document
7.5.2
role
7.6
Common Absolute Position Properties
7.6.1
absolute-position
7.6.2
top
7.6.3
right
7.6.4
bottom
7.6.5
left
7.7
Common Aural Properties
7.7.1
azimuth
7.7.2
cue-after
7.7.3
cue-before
7.7.4
elevation
7.7.5
pause-after
7.7.6
pause-before
7.7.7
pitch
7.7.8
pitch-range
7.7.9
play-during
7.7.10
richness
7.7.11
speak
7.7.12
speak-header
7.7.13
speak-numeral
7.7.14
speak-punctuation
7.7.15
speech-rate
7.7.16
stress
7.7.17
voice-family
7.7.18
volume
7.8
Common Border, Padding, and Background Properties
7.8.1
background-attachment
7.8.2
background-color
7.8.3
background-image
7.8.4
background-repeat
7.8.5
background-position-horizontal
7.8.6
background-position-vertical
7.8.7
border-before-color
7.8.8
border-before-style
7.8.9
border-before-width
7.8.10
border-after-color
7.8.11
border-after-style
7.8.12
border-after-width
7.8.13
border-start-color
7.8.14
border-start-style
7.8.15
border-start-width
7.8.16
border-end-color
7.8.17
border-end-style
7.8.18
border-end-width
7.8.19
border-top-color
7.8.20
border-top-style
7.8.21
border-top-width
7.8.22
border-bottom-color
7.8.23
border-bottom-style
7.8.24
border-bottom-width
7.8.25
border-left-color
7.8.26
border-left-style
7.8.27
border-left-width
7.8.28
border-right-color
7.8.29
border-right-style
7.8.30
border-right-width
7.8.31
padding-before
7.8.32
padding-after
7.8.33
padding-start
7.8.34
padding-end
7.8.35
padding-top
7.8.36
padding-bottom
7.8.37
padding-left
7.8.38
padding-right
7.9
Common Font Properties
7.9.1
Fonts and Font Data
7.9.2
font-family
7.9.3
font-selection-strategy
7.9.4
font-size
7.9.5
font-stretch
7.9.6
font-size-adjust
7.9.7
font-style
7.9.8
font-variant
7.9.9
font-weight
7.10
Common Hyphenation Properties
7.10.1
country
7.10.2
language
7.10.3
script
7.10.4
hyphenate
7.10.5
hyphenation-character
7.10.6
hyphenation-push-character-count
7.10.7
hyphenation-remain-character-count
7.11
Common Margin Properties-Block
7.11.1
margin-top
7.11.2
margin-bottom
7.11.3
margin-left
7.11.4
margin-right
7.11.5
space-before
7.11.6
space-after
7.11.7
start-indent
7.11.8
end-indent
7.12
Common Margin Properties-Inline
7.12.1
margin-top
7.12.2
margin-bottom
7.12.3
margin-left
7.12.4
margin-right
7.12.5
space-end
7.12.6
space-start
7.13
Common Relative Position Properties
7.13.1
top
7.13.2
right
7.13.3
bottom
7.13.4
left
7.13.5
relative-position
7.14
Area Alignment Properties
7.14.1
alignment-adjust
7.14.2
alignment-baseline
7.14.3
baseline-shift
7.14.4
display-align
7.14.5
dominant-baseline
7.14.6
relative-align
7.15
Area Dimension Properties
7.15.1
allowed-height-scale
7.15.2
allowed-width-scale
7.15.3
block-progression-dimension
7.15.4
content-height
7.15.5
content-width
7.15.6
height
7.15.7
inline-progression-dimension
7.15.8
max-height
7.15.9
max-width
7.15.10
min-height
7.15.11
min-width
7.15.12
scaling
7.15.13
scaling-method
7.15.14
width
7.16
Block and Line-related Properties
7.16.1
hyphenation-keep
7.16.2
hyphenation-ladder-count
7.16.3
last-line-end-indent
7.16.4
line-height
7.16.5
line-height-shift-adjustment
7.16.6
line-stacking-strategy
7.16.7
linefeed-treatment
7.16.8
white-space-treatment
7.16.9
text-align
7.16.10
text-align-last
7.16.11
text-indent
7.16.12
white-space-collapse
7.16.13
wrap-option
7.17
Character Properties
7.17.1
character
7.17.2
letter-spacing
7.17.3
suppress-at-line-break
7.17.4
text-decoration
7.17.5
text-shadow
7.17.6
text-transform
7.17.7
treat-as-word-space
7.17.8
word-spacing
7.18
Color-related Properties
7.18.1
color
7.18.2
color-profile-name
7.18.3
rendering-intent
7.19
Float-related Properties
7.19.1
clear
7.19.2
float
7.19.3
intrusion-displace
7.20
Keeps and Breaks Properties
7.20.1
break-after
7.20.2
break-before
7.20.3
keep-together
7.20.4
keep-with-next
7.20.5
keep-with-previous
7.20.6
orphans
7.20.7
widows
7.21
Layout-related Properties
7.21.1
clip
7.21.2
overflow
7.21.3
reference-orientation
7.21.4
span
7.22
Leader and Rule Properties
7.22.1
leader-alignment
7.22.2
leader-pattern
7.22.3
leader-pattern-width
7.22.4
leader-length
7.22.5
rule-style
7.22.6
rule-thickness
7.23
Properties for Dynamic Effects Formatting Objects
7.23.1
active-state
7.23.2
auto-restore
7.23.3
case-name
7.23.4
case-title
7.23.5
destination-placement-offset
7.23.6
external-destination
7.23.7
indicate-destination
7.23.8
internal-destination
7.23.9
show-destination
7.23.10
starting-state
7.23.11
switch-to
7.23.12
target-presentation-context
7.23.13
target-processing-context
7.23.14
target-stylesheet
7.24
Properties for Indexing
7.24.1
index-class
7.24.2
index-key
7.24.3
page-number-treatment
7.24.4
merge-ranges-across-index-key-references
7.24.5
merge-sequential-page-numbers
7.24.6
merge-pages-across-index-key-references
7.24.7
ref-index-key
7.25
Properties for Markers
7.25.1
marker-class-name
7.25.2
retrieve-boundary-within-table
7.25.3
retrieve-class-name
7.25.4
retrieve-position
7.25.5
retrieve-boundary
7.25.6
retrieve-position-within-table
7.26
Properties for Number to String Conversion
7.26.1
format
7.26.2
grouping-separator
7.26.3
grouping-size
7.26.4
letter-value
7.27
Pagination and Layout Properties
7.27.1
blank-or-not-blank
7.27.2
column-count
7.27.3
column-gap
7.27.4
extent
7.27.5
flow-name
7.27.6
force-page-count
7.27.7
initial-page-number
7.27.8
master-name
7.27.9
master-reference
7.27.10
maximum-repeats
7.27.11
media-usage
7.27.12
odd-or-even
7.27.13
page-height
7.27.14
page-position
7.27.15
page-width
7.27.16
precedence
7.27.17
region-name
7.27.18
flow-map-name
7.27.19
flow-map-reference
7.27.20
flow-name-reference
7.27.21
region-name-reference
7.28
Table Properties
7.28.1
border-after-precedence
7.28.2
border-before-precedence
7.28.3
border-collapse
7.28.4
border-end-precedence
7.28.5
border-separation
7.28.6
border-start-precedence
7.28.7
caption-side
7.28.8
column-number
7.28.9
column-width
7.28.10
empty-cells
7.28.11
ends-row
7.28.12
number-columns-repeated
7.28.13
number-columns-spanned
7.28.14
number-rows-spanned
7.28.15
starts-row
7.28.16
table-layout
7.28.17
table-omit-footer-at-break
7.28.18
table-omit-header-at-break
7.29
Writing-mode-related Properties
7.29.1
direction
7.29.2
glyph-orientation-horizontal
7.29.3
glyph-orientation-vertical
7.29.4
text-altitude
7.29.5
text-depth
7.29.6
unicode-bidi
7.29.7
writing-mode
7.30
Miscellaneous Properties
7.30.1
change-bar-class
7.30.2
change-bar-color
7.30.3
change-bar-offset
7.30.4
change-bar-placement
7.30.5
change-bar-style
7.30.6
change-bar-width
7.30.7
content-type
7.30.8
id
7.30.9
intrinsic-scale-value
7.30.10
page-citation-strategy
7.30.11
provisional-label-separation
7.30.12
provisional-distance-between-starts
7.30.13
ref-id
7.30.14
scale-option
7.30.15
score-spaces
7.30.16
src
7.30.17
visibility
7.30.18
z-index
7.31
Shorthand Properties
7.31.1
background
7.31.2
background-position
7.31.3
border
7.31.4
border-bottom
7.31.5
border-color
7.31.6
border-left
7.31.7
border-right
7.31.8
border-style
7.31.9
border-spacing
7.31.10
border-top
7.31.11
border-width
7.31.12
cue
7.31.13
font
7.31.14
margin
7.31.15
padding
7.31.16
page-break-after
7.31.17
page-break-before
7.31.18
page-break-inside
7.31.19
pause
7.31.20
position
7.31.21
size
7.31.22
vertical-align
7.31.23
white-space
7.31.24
xml:lang
Conformance
Appendices
Formatting Object Summary
A.1
Declaration and Pagination and Layout Formatting Objects
A.2
Block Formatting Objects
A.3
Inline Formatting Objects
A.4
Table Formatting Objects
A.5
List Formatting Objects
A.6
Link and Multi Formatting Objects
A.7
Out-of-line Formatting Objects
A.8
Formatting Objects for Indexing
A.9
Formatting Objects for Bookmarks
A.10
Other Formatting Objects
Property Summary
B.1
Explanation of Trait Mapping Values
B.2
Property Table: Part I
B.3
Property Table: Part II
B.4
Properties and the FOs they apply to
References
C.1
Normative References
C.2
Other References
Property Index
Changes from XSL 1.0
(Non-Normative)
Acknowledgements
(Non-Normative)
1 Introduction and Overview
This specification defines the Extensible Stylesheet Language
(XSL). XSL is a language for expressing stylesheets. Given a class of
arbitrarily structured XML
[XML]
or
[XML 1.1]
documents or data files, 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
hand-held device, or a set of
physical pages in a catalog, report, pamphlet, or book.
1.1 Processing a Stylesheet
An XSL
stylesheet processor
accepts a document
or data in XML
and an XSL stylesheet and produces the presentation of that XML source
content that was intended by the designer of that
stylesheet. There are two aspects of this
presentation process:
first, constructing a result tree from the XML source tree and second,
interpreting the result tree to produce formatted
results suitable for presentation on a
display, on paper, in speech, or onto other media. The first
aspect is called
tree transformation
and the
second
is called
formatting
. The process of formatting
is performed by the
formatter.
This formatter
may simply be a rendering engine inside a browser.
Tree transformation allows the structure of the result tree to be significantly
different from the structure of the source tree. For example, one could add
a table-of-contents as a filtered selection of an original source document,
or one could rearrange source data into a sorted tabular presentation.
In constructing the result tree,
the tree transformation process also adds the information necessary to
format that result tree.
Formatting is enabled by including formatting semantics
in the result tree. Formatting semantics are
expressed in terms of a catalog of classes of
formatting
objects.
The nodes of the result tree are formatting
objects. The classes of formatting objects
denote typographic abstractions such as page, paragraph,
table, and so
forth. Finer control over the presentation of these abstractions is
provided by a set of
formatting properties
, such as
those controlling indents, word- and
letter spacing, and widow, orphan, and hyphenation control.
In XSL, the
classes of formatting objects and
formatting properties
provide the vocabulary for expressing presentation intent.
The XSL processing model is intended to be
conceptual only. An implementation is not
mandated to provide these as separate
processes. Furthermore, implementations are free to process
the source document in any way that produces the same result
as if it were processed using the conceptual XSL processing
model. A diagram depicting the detailed conceptual model is
shown below.
[D]
XSL Two Processes: Transformation & Formatting
1.1.1 Tree Transformations
Tree transformation constructs the result tree. In XSL,
this tree is called the
element and attribute
tree,
with objects primarily in the
"formatting object" namespace. In this tree, a formatting
object
is represented as an XML element, with the properties represented by a
set of XML attribute-value pairs. The content of the formatting object
is the content of the XML element. Tree
transformation is defined in the XSLT Recommendation
[XSLT]
A diagram depicting this conceptual process is
shown below.
[D]
Transform to Another Vocabulary
The XSL stylesheet is used in tree transformation. A stylesheet
contains a set of tree construction rules. The tree construction rules
have two parts: a pattern that is matched against elements in the
source tree and a template that constructs a portion of the result
tree. This allows a stylesheet to be applicable to a wide class of
documents that have similar source tree structures.
In some implementations of XSL/XSLT,
the result of tree construction
can be output as an XML document. This would allow an XML document
which contains formatting objects and formatting properties to be
output. This capability is neither necessary for an XSL processor nor
is it encouraged. There are, however, cases where this is important,
such as a server preparing input for a known client; for example, the way
that a WAP
server prepares specialized input for a WAP capable
hand held device. To preserve accessibility, designers of Web systems
should not develop architectures that require (or use) the
transmission of documents containing formatting objects and properties
unless either the transmitter knows that the client can accept
formatting objects and properties or the transmitted document contains
a reference to the source document(s) used in the construction of the
document with the formatting objects and properties.
1.1.2 Formatting
Formatting interprets the result tree in its formatting object tree
form to produce the presentation intended by the designer
of the stylesheet from which the XML element and attribute
tree in the "fo" namespace was constructed.
The vocabulary of formatting objects supported by XSL - the set of
fo:
element types - represents the set of
typographic abstractions available to the
designer. Semantically, each formatting object represents a
specification for a part of the pagination, layout, and styling
information that will be applied to the content of that formatting
object as a result of formatting the whole result tree. Each
formatting object class represents a particular kind of formatting
behavior. For example, the block formatting object class represents
the breaking of the content of a paragraph into lines. Other parts of
the specification may come from other formatting objects; for
example, the formatting of a paragraph (block formatting
object)
depends on both the specification of properties on the block
formatting object and the specification of the layout structure into
which the block is placed by the formatter.
The properties associated with an instance of a formatting object
control the formatting of that object. Some of the properties, for
example "color", directly specify the formatted result.
Other properties, for example 'space-before', only constrain the set
of possible formatted results without specifying any particular
formatted result. The formatter may make choices among other
possible considerations such as esthetics.
Formatting consists of the generation of a tree
of geometric areas, called the
area tree
. The
geometric areas are
positioned on a sequence of one or more pages (a browser typically
uses a single page). Each geometric area has a position on the page, a
specification of what to display in that area and may have a
background, padding, and borders. For example, formatting a
single
character generates an area sufficiently large enough to hold the
glyph that is used to present the character visually and the glyph is
what is displayed in this area. These areas may be nested. For
example, the glyph may be positioned within a line, within a
block, within a page.
Rendering
takes the area tree, the abstract model of the presentation (in terms
of pages and their collections of areas), and causes a
presentation to appear on the relevant medium, such as a browser
window on a computer display screen or sheets of paper. The semantics
of rendering are not described in detail in this specification.
The first step in formatting is to "objectify" the element
and attribute
tree obtained via an XSLT transformation.
Objectifying the tree basically consists of turning the
elements in the
tree into formatting object nodes and the
attributes into property specifications. The result of this step is
the
formatting object tree
[D]
Build the XSL Formatting Object Tree
As part of the step of objectifying, the characters that occur in
the result tree are replaced by fo:character nodes.
Characters in text nodes which consist
solely of white space characters and
which are children of elements whose corresponding formatting objects do
not permit fo:character nodes as children are ignored. Other characters
within elements whose corresponding formatting objects do not permit
fo:character nodes as children are errors.
The content of the fo:instream-foreign-object
is not objectified;
instead the object representing the fo:instream-foreign-object
element points to the appropriate node in the element and
attribute tree.
Similarly any non-XSL namespace child element
of fo:declarations is not objectified; instead the object representing
the fo:declarations element points to the appropriate node in the
element and attribute tree.
The second phase in formatting is to refine the formatting
object tree
to produce the
refined formatting object tree
The refinement process handles the mapping from properties
to traits. This consists of: (1) shorthand expansion into
individual properties, (2) mapping of corresponding
properties, (3) determining computed values (may include
expression evaluation),
(4) handling white-space-treatment and linefeed-treatment
property effects, and (5) inheritance.
Details on
refinement are found in
5 Property Refinement / Resolution
The refinement step is depicted in the diagram below.
[D]
Refine the Formatting Object Tree
The third step in formatting is the construction of the area
tree. The
area tree is generated as described in the semantics of each
formatting object. The traits applicable to each formatting
object
class control how the areas are generated. Although every
formatting property may be specified on every formatting object, for
each formatting object class, only a subset of the formatting
properties are used to determine the traits for objects of
that class.
Area generation is depicted in the diagram below.
[D]
Generate the Area Tree
[D]
Summary of the Process
1.2 Benefits of XSL
Unlike the case of HTML, element names in XML have no intrinsic
presentation semantics. Absent a stylesheet, a processor could not
possibly know how to render the content of an XML document other
than as an undifferentiated string of characters. XSL provides
a comprehensive model and a vocabulary for writing such stylesheets using XML syntax.
This document is intended for implementors of such XSL processors.
Although it can be used as a reference manual for writers of XSL
stylesheets, it is not tutorial in nature.
XSL builds on the prior work on Cascading Style Sheets
[CSS2]
and
the Document Style Semantics and Specification Language
[DSSSL]
While many of XSL's formatting objects and properties correspond
to the common set of properties, this would not be
sufficient by
itself to accomplish all the goals of XSL. In particular, XSL introduces
a model for pagination and layout that extends what is currently available
and that can in turn be extended, in a straightforward way, to page
structures beyond the simple page models described in this specification.
1.2.1 Paging and Scrolling
Doing both scrollable document windows and pagination introduces
new complexities to the styling (and pagination) of XML content.
Because pagination introduces arbitrary boundaries
(pages or regions on pages) on the content, concepts such as
the control
of spacing at page, region, and block boundaries become
extremely important. There are also concepts related to
adjusting the spaces between lines (to adjust the page
vertically)
and between words and letters (to justify the lines of text).
These do not always arise with simple scrollable document
windows, such as those found in today's browsers. However, there
is a correspondence between a page with multiple regions, such as a body,
header, footer, and left and right sidebars, and a Web
presentation using "frames". The distribution of content into the regions
is basically the same in both cases, and XSL handles both
cases in an analogous fashion.
XSL was developed to give designers control over the features
needed when documents are paginated as well as to provide an
equivalent "frame" based structure for browsing on the Web.
To achieve this control, XSL has extended the set of formatting
objects and formatting properties beyond those available in
either CSS2 or DSSSL.
In addition, the selection
of XML source components that can be styled (elements,
attributes, text nodes, comments, and processing
instructions) is based on XSLT and
XPath
[XPath]
thus providing the
user with an extremely powerful selection mechanism.
The design of the formatting objects and properties extensions
was first inspired by DSSSL. The actual extensions, however, do not
always look like the DSSSL constructs on which they were based. To either
conform more closely with the CSS2 specification or to
handle cases more simply than in DSSSL, some extensions have diverged from DSSSL.
There are several ways in which extensions were made. In some cases,
it sufficed to add new values, as in the case of those added to reflect
a variety of writing-modes, such as top-to-bottom and bottom-to-top, rather
than just left-to-right and right-to-left.
In other cases, common properties that are expressed in CSS2
as one property with multiple simultaneous values, were split into
several new properties to provide independent control over independent
aspects of the property. For example, the "white-space" property was
split into four properties:
a "white-space-treatment" property that
controls how white space is processed, a "linefeed-treatment" property that controls
how line feeds are processed,
a "white-space-collapse" property that controls
how multiple consecutive spaces are collapsed,
and a "wrap-option" property
that controls whether lines are automatically wrapped when
they encounter a boundary, such as the edge of a column.
The effect of splitting a property into two or more
(sub-)properties is to make the equivalent existing CSS2
property a "shorthand" for the set of sub-properties it subsumes.
In still other cases, it was necessary to create new properties.
For example, there are a number of new properties that control how
hyphenation is done. These include identifying the script and country
the text is from as well as such properties as "hyphenation-character"
(which varies from script to script).
Some of the formatting objects and many of the properties in XSL
come from the CSS2 specification, ensuring compatibility
between the two.
There are four classes of XSL properties that can be identified as:
CSS properties by copy (unchanged from their CSS2
semantics)
CSS properties with extended values
CSS properties broken apart and/or extended
XSL-only properties
1.2.2 Selectors and Tree Construction
As mentioned above, XSL uses XSLT and XPath for tree construction
and pattern selection, thus providing a high degree of control
over how portions of the source content are presented, and what
properties are associated with those content portions, even where
mixed namespaces are involved.
For example, the patterns of XPath allow the selection of a portion
of a string or the Nth text node in a paragraph. This allows
users to have a rule that makes all third paragraphs in
procedural steps appear in bold, for instance. In addition,
properties can be associated with a content portion based on the
numeric value of that content portion or attributes on the
containing element. This allows one to have a style rule
that makes negative values appear in "red" and positive
values appear in "black". Also, text can be generated
depending on a particular context in the source tree,
or portions of the source tree may be presented
multiple times with different styles.
1.2.3 An Extended Page Layout Model
There is a set of formatting objects in XSL to describe both the
layout structure of a page or "frame"
(how big is the body; are there multiple columns;
are there headers, footers, or sidebars; how big are these)
and the rules by which the XML source content is placed into these "containers".
The layout structure is defined in terms of one or more instances
of a "simple-page-master" formatting object. This formatting
object allows one to define independently filled regions for
the body (with multiple columns), a header, a footer, and sidebars
on a page. These simple-page-masters can be used in page sequences
that specify in which order the various simple-page-masters shall be used.
The page sequence also specifies how styled content is to fill those pages.
This model allows one to specify a sequence of simple-page-masters
for a book chapter where the page instances are automatically
generated by the formatter or an explicit sequence of pages
such as used in a magazine layout. Styled content is assigned
to the various regions on a page by associating the name of the
region with names attached to styled content in the result tree.
In addition to these layout formatting objects and properties,
there are properties designed to provide the level of control
over formatting that is typical of paginated documents.
This includes control over hyphenation, and expanding the control over
text that is kept with other text in the same line, column,
or on the same page.
1.2.4 A Comprehensive Area Model
The extension of the properties and formatting objects,
particularly in the area on control over the spacing of blocks, lines,
and page regions and within lines, necessitated an extension of the
CSS2 box formatting model. This extended model is described
in
4 Area Model
of this
specification. The CSS2 box model is a
subset of this model. See the mapping of the CSS2 box model
terminology to the XSL Area Model terminology in
7.2 XSL Areas and the CSS Box Model
The area model provides a vocabulary for describing
the relationships and space-adjustment between
letters, words, lines, and blocks.
1.2.5 Internationalization and Writing-Modes
There are some scripts, in particular in the Far East, that are
typically set with words proceeding from top-to-bottom and
lines proceeding either from right-to-left (most common) or
from left-to-right. Other directions are also
used. Properties expressed in terms of a fixed,
absolute frame of reference (using top, bottom, left, and right)
and which apply only to a notion of words proceeding from left to right
or right to left do not generalize well to
text written in those scripts.
For this reason XSL (and before it DSSSL) uses a relative frame of
reference for the formatting object and property descriptions. Just as
the CSS2 frame of reference has four directions (top, bottom, left and right),
so does the XSL relative frame of reference have four directions
(before, after, start, and end), but these are relative to the "writing-mode". The
"writing-mode" property is a way of controlling the
directions needed by a formatter to correctly place
glyphs, words, lines, blocks, etc. on the page or screen.
The "writing-mode" expresses the basic directions noted
above. There are writing-modes for "left-to-right - top-to-bottom"
(denoted as "lr-tb"), "right-to-left - top-to-bottom" (denoted as "rl-tb"),
"top-to-bottom - right-to-left" (denoted as "tb-rl") and more. See
7.29.7 writing-mode
for the description of the "writing-mode" property.
Typically, the writing-mode value specifies two directions:
the first is the inline-progression-direction which determines
the direction in which words will
be placed and the second is the block-progression-direction
which determines the direction in which blocks (and lines)
are placed one after another.
In addition, the inline-progression-direction
for a sequence of characters may be implicitly determined using
bidirectional character types for those characters from the
Unicode Character Database
[UNICODE Character Database]
for those characters and the Unicode bidirectional (BIDI) algorithm
[UNICODE UAX #9]
Besides the directions that are explicit in the name of the
value of the "writing-mode" property, the writing-mode determines
other directions needed by the formatter, such as the
shift-direction (used for subscripts and superscripts), etc.
1.2.6 Linking
Because XML, unlike HTML, has no built-in semantics,
there is no built-in notion of a hypertext link.
In this context, "link" refers
to "hypertext link" as defined in
as well as some of the aspects of "link" as defined in
where "link is a relationship between two or more resources or
portions of resources, made explicit by an XLink linking element".
Therefore,
XSL has a formatting object that expresses the dual semantics of
formatting the content of the link reference and the
semantics of following the link.
XSL provides a few mechanisms for changing the presentation
of a link target that is being visited. One of these mechanisms
permits indicating the link target as such;
another allows for control over the placement of the link
target in the viewing area; still another permits some degree of
control over the way the link target is displayed in relationship
to the originating link anchor.
XSL also provides a general mechanism for changing the way elements
are formatted depending on their active state. This is particularly
useful in relation to links, to indicate whether a given link
reference has already been visited, or to apply a given style
depending on whether the mouse, for instance, is hovering over
the link reference or not.
2 XSL Transformation
2.1 Tree Construction
The Tree Construction is described in
"XSL Transformations"
[XSLT]
The data model in XSLT is capable of representing either an
XML 1.0 document
(conforming to
[XML]
and
[XML Names]
or an XML 1.1 document
(conforming to
[XML 1.1]
and
[XML Names 1.1]
),
and it makes no distinction between the two.
In principle, therefore, XSL 1.1 can be used with either of these XML versions;
the only differences arise outside the boundary of the transformation proper,
while creating the data model from textual XML (parsing).
The provisions in "XSL Transformations" form an integral part of
this Recommendation and are considered normative.
Because the data model is the same whether the original document was
XML 1.0 or XML 1.1, the semantics of XSLT processing
do not depend on the version of XML used by the original document.
There is no reason in principle why all the documents
used in a single transformation must conform to the same version of XML.
2.2 XSL Namespace
The XSL namespace has the URI
Note:
The
1999
in the URI indicates the year in which
the URI was allocated by the W3C. It does not indicate the version of
XSL being used.
XSL processors must use the XML namespaces mechanism
[XML Names]
or
[XML Names 1.1]
to recognize elements and attributes from this
namespace. Elements from the XSL namespace are recognized only in the
stylesheet, not in the source document.
Implementors must not extend the XSL
namespace with additional elements or attributes. Instead, any
extension must be in a separate namespace.
The expanded-name of extension elements must have a
non-null namespace URI.
This specification uses the prefix
fo:
for referring
to elements in the XSL namespace. However, XSL stylesheets are free
to use any prefix, provided that there is a namespace declaration that
binds the prefix to the URI of the XSL namespace.
An element from the XSL namespace may have any attribute not from
the XSL namespace, provided that the
expanded-name
of the
attribute has a non-null namespace URI. The presence of such
attributes must not change the behavior of XSL elements and functions
defined in this document.
This means that an extension attribute may change the processing of
an FO, but only provided that the constraints specified by XSL on
that FO remain satisfied.
Thus, an XSL processor is always free to
ignore such attributes, and must ignore such attributes without giving
an error if it does not recognize the namespace URI. Such attributes
can provide, for example, unique identifiers, optimization hints, or
documentation.
It is an error for an element from the XSL namespace to have
attributes with expanded-names that have null namespace URIs
(i.e., attributes with unprefixed names) other than
attributes defined in this document.
Note:
The conventions used for the names of XSL elements,
attributes, and functions are as follows:
names are all lowercase,
hyphens are used to separate words, dots are used to
separate names for the components of complex datatypes,
and abbreviations are used only if they already
appear in the syntax of a related language such as XML or
HTML.
3 Introduction to Formatting
The aim of this section is to describe the general process
of formatting, enough to read the area model and the
formatting object descriptions and properties and to
understand the process of refinement.
Formatting
is the process of turning the result of an XSL
transformation into a tangible form for the reader or listener. This
process comprises several steps, some of which depend on others in a
non-sequential way.
Our model for formatting will be the construction of an
area tree
, which is an ordered tree containing
geometric information
for the placement of every glyph, shape, and image in the document,
together with information embodying spacing constraints and other rendering
information; this information is referred to under the rubric of
traits
, which are to areas what properties are to formatting objects
and attributes are to XML elements.
4 Area Model
will
describe the area tree and
define the default placement constraints on stacked areas. However, this is
an abstract model which need not be actually implemented in this way
in a formatter, so long as the resulting tangible form obeys the implied constraints.
Constraints might conflict to the point where it is
impossible to satisfy them all. In that case, it is
implementation-defined which constraints should be relaxed
and in what order to satisfy the others.
Formatting objects
are elements in the formatting object tree, whose
names are from the XSL namespace; a formatting object belongs to a
class
of formatting objects identified by its element name. The
formatting behavior of each class of formatting objects is described in
terms of what areas are created by a formatting object of that class, how
the traits of the areas are established, and how the areas are
structured hierarchically with respect to areas created by other formatting
objects.
6 Formatting Objects
and
7 Formatting Properties
describe formatting objects and their properties.
Some formatting objects are
block-level
and others are
inline-level
. This refers to the types of areas which they generate,
which in turn refer to their default placement method. Inline-areas (for
example, glyph-areas) are collected into lines and the direction in which
they are stacked is the inline-progression-direction. Lines are a type of
block-area and these are stacked in a direction perpendicular to the
inline-progression-direction, called the block-progression-direction. See
4 Area Model
for detailed decriptions
of these area types and directions.
In Western writing systems, the block-progression-direction is
"top-to-bottom" and the inline-progression-direction is
"left-to-right". This specification treats other writing systems
as well and introduces the terms "block" and "inline"
instead of using absolute indicators like "vertical" and
"horizontal". Similarly this specification tries to give
relatively-specified directions ("before" and "after"
in the block-progression-direction, "start" and "end"
in the inline-progression-direction) where appropriate, either in addition
to or in place of absolutely-specified directions such as "top",
"bottom", "left", and "right". These are
interpreted according to the value of the writing-mode property.
Central to this model of formatting is
refinement
This is a computational
process which finalizes the specification of properties based on the attribute
values in the XML result tree. Though the XML result tree and the formatting object
tree have very similar structure, it is helpful to think of them as
separate conceptual entities. Refinement involves
propagating the various inherited values
of properties (both implicitly and those with an attribute value of "inherit"),
evaluating expressions in property value specifications into actual
values, which
are then used to determine the value of the properties,
converting relative numerics to absolute numerics,
constructing some composite properties from more than one attribute
Some of these operations (particularly evaluating expressions) depend on knowledge
of the area tree. Thus refinement is not necessarily a straightforward, sequential
procedure, but may involve look-ahead, back-tracking, or control-splicing with
other processes in the formatter. Refinement is described more fully in
5 Property Refinement / Resolution
To summarize, formatting proceeds by constructing an area tree
(containing areas and their traits) which satisfies constraints based on
information contained in the XML result tree (containing
element nodes and their
attributes). Conceptually, there are intermediate steps of
constructing a formatting object tree (containing formatting objects and their
properties) and refinement;
these steps may proceed in an interleaved fashion during the
construction of the area tree.
3.1 Conceptual Procedure
This subsection contains a conceptual description of how
formatting could work. This conceptual
procedure does not mandate any particular algorithms or data structures as
long as the result obeys the implied constraints.
The procedure works by processing formatting objects. Each object,
while being processed, may initiate processing of other objects. While the
objects are hierarchically structured, the processing is not; processing of
a given object is rather like a co-routine which may pass control to other
processes, but pick up again later where it left off. The procedure starts
by initiating the processing of the fo:root
formatting object.
Unless otherwise specified, processing a formatting object creates areas
and returns
them to its parent to be placed in the area tree. Like a co-routine, when
given control, it initiates, then continues
formatting of its own children (if
any), or some subset of them. The formatting object supplies parameters to its
children
based on the traits of areas already in the area tree, possibly including
areas generated by the formatting object or its ancestors. It then disposes of the
areas
returned by its formatting object children. It might simply
return such an area to its
parent (and will always do this if it does not generate areas itself), or
alternatively it might arrange the area in the area tree according to the
semantics of the formatting object; this may involve changing its geometric position.
It
terminates processing when all its children have terminated processing (if
initiated) and it is finished generating areas.
Some formatting objects do not themselves generate areas; instead these
formatting objects simply
return the areas returned to them by their children. Alternatively, a formatting object
may continue to generate (and return) areas based on information discovered
while formatting its own children; for example, the fo:page-sequence formatting object
will continue generating pages as long as it contains a flow with
unprocessed descendants.
Areas returned to an fo:root formatting object are
page-viewport-areas, and are simply placed as
children of the area tree root in the order in which they are returned,
with no geometrical implications.
As a general rule, the order of the area tree parallels the order of the
formatting object tree. That is, if one formatting object
precedes another in the depth-first
traversal of the formatting object tree, with neither
containing the other, then
all the areas generated by the first will precede all the areas generated
by the second in the depth-first traversal of the area tree, unless
otherwise specified. Typical exceptions to this rule would be things like
side floats, before floats, and footnotes.
At the end of the procedure, the areas and their traits have been
constructed, and they are required to satisfy constraints described in the
definitions of their associated formatting objects, and in the area model
section. In particular, size and position of the areas will be subject to
the placement and spacing constraints described in the area model, unless
the formatting object definition indicates otherwise.
The formatting object definitions, property descriptions, and area model
are not algorithms. Thus, the formatting object semantics do not specify how
the line-breaking algorithm must work in collecting characters into words,
positioning words within lines, shifting lines within a container, etc.
Rather this specification assumes that the formatter has done these things
and describes the constraints which the result is supposed to
satisfy.
Thus, the constraints do not specify at what time an implementation
makes use of that information; the constraints only specify what must
be true after processing has been completed.
An actual implementation may well make use of some constraints at a
time other than when formatting the formatting object for which the
constraint applies. For example, the constraint given by the
"hyphenate" property on an fo:character would typically be used during
line-building, rather than when progessing the fo:character.
Other examples include constraints for keeps and breaks.
4 Area Model
In XSL, one creates a tree of formatting objects that serve as inputs or
specifications to a formatter. The formatter generates a hierarchical arrangement
of areas which comprise the formatted result. This section defines the general
model of these areas and how they interact. The purpose is to present an abstract
framework which is used in describing the semantics of formatting objects.
It should be seen as describing a series of constraints for
conforming implementations,
and not as prescribing particular algorithms.
4.1 Introduction
The formatter generates an ordered tree, the
area tree,
which
describes a geometric structuring of the output medium. The terms
child, sibling, parent, descendant,
and
ancestor
refer to this tree structure. The tree has a
root node
Each area tree node other than the root is called an
area
and is
associated to a rectangular portion of the output medium. Areas are
not formatting objects; rather, a formatting object generates zero or more
rectangular areas, and normally each area is generated by a unique object in the
formatting object tree.
Note:
The only exceptions to this rule are when several leaf nodes of the formatting object
tree are combined
to generate a single area, for example when several characters
in sequence generate a single ligature
glyph. In all such cases, relevant properties such as
font-family
and
font-size
must be the same for
all the generating formatting objects (see section
4.7.2 Line-building
).
An area has a
content-rectangle
the portion in which its child areas are assigned, and optional
padding
and
border
. The diagram shows
how these portions are related to one another. The outer bound of the border
is called the
border-rectangle
, and the outer
bound of the
padding is called the
padding-rectangle
[D]
Each area has a set of
traits
, a mapping of names to values,
in the way elements have attributes and formatting objects have properties.
Individual traits are used either
for rendering the area or for defining constraints on the result of formatting,
or both. Traits used strictly for formatting purposes or for defining
constraints may be called
formatting traits
, and traits used for
rendering may be called
rendering traits
Traits whose values are copied or derived from a property
of the same or a corresponding
name are listed in
B Property Summary
and
5 Property Refinement / Resolution
other traits are listed below.
Note:
Traits are also associated with FOs during the process of refinement.
Some traits are assigned during formatting, while others are already present after
refinement.
The semantics of each type of formatting object that generates areas are
given in terms of which areas it generates and their place in the area-tree
hierarchy. This may be further modified by interactions between the various
types of formatting
objects. The properties of the formatting object determine what areas are
generated and how the formatting object's content is distributed among them.
(For example, a word that is not to be hyphenated may not have its glyphs
distributed into areas on two separate line-areas.)
The traits of an area are either:
directly-derived
: the values of directly-derived traits are the computed
value of a property of the same or a corresponding name on the generating formatting object, or
indirectly-derived
: the values of indirectly-derived traits are the
result of a computation involving the computed values of one or more properties
on the generating formatting object, other traits on this area or other
interacting areas (ancestors, parent, siblings, and/or children) and/or
one or more values constructed by the formatter. The calculation formula
may depend on the type of the formatting object.
This description assumes that refined values have been computed for all
properties of formatting objects in the result tree, i.e.,
all relative and corresponding values have been computed and the inheritable
values have been propagated as described in
5 Property Refinement / Resolution
. This
allows the
process of inheritance to be described once and avoids a need to repeat
information on computing values
in this description.
The indirectly-derived traits are:
block-progression-direction
inline-progression-direction
shift-direction
glyph-orientation
is-reference-area
is-viewport-area
left-position
right-position
top-position
bottom-position
left-offset
top-offset
is-first
is-last
alignment-point
area-class
start-intrusion-adjustment
end-intrusion-adjustment
generated-by
returned-by
folio-number
blink
underline-score
overline-score
through-score
underline-score-color
overline-score-color
through-score-color
alignment-baseline
baseline-shift
nominal-font
dominant-baseline-identifier
actual-baseline-table
, and
script
4.2 Rectangular Areas
4.2.1 Area Types
There are two types of areas:
block-areas
and
inline-areas
. These differ according to how
they are typically stacked by the formatter. An area can have
block-area children or inline-area children as determined
by the generating formatting object, but a given area's children must all be of
one type. Although block-areas and inline-areas are
typically stacked, some areas can be explicitly positioned.
line-area
is a special kind of block-area whose children
are all inline-areas. A
glyph-area
is a special kind of
inline-area which has no child areas, and has a single
glyph image as its content.
Typical examples of areas are: a paragraph rendered by using
an fo:block formatting object,
which generates block-areas,
and a character rendered by using an fo:character
formatting object,
which generates an inline-area (in fact, a glyph-area).
4.2.2 Common Traits
Associated with any area are two directions, which are derived from the
generating
formatting object's
writing-mode
and
reference-orientation
properties: the
block-progression-direction
is the direction for stacking block-area
descendants of the area, and the
inline-progression-direction
is the direction for stacking inline-area
descendants of the area. Another
trait, the
shift-direction
, is present on inline-areas and refers to
the direction in which baseline
shifts are applied. Also the
glyph-orientation
defines the orientation
of glyph-images in the rendered result.
If the reference-orientation for an area is 0, then the
top, bottom, left, and right edges of the content are parallel to those of
the area's parent and consistent with them. Otherwise the edges are rotated
from those of the area's parent as described in
7.21.3 reference-orientation
The inline-progression-direction and block-progression-direction are determined
by the location of these edges as described in
7.29.7 writing-mode
The Boolean trait
is-reference-area
determines
whether or not an area establishes a coordinate system for
specifying indents. An area for which this trait is
true
is called a
reference-area
Only a reference-area may have a block-progression-direction which is different from
that of its parent.
A reference-area may be either a
block-area or an inline-area.
Only specific formatting objects generate reference areas.
The Boolean trait
is-viewport-area
determines
whether or not an area establishes an opening through which its
descendant areas can be viewed, and can be used to
present clipped or scrolled material; for example, in printing
applications where bleed and trim is desired.
An area for which this trait is
true
is called a
viewport-area
A viewport-area also has the value
true
for the
is-reference-area
trait.
A common construct is a
viewport/reference pair
This is a
viewport-area
and a block-area
reference-area
, where
is the sole child
of
and where the start-edge and end-edge of the
content-rectangle of
are parallel to the start-edge and
end-edge of the content-rectangle of
Each area has the traits
top-position
bottom-position
left-position
, and
right-position
which represent the distance
from the edges of its content-rectangle to the like-named edges of the
nearest ancestor reference-area (or the page-viewport-area
in the
case of areas generated by descendants of formatting objects
whose absolute-position is
fixed
); the
left-offset
and
top-offset
determine the amount by which
a relatively-positioned area is shifted for rendering. These traits receive
their values during the formatting process, or in the case
of absolutely positioned areas, during refinement.
The
block-progression-dimension
and
inline-progression-dimension
of an area represent the
extent of the content-rectangle of that area in each of the two
relative directions.
Other traits include:
the
is-first
and
is-last
traits, which are Boolean traits
indicating the order in which areas are generated and returned
(See
6.1.1 Definitions Common to Many Formatting Objects
by a given
formatting object.
is-first
is
true
for the first area (or only area) generated and returned by a formatting object,
and
is-last
is
true
for the last area (or only area);
the amount of space outside the border-rectangle:
space-before
space-after
space-start
, and
space-end
(though some of these may be required to be zero on certain classes of area);
Note:
"Before", "after", "start",
and "end" refer to relative directions and are defined
below.
the thickness of each of the four sides of the padding:
padding-before
padding-after
padding-start
, and
padding-end
the style, thickness, and color of each of the
four sides of the border:
border-before
, etc.;
the background rendering of the
area:
background-color
background-image
, and
other background traits; and
the
nominal-font
for an area, as
determined by the font properties and the character descendants of the
area's generating formatting object.
(see
5.5.7 Font Properties
Unless otherwise specified, the traits of a
formatting object are present on each of its generated areas,
and with the same value. (However, see sections
4.7.2 Line-building
and
4.9.4 Border, Padding, and Background
.)
The
id
trait is computed for formatting objects but
is not present on areas.
4.2.3 Geometric Definitions
As described above, the
content-rectangle
is the rectangle
bounding the inside of the padding and is used to describe
the constraints on the positions of descendant areas. It is possible that
marks from descendant glyphs or other areas may appear outside the
content-rectangle.
Related to this is the
allocation-rectangle
of an area,
which is used to describe the constraints on the position of
the area within its parent area. For an inline-area this is either the
normal-allocation-rectangle
or the
large-allocation-rectangle
The
normal-allocation-rectangle
extends
to the content-rectangle
in the block-progression-direction and to the border-rectangle in the
inline-progression-direction. The
large-allocation-rectangle
is the border-rectangle. Unless
otherwise specified, the allocation-rectangle for an area is the
normal-allocation-rectangle.
[D]
Normal-allocation-rectangle of an inline-area
[D]
Large-allocation-rectangle of an inline-area
For a block-area, the allocation-rectangle extends to the border-rectangle in
the block-progression-direction and outside the content-rectangle
in the inline-progression-direction by an amount equal to
the
end-indent
and in the opposite direction by an amount equal to the
start-indent
Note:
The inclusion of space outside the border-rectangle of a block-area
in the inline-progression-direction does not affect
placement constraints, and
is intended to promote compatibility with the CSS box model.
[D]
Allocation- and content-rectangles of a block-area
The edges of a rectangle are designated as follows:
the
before-edge
is the edge occurring first in the
block-progression-direction and perpendicular
to it;
the
after-edge
is the edge opposite
the before-edge;
the
start-edge
is the edge occurring
first in the inline-progression-direction and perpendicular
to it,
the
end-edge
is the edge opposite the
start-edge.
For purposes of this definition, the content-rectangle of an area uses the
inline-progression-direction and block-progression-direction of that area;
but the border-rectangle, padding-rectangle, and
allocation-rectangle use the
directions of its parent area. Thus the edges designated for the
content-rectangle may not correspond to the same-named edges
on the padding-, border-,
and allocation-rectangles. This is important in the case of
nested areas with different writing-modes or reference-orientation.
The following diagram shows the correspondence between the various edge
names for a mixed writing-mode example:
[D]
Each inline-area has an
alignment-point
determined by the formatter,
on the start-edge
of its allocation-rectangle; for a glyph-area, this is
a point on the start-edge of the glyph on its alignment baseline (see below).
This is script-dependent and does not necessarily correspond to the
(0,0) coordinate point used for the data describing the glyph shape.
4.2.4 Tree Ordering
In the area tree, the set of areas with a given parent is ordered.
The terms
initial, final, preceding
, and
following
refer to this ordering.
In any ordered tree, this sibling order extends to an ordering of the entire tree
in at least two ways.
In the
pre-order traversal order
of a tree, the children
of each node (their order unchanged relative to one another) follow the node, but
precede any following siblings of the node or of its ancestors.
In the
post-order traversal order
of a tree, the children of
each node precede the node, but follow any preceding siblings of the node or of its
ancestors.
"Preceding" and "following", when applied to non-siblings, will depend on the
extension order used, which must be specified. However, in either of these given orders,
the leaves of the tree (nodes without children) are unambiguously ordered.
4.2.5 Stacking Constraints
This section defines the notion of
block-stacking constraints
and
inline-stacking constraints
involving areas. These are defined as
ordered relations, i.e., if
and
have a stacking constraint
it does not necessarily mean that
and
have a stacking
constraint. These definitions are recursive in nature and some cases may depend
upon simpler cases of the same definition. This is not circularity but rather a
consequence of recursion. The intention of the
definitions is to identify areas at any level of the
tree which may have only space between them.
The
area-class
trait is an enumerated value which is
xsl-normal
for an area which is stacked with
other areas in sequence. A
normal
area is an
area for which this trait is
xsl-normal
. A
page-level-out-of-line
area is an area with area-class
xsl-footnote
xsl-before-float
or
xsl-fixed
; placement of these areas is controlled
by the fo:page-sequence
ancestor of its generating formatting object. A
reference-level-out-of-line
area is an area with area-class
xsl-side-float
or
xsl-absolute
placement of these areas is controlled by the formatting object generating
the relevant reference-area. An
anchor
area is an area with area-class
xsl-anchor
placement of these areas is arbitrary and does not affect stacking.
Areas with area-class equal to one of
xsl-normal
xsl-footnote
, or
xsl-before-float
are defined to be
stackable
indicating that they are supposed to be properly stacked.
Block-stacking constraints
If
is a block-area, then there is a
fence preceding
if
is a reference-area or if the
border-before-width
or padding-before-width of
are non-zero.
Similarly, there is a
fence following
if
is a
reference-area
or if the border-after-width or padding-after-width of
are non-zero.
If
and
are stackable areas, and
is
a sequence of space-specifiers (see
4.3 Spaces and Conditionality
),
it is defined that
and
have block-stacking constraint
if
any of the following conditions holds:
is a block-area which is the first normal
child of
, and
is the sequence consisting of the
space-before of
is a block-area which is the last normal
child of
, and
is the sequence consisting of the
space-after of
and
are both block-areas, and either
a.
is the next stackable sibling area of
and
is the sequence consisting of the space-after of
and the space-before of
b.
is the first normal child of a block-area
is not a line-area,
there is no fence preceding
and
have a block-stacking constraint
', and
consists of
' followed by the space-before of
; or
c.
is the last normal child of a block-area
is not a line-area,
there is no fence following
and
have a block-stacking constraint
'', and
consists of the space-after of
followed by
''.
d.
has a block-stacking constraint
S'
with a
block-area
has a block-stacking constraint
S''
with
is
empty
(i.e., it has zero border,
padding, and block-progression-dimension, and no normal children), and
consists of
S'
followed by
S''
Note:
The use of "stackable" in two places in the above definition allows
block-stacking constraints to apply between areas of area-class
xsl-before-float
or
xsl-footnote
[D]
Adjacent Edges with Block-stacking
When
and
have a block-stacking constraint, the
adjacent edges
of
and
are an ordered
pair recursively defined as:
In case 1, the before-edge of the
content-rectangle of
and the before-edge of the allocation-rectangle of
In case 2, the after-edge of the allocation-rectangle
of
and
the after-edge of the content-rectangle of
In case 3a, the after-edge of the
allocation-rectangle of
and the before-edge of the allocation-rectangle of
In case 3b, the first of the adjacent edges of
and
and the before-edge of the allocation-rectangle of
In case 3c, the after-edge of the
allocation-rectangle of
and the second of the adjacent edges of
and
In

case 3d, the first of the adjacent edges of
and
and the second of the adjacent edges of
and
Example
. In this diagram each node represents a block-area.

Assume that all padding
and border widths are zero, and none of the areas are
reference-areas. Then
and
have a block-stacking constraint, as do
and
and
and
and
and
and
and
, and
and
; these

are the only pairs in the diagram having block-stacking constraints. If
had non-zero padding-after, then
and
would not have any block-stacking constraint (though
and
would continue to have a block-stacking constraint).
[D]
Block-stacking constraint example
Inline-stacking constraints.
This section will recursively define the
inline-stacking constraints between two areas (either two inline-areas or one inline-area
and one line-area),
together with the notion of
fence preceding
and
fence following
; these definitions are interwoven with one another.
This parallels the definition for block-stacking
constraints, but with the additional complication that we may have a stacking
constraint between inline-areas which are stacked in opposite inline-progression-directions.
(This is not an issue for block-stacking constraints because
a block-area which is not a reference-area may not have a
block-progression-direction
different from that of its parent.)
If
and
have an inline-stacking constraint, then
has a
fence preceding
if
is
a reference-area or has non-zero border-width or padding-width at the first
adjacent edge of
and
. Similarly,
has
fence following
if
is a reference-area
or has non-zero border-width or padding-width at the second
adjacent edge of
and
If
and
are normal areas, and
is a sequence of space-specifiers, it is defined that
and
have inline-stacking constraint
if any of the
following conditions holds:
is an inline-area or line-area,
is an inline-area which is the first normal child of
, and
is the sequence consisting of the space-start of
is an inline-area or line-area,
is an inline-area which is the last normal child of
, and
is the sequence consisting of the space-end of
and
are each either an inline-area or a line-area, and either
a. both
and
are inline-areas,
is the next normal sibling area of
and
is the sequence consisting of the space-end of
and the space-start of
b.
is an inline-area which is the first normal child of an inline-area
has no fence following
and
have an
inline-stacking constraint
', the inline-progression-direction of
is the same as the inline-progression-direction of the nearest
common ancestor area of
and
, and
consists of
' followed by the space-start of
c.
is an inline-area which is the last normal child of an inline-area
has no fence preceding
and
have an
inline-stacking constraint
'', the inline-progression-direction of
is the same as the inline-progression-direction of the nearest
common ancestor area of
and
, and
consists of the
space-end of
followed by
''.
d.
is an inline-area which is the last normal child of an inline-area
has no fence following
and
have an
inline-stacking constraint
', the inline-progression-direction of
is opposite to the inline-progression-direction of the nearest
common ancestor area of
and
, and
consists of
' followed by the space-end of
e.
is an inline-area which is the first normal child of an inline-area
has no fence preceding
and
have an
inline-stacking constraint
'', the inline-progression-direction of
is opposite to the inline-progression-direction of the nearest
common ancestor area of
and
, and
consists of the
space-start of
followed by
''.
[D]
Adjacent Edges with Inline-stacking
[D]
Adjacent Edges with Inline-stacking, continued
[D]
Mixed English and Arabic
[D]
Mixed English and Arabic
When
and
have an inline-stacking constraint,
the
adjacent edges
of
and
are an ordered
pair defined as:
In case 1, the start-edge of the
content-rectangle of
and the start-edge of the allocation-rectangle of
In case 2, the end-edge of the allocation-rectangle of
and
the end-edge of the content-rectangle of
In case 3a, the end-edge of the
allocation-rectangle of
and
the start-edge of the allocation-rectangle of
In case 3b, the first of the adjacent edges of
and
, and the start-edge of the allocation-rectangle of
In case 3c, the end-edge of the
allocation-rectangle of
and the second of the adjacent edges of
and
In case 3d, the first of the adjacent edges of
and
, and the end-edge of the allocation-rectangle of
In case 3e, the start-edge of the
allocation-rectangle of
and the second of the adjacent edges of
and
Two areas are
adjacent
if they have a block-stacking constraint
or an inline-stacking constraint. It follows from the definitions that areas of the same
type (inline or block) can be adjacent only if all their non-common ancestors
are also of the same type (up to but not including their nearest common ancestor).
Thus, for example, two inline-areas which reside in different line-areas are never
adjacent.
An area
begins
an area
if
is a
descendant of
and
and
have either a
block-stacking constraint or an inline-stacking constraint,
provided that no descendant of
which is an ancestor
of
has a space-before (in the case of a block-stacking constraint)
or a space-start (in the case of an inline-stacking constraint)
whose computed minimum, maximum, or optimum values
are nonzero.
In this case the
second of the adjacent edges of
and
is defined
to be
leading edge
in
. A space-specifier which
applies to
the leading edge is also defined to
begin
Similarly, An area
ends
an area
if
is a
descendant of
and
and
have either a
block-stacking constraint or an inline-stacking constraint,
provided that no descendant of
which is an ancestor
of
has a space-after (in the case of a block-stacking constraint)
or a space-end (in the case of an inline-stacking constraint)
whose computed minimum, maximum, or optimum values
are nonzero.
In this case the
first of the adjacent edges of
and
is defined
to be
trailing edge
in
. A space-specifier which
applies to
the trailing edge is also defined to
end
4.2.6 Font Baseline Tables
Each script has its preferred "baseline" for aligning glyphs from that script.
Western scripts typically use an "alphabetic" baseline that touches at or near the
bottom of capital letters. Further, for each font there is a
preferred way of aligning embedded glyphs from different scripts, e.g., for a
Western font there are separate baselines for aligning embedded ideographic or Indic
glyphs.
Each block-area and inline-area has a
dominant-baseline-identifier
trait whose value is a baseline identifier
corresponding to the type of alignment expected for inline-area descendants of that area,
and each inline-area has an
alignment-baseline
which specifies how the
area is aligned to its parent. These traits are interpreted as described in section
7.9.1 Fonts and Font Data
For each font, an
actual-baseline-table
maps these identifiers
to points on the start-edge of the area. By
abuse of terminology, the line in the inline-progression-direction
through the point corresponding to the dominant-baseline-identifier is called
the "dominant baseline."
4.3 Spaces and Conditionality
A space-specifier is a compound datatype whose components are minimum, optimum,
maximum, conditionality, and precedence.
Minimum
optimum
, and
maximum
are lengths
and can be used to define a constraint
on a distance, namely that the distance should preferably be the optimum,
and in any case no less than the minimum nor more than the maximum. Any of these
values may be negative, which can (for
example) cause areas to overlap, but in any case the minimum should be less
than or equal to the optimum value, and the optimum less than or equal to
the maximum value.
Conditionality
is an enumerated value which controls whether a
space-specifier has effect at the beginning or end of a reference-area or a
line-area. Possible values are
retain
and
discard
conditional
space-specifier is one for which this value is
discard
Precedence
has a value which is either an integer or the special
token
force
. A
forcing
space-specifier
is one for which this value is
force
Space-specifiers occurring in sequence may interact with each other. The
constraint imposed by a sequence of space-specifiers is computed by
calculating for each space-specifier
its associated
resolved space-specifier
in accordance with
their conditionality and precedence, as
shown below in the space-resolution rules.
The constraint imposed on a distance by a sequence of resolved space-specifiers
is additive; that is, the distance is constrained to be no less than the
sum of the resolved minimum values and no larger than the sum of the resolved
maximum values.
4.3.1 Space-resolution Rules
The
resolved space-specifier of a given space-specifier
is
computed as follows. Consider the maximal inline-stacking constraint or
block-stacking constraint
S''
containing the space-specifier
as an element of the sequence (
S''
is a sequence
of space-specifiers; see
4.2.5 Stacking Constraints
). Define
S'
to be a subsequence of
S''
as follows:
if
is the space-before or space-after of a line-area,
then
S'
is the maximal subsequence of
S''
containing
such that all the space-specifiers in
S'
are traits
of line-areas,
if
is the space-before or space-after of a block-area
which is not a line-area, then
S'
is the maximal subsequence
of
S''
containing
such that all the space-specifiers
in
S'
are traits of block-areas which are not
line-areas,
if
is the space-start or space-end of an inline-area,
then
S'
is all of
S''
The resolved space-specifier of
is a non-conditional,
forcing space-specifier computed in terms of the
sequence
S'
If any of the space-specifiers in
S'
is conditional,
and begins a reference-area or line-area, then it is
suppressed
which means that its resolved space-specifier is zero. Further, any conditional
space-specifiers which consecutively follow it in the sequence are also suppressed.
For purposes of this rule, a space-specifier
consecutively follows
a space-specifier
if it
follows
and
and
are separated in
the sequence only by conditional space-specifiers and/or
space-specifiers whose computed minimum, maximum, and optimum values are
zero.
If a conditional space-specifier ends a reference-area or line-area, then it
is suppressed together with any other conditional space-specifiers which
consecutively precede it in the sequence.
For purposes of this rule, a space-specifier
consecutively precedes
a space-specifier
if
it
precedes
and
and
are separated in
the sequence only by conditional space-specifiers and/or
space-specifiers whose computed minimum, maximum, and optimum values are
zero.
If any of the remaining space-specifiers in
S'
is forcing, all non-forcing
space-specifiers are suppressed, and the value of each of the forcing space-specifiers
is taken as its resolved value.
Alternatively if all of the remaining space-specifiers in
S'
are non-forcing,
then the resolved space-specifier is defined in terms of those non-suppressed space-specifiers
whose precedence is numerically highest, and among these those whose optimum value is the
greatest. All other space-specifiers are suppressed. If there is only one of
these then its value is taken as its resolved value.
Otherwise, follow these rules when there are
two or more
space-specifiers all of the same highest precedence and the same
(largest) optimum: The resolved space-specifier of the last
space-specifier in the sequence is derived from these spaces by
taking their common optimum value as its optimum. The greatest of
their minimum values is its minimum. The least of their maximum
values is its maximum. All other space-specifiers are suppressed.
If
is subject to overconstrainment relaxing,
then its maximum value is set to the actual block-progression-dimension of the
containing block-area. See
4.3.2 Overconstrained space-specifiers
Example
. Suppose the sequence of space values occurring at the
beginning of a reference-area is:
first, a space with value 10 points (that is
minimum, optimum, and maximum all equal to 10 points) and conditionality
discard
; second, a space with value 4 points and
conditionality
retain
; and third, a space
with value 5 points and conditionality
discard
all three spaces having precedence zero. Then the first (10 point) space is
suppressed under rule 1, and the
second (4 point) space is suppressed under rule 3. The resolved value of the
third space is a non-conditional 5 points, even though
it originally came from a conditional space.
The padding of a block-area does not interact with any
space-specifier
(except that by definition, the presence of padding at the before- or after-edge
prevents areas on either side of it from having a stacking constraint.)
The border or padding at the before-edge or after-edge of a block-area
may
be specified as conditional. If so, then it is set to zero if its associated
edge is a leading edge in a reference-area, and the is-first trait of
is false, or if its associated
edge is a trailing edge in a reference-area, and the is-last trait of
is false. In either of these cases, the border
or padding is taken to be zero for purposes of the stacking constraint definitions.
The border or padding at the start-edge or end-edge of an inline-area
may
be specified as conditional. If so, then it is set to zero if its associated
edge is a leading edge in a line-area, and the is-first trait of
is false, or if its associated
edge is a trailing edge in a line-area, and the is-last trait of
is false. In either of these cases, the border
or padding is taken to be zero for purposes of the stacking constraint definitions.
4.3.2 Overconstrained space-specifiers
When

an area
is generated by a formatting object whose
block-progression-dimension
is "auto", then the constraints involving the before-edge and after-edge of
the content-rectangle of
, together with the constraints between the
various descendants of
, result in a constraint on the actual value
of the block-progression-dimension. If the block-progression-dimension is instead
specified as a length, then this might result in an overconstrained area tree,
for example an incompletely-filled fo:block
with a specified size. In that case some constraints between
and its
descendants should be relaxed; those that are eligible for this treatment are
said to be
subject to overconstrainment relaxing
, and treated as in
the previous section.
If the display-align value is "after" or "center" and
is the first normal area generated
by the formatting object, then the space-before of the first normal child of
is subject to overconstrainment relaxing.
If the display-align value is "before" or "center" and
is the last normal area generated
by the formatting object, then the space-after of the last normal child of
is subject to overconstrainment relaxing.
4.4 Block-areas
Block-areas have several traits which typically affect the placement of their
children. The
line-height
is used in line placement calculations.
The
line-stacking-strategy
trait controls what kind of allocation
is used for descendant line-areas and has an enumerated value
(either
font-height
max-height
or
line-height
). This is all rigorously described below.
All areas have these traits,
but they only have relevance for areas which have stacked line-area children.
The
space-before
and
space-after
traits
determine the
distance between the block-area and surrounding block-areas.
A block-area which is not a line-area typically has its size in the
inline-progression-direction determined
by its
start-indent
and
end-indent
and by the size of its nearest ancestor
reference-area.

A block-area which is not a line-area must be properly stacked (as defined in
4.4.1 Stacked Block-areas
below)
unless otherwise specified in the description of its generating formatting object.
In this case its block-progression-dimension will be subject to constraints based
on the block-progression-dimensions and space-specifiers of its descendants.
See
4.3.2 Overconstrained space-specifiers
4.4.1 Stacked Block-areas
Block-area children of an area are typically stacked in the
block-progression-direction
within their parent area, and this is the default method of
positioning block-areas. However, formatting objects
are free to specify other methods of positioning child areas of areas which
they generate, for example list-items or tables.
For a parent area
whose children are
block-areas,
is defined to be
properly
stacked
if all of the following conditions hold:
For each block-area
which is a descendant of
the following hold:
the before-edge and after-edge
of its allocation-rectangle are parallel to the before-edge and after-edges of the
content-rectangle of
the start-edge of its allocation-rectangle is parallel to the start-edge
of the content-rectangle of
(where
is the closest
ancestor reference-area of
), and offset from it inward
by a distance equal to
the block-area's start-indent plus its
start-intrusion-adjustment
(as defined below), minus its border-start,
padding-start, and space-start values, and
the end-edge of its allocation-rectangle is parallel to the
end-edge
of the content-rectangle of
, and offset from it inward
by a distance equal to
the block-area's end-indent plus its
end-intrusion-adjustment
(as defined below),
minus its border-end, padding-end, and space-end
values.
[D]
Content Rectangle of Reference Area
Note:
The notion of indent is intended to apply to the content-rectangle, but
the constraint is written in terms of the
allocation-rectangle, because as noted earlier

4.2.3 Geometric Definitions
the edges of the
content-rectangle may not
correspond to like-named edges of the
allocation-rectangle.
The
start-intrusion-adjustment
and
end-intrusion-adjustment
are traits used to
deal with intrusions from
floats in the inline-progression-direction.
See also section
5.3.2 Margin, Space, and Indent Properties
for how the margin properties affect the indents.
For each pair of normal areas
and
in the subtree below
, if
and
' have a block-stacking constraint
and
is not empty (see
4.2.5 Stacking Constraints
),

then the distance between the adjacent edges of
and
is consistent with the
constraint imposed by the
resolved values of the space-specifiers in
[D]
Example
. In the diagram, if area
has a space-after value of 3 points,
space-before
of 1 point, and
a space-before of 2 points, all
with
precedence of
force
, and with zero border and padding,
then the constraints will place
's
allocation-rectangle
4 points below that of
, and
's
allocation-rectangle
6 points below that
of
. Thus the 4-point gap receives the
background color
from
, and the 2-point gap before
receives the background color from
4.4.2 Intrusion Adjustments
Intrusion adjustments (both start- and end-) are defined to account for the
indentation that occurs as the result of side floats.
If
and
are areas which have the same nearest reference area ancestor, then
and
are defined to be
inline-overlapping
if there is some line
parallel to the inline-progression-direction, which intersects both the
allocation-rectangle of
and the allocation-rectangle of
If
is an area of class
xsl-side-float
with float="
start
", and
is a block-area, and
and
have the same nearest reference area ancestor, then
is defined to
encroach
upon
if
and
are inline-overlapping and the start-indent of
is less than the sum of the start-indent of
and the inline-progression-dimension of
. The
start-encroachment
of
on
is then defined to
be amount by which the start-indent of
is less than the sum of the start-indent of
and
the inline-progression-dimension of
If
is an area of class
xsl-side-float
with float="
end
", and
is a block-area, and
and
have the same nearest reference area ancestor, then
is defined to
encroach
upon
if
and
are inline-overlapping and the end-indent of
is less than the sum of the end-indent of
and the inline-progression-dimension of
. The
end-encroachment
of
on
is then
defined to be amount by which the end-indent of
is less than the sum of the end-indent of
and
the inline-progression-dimension of
If
is a block-area which is not a line-area, then its
local-start-intrusion-adjustment
is computed as the maximum of
the following lengths:
zero;
if the parent of
is not a reference area: the start-intrusion-adjustment of the parent of
and
if
has intrusion-displace="
block
",
then for each area
of class
xsl-side-float
with float="
start
" such that the generating formatting object of
is not a descendant of
the generating formatting object of
, and such that
encroaches upon some line-area child of
: the start-encroachment of
on
and
if
has intrusion-displace = "
block
", then for each area
of class
xsl-side-float
with float="
start
such that
and
are inline-overlapping, and for each block-area ancestor
B'
of
which is
a descendant of the nearest reference area ancestor of
, such that
encroaches on a line-area
child of
B'
: the start-encroachment of
on
B'
The start-intrusion-adjustment of a block-area
is then defined to be
the maximum of the local-start-intrusion-adjustments of the normal block-areas generated
and returned by the generating formatting object of
If
is a line-area, then its start-intrusion-adjustment is computed as the maximum of
the following lengths:
the start-intrusion-adjustment of the parent of
for each area
of class
xsl-side-float
with float="
start
" such that
encroaches upon
the start-encroachment of
on
; and
if the parent of
has intrusion-displace = "
indent
",
then for each area
of class
xsl-side-float
with float="
start
" such that
and
are inline-overlapping, and for each block-area ancestor
B'
of
which is
a descendant of the nearest reference area ancestor of
, such that
encroaches on some line-area
child
L'
of
B'
: the start-encroachment of
on
B'
The end-intrusion-adjustment for a block-area is computed in a precisely analogous manner.
That is:
If
is a block-area which is not a line-area, then its
local-end-intrusion-adjustment
is computed as the maximum of
the following lengths:
zero;
if the parent of
is not a reference area: the end-intrusion-adjustment of the parent of
and
if
has intrusion-displace="
block
",
then for each area
of class
xsl-side-float
with float="
end
" such that the generating formatting object of
is not a descendant of
the generating formatting object of
, and such that
encroaches upon some line-area child of
: the end-encroachment of
on
and
if
has intrusion-displace = "
block
", then for each area
of class
xsl-side-float
with float="
end
such that
and
are inline-overlapping, and for each block-area ancestor
B'
of
which is
a descendant of the nearest reference area ancestor of
, such that
encroaches on a line-area
child of
B'
: the end-encroachment of
on
B'
The end-intrusion-adjustment of a block-area
is then defined to be
the maximum of the local-end-intrusion-adjustments of the normal block-areas generated
and returned by the generating formatting object of
If
is a line-area, then its end-intrusion-adjustment is computed as the maximum of
the following lengths:
the end-intrusion-adjustment of the parent of
for each area
of class
xsl-side-float
with float="
end
" such that
encroaches upon
the end-encroachment of
on
; and
if the parent of
has intrusion-displace = "
indent
",
then for each area
of class
xsl-side-float
with float="
end
" such that
and
are inline-overlapping, and for each block-area ancestor
B'
of
which is
a descendant of the nearest reference area ancestor of
, such that
encroaches on some line-area
child
L'
of
B'
: the end-encroachment of
on
B'
4.5 Line-areas
A line-area is a special type of block-area, and is generated by the same
formatting object which generated
its parent. Line-areas do not have borders and padding, i.e., border-before-width,
padding-before-width, etc. are all zero. Inline-areas are stacked within a line-area
relative to a
baseline-start-point
which is a point determined by the
formatter, on the start-edge of the line area's content-rectangle.
The allocation-rectangle of a line is determined by the value of the
line-stacking-strategy
trait: if the
value is
font-height
, the allocation-rectangle is
the
nominal-requested-line-rectangle
, defined below; if the value is
max-height
, the allocation-rectangle is the
maximum-line-rectangle
, defined below; and if
the value is
line-height
, the allocation-rectangle is the
per-inline-height-rectangle
, defined below.
If the
line-stacking-strategy
trait is
font-height
or
max-height
the
space-before
and
space-after
are both set to the half-leading value; otherwise they are both set to zero.
The
nominal-requested-line-rectangle
for a line-area is the rectangle
whose start-edge is parallel to the start-edge of the
content-rectangle of the nearest ancestor reference-area and offset from it by the sum
of the start-indent and the start-intrusion-adjustment of the line area,
whose end-edge is parallel to the end-edge of the
content-rectangle of the nearest ancestor reference-area and offset from it by the sum
of the end-indent and the end-intrusion-adjustment of the line area,
whose before-edge is separated from the
baseline-start-point by the text-altitude of the parent block-area, and whose after-edge is
separated from the baseline-start-point by the text-depth of the parent block-area. It has the
same block-progression-dimension for each line-area child of a block-area.
The
maximum-line-rectangle
for a line-area is the rectangle
whose start-edge and end-edge are parallel to and coincident with the start-edge
and end-edge of the nominal-requested-line-rectangle, and whose
extent in the block-progression-direction is the minimum required to enclose both the
nominal-requested-line-rectangle and the allocation-rectangles of all the
inline-areas stacked within the line-area; this may vary depending on the
descendants of the line-area.
[D]
Nominal and Maximum Line Rectangles
The
per-inline-height-rectangle
for a line-area is the rectangle
whose start-edge and end-edge are parallel to and coincident with the start-edge
and end-edge of the nominal-requested-line-rectangle, and whose extent in the
block-progression-dimension is determined as follows.
The
expanded-rectangle
of an inline-area is the rectangle with start-edge
and end-edge coincident with those of its allocation-rectangle, and whose
before-edge and after-edge are outside those of its allocation-rectangle by a
distance equal to either (a.) the half-leading, when the area's allocation-rectangle is
specified to be the normal-allocation-rectangle by the description of the generating
formatting object , or (b.) the space-before and space-after (respectively),
when the area's allocation-rectangle is specified to be the large-allocation-rectangle. The
expanded-nominal-requested-line-rectangle
is the rectangle with start-edge
and end-edge coincident with those of the nominal-requested-line-rectangle, and whose
before-edge and after-edge are outside those of the nominal-requested-line-rectangle by a
distance equal to the half-leading.
The extent of the
per-inline-height-rectangle in the block-progression-direction is then defined to
be the minimum required to enclose both
the expanded-nominal-requested-line-rectangle and the expanded-rectangles of all the
inline-areas stacked within the line-area; this may vary depending on the
descendants of the line-area.
Note:
Using the nominal-requested-line-rectangle allows equal baseline-to-baseline
spacing. Using the maximum-line-rectangle allows constant space between line-areas.
Using the
per-inline-height-rectangle and zero space-before and space-after allows
CSS-style line box stacking. Also, the value of half-leading is included in the
expanded-rectangle regardless of conditionality, and thus a line-height conditionality
of "discard" does not have effect in this case.
4.6 Inline-areas
An inline-area has its own
line-height
trait, which may be
different from the line-height of its containing block-area. This may affect the
placement of its ancestor line-area when the line-stacking-strategy
is
line-height
. An inline-area has an
actual-baseline-table
for its
nominal-font
. It has
dominant-baseline-identifier
trait which determines how
its stacked inline-area descendants are to be aligned.
An inline-area may or may not have child areas, and if so it may or may not
be a reference-area. The dimensions of the content-rectangle for an inline-area
without children is computed as specified by the generating formatting object,
as are those of an inline-area with block-area children.
An inline-area with inline-area children has a content-rectangle
which extends from its dominant baseline (see
4.2.6 Font Baseline Tables
) by its
text-depth in the block-progression-direction, and in the opposite
direction by its text-altitude; in the inline-progression-direction it
extends from the start-edge of the allocation-rectangle of its first child to
the end-edge of the allocation-rectangle of its last child. The allocation-rectangle
of such an inline-area is the same as its content-rectangle.
The allocation-rectangle of an inline-area without children is either
the normal-allocation-rectangle or the large-allocation-rectangle, as specified
in the description of the generating formatting object.
Note:
When the line-stacking-strategy is
line-height
allocation is done with respect to the expanded-rectangle.
Examples of inline-areas with children might include portions of inline
mathematical expressions or areas arising from mixed writing systems
(left-to-right within right-to-left, for example).
4.6.1 Stacked Inline-areas
Inline-area children of an area are typically stacked in the
inline-progression-direction
within their parent area, and this is the default method of
positioning inline-areas.
Inline-areas are stacked relative to the
dominant baseline
as defined above

4.2.6 Font Baseline Tables
).
For a parent area
whose children are inline-areas,
is defined to be
properly stacked
if all of the following conditions
hold:
For each inline-area descendant
of
, the
start-edge, end-edge, before-edge and after-edge of the allocation-rectangle
of
are parallel to corresponding edges of the content-rectangle
of the nearest ancestor reference-area of
For each pair of normal areas
and
in the subtree below
, if
and
' have
an inline-stacking constraint
, then the distance between the
adjacent edges of
and
' is consistent with the
constraint imposed by the resolved values of the space-specifiers in
For any inline-area descendant
of
, the
distance in the shift-direction from the dominant baseline of the parent
of
, to the alignment-point of
equals the offset between the dominant baseline of
and
the baseline of
corresponding to the alignment-baseline
trait of
, plus
the baseline-shift for
The first summand is computed to compensate for
mixed writing systems with different baseline types, and the other
summands involve deliberate baseline shifts for things like superscripts
and subscripts.
4.6.2 Glyph-areas
The most common inline-area is a glyph-area, which contains the
representation for a character (or characters) in a particular font.
A glyph-area has an associated
nominal-font
, determined by
the area's typographic traits, which apply to its character data, and
glyph-orientation
determined by its writing-mode and
reference-orientation, which determine the orientation of the glyph
when it is rendered.
The alignment-point and dominant-baseline-identifier of a glyph-area are assigned
according to the writing-system in use (e.g., the glyph baseline
in Western languages), and are used to control placement of inline-areas
descendants of a line-area. The formatter may generate inline-areas with
different inline-progression-directions from their parent to accommodate
correct inline-area stacking in the case of mixed writing systems.
A glyph-area has no children. Its block-progression-dimension and
actual-baseline-table are the same for all glyphs in a font.
Conforming implementations may choose to
compute the block-progression-dimension for a glyph area based on the
actual glyph size rather than using a common size for all glyphs
in a font.
4.7 Ordering Constraints
4.7.1 General Ordering Constraints
A subset
of the areas returned to a formatting object is
called
properly ordered
if the areas in that
subset have the
same order as their generating formatting objects. Specifically, if
and
are areas in
, returned by child
formatting objects
and
where
precedes
then
must precede
in the
pre-order traversal order of the area tree. If
equals
and
is
returned prior to
, then
must precede
in the pre-order-traversal
of the area tree.
For each formatting object
and each area-class
the subset consisting of the areas returned to
with area-class
must be properly ordered, except where
otherwise specified.
4.7.2 Line-building
This section describes the ordering constraints that apply to formatting
an fo:block or similar block-level object.
A block-level formatting object
which
constructs lines does so by
constructing block-areas which it returns to its parent
formatting object, and placing normal areas and/or anchor areas returned to
by its child
formatting objects as children of those block-areas or of
line-areas
which it constructs as children of those block-areas.
For each such formatting object
, it must be
possible to form an
ordered partition
consisting of ordered subsets
, ...,
of
the normal areas and anchor areas returned by the child formatting objects,
such that the following are all satisfied:
Each subset consists of a sequence of inline-areas, or of a single
block-area.
The ordering of the partition follows the ordering of the
formatting object tree. Specifically, if
is in
and
is in
with
, or if
and
are both in the same subset
with
before
in the
subset order, then either
is returned by a preceding sibling
formatting object of
, or
and
are returned by the same
formatting object with
being returned before
The partitioning occurs at legal line-breaks. Specifically, if
is
the last area of
and
is the first area of
+1
, then the rules of
the language, script and hyphenation constraints
7.10 Common Hyphenation Properties
7.16.1 hyphenation-keep
, and
7.16.2 hyphenation-ladder-count
in effect must permit a line-break
between
and
, within the context of all areas in
and
+1
Forced line-breaks are respected.
Specifically, if C is a descendant of F, and C is an fo:character
whose Unicode character is U+000A, and A is the area generated by C,
then either C is a child of F and A is the last area in a subset S
or C is a descendant of a child C' of F, and A ends
(in the sense of 4.2.5) an area A' returned by C',
such that A' is the last area in a subset S
The partition follows the ordering of the area tree,
except for certain glyph substitutions and deletions.
Specifically, if B
, B
, ..., B
are
the normal child areas of the area or areas returned by F,
(ordered in the pre-order traversal order of the area tree),
then there is a one-to-one correspondence between these child areas
and the partition subsets (i.e. n = p), and for each i,
consists of a single block-area and
is that block-area, or
consists of inline-areas and B
is a line-area
whose child areas are the same as the inline-areas in S
and in the same order, except that where the rules of the language
and script in effect call for glyph-areas to be substituted,
inserted, or deleted, then the substituted or inserted glyph-areas
appear in the area tree in the corresponding place, and the
deleted glyph-areas do not appear in the area tree.
For example, insertions and substitutions may occur because of
addition of hyphens or spelling changes due to hyphenation,
or glyph image construction from syllabification, or ligature formation.
Deletions occur as specified in
6.
below.
white-space-treatment is enforced. In particular,
deletions in
5.
occur when there is a glyph area G such that
(a.) the white-space-treatment of G is "ignore" and the character of G
is classified as white space in XML; or
(b.) the white-space-treatment of G is "ignore-if-before-linefeed" or
"ignore-if-surrounding-linefeed", the suppress-at-line-break of G is
"suppress", and G would end a line-area; or
(c.) the white-space-treatment of G is "ignore-if-after-linefeed" or
"ignore-if-surrounding-linefeed", the suppress-at-line-break of G is
"suppress", and G would begin a line-area.
In these cases the area G is deleted; this may cause the condition in
clauses (b.) or (c.) to become true and lead to further deletions.
Substitutions that replace a sequence of glyph-areas with a single
glyph-area should only occur when the margin, border, and padding in the
inline-progression-direction (start- and end-), baseline-shift, and
letter-spacing values are zero, treat-as-word-space is
false
, and the
values of all other relevant traits match (i.e.,
alignment-adjust, alignment-baseline, color
trait, background traits, dominant-baseline-identifier, font traits,
text-depth,
text-altitude, glyph-orientation-horizontal,
glyph-orientation-vertical, line-height, line-height-shift-adjustment,
text-decoration, text-shadow).
Note:
Line-areas do not receive the background traits or text-decoration
of their generating formatting object, or any other trait that requires
generation of a mark during rendering.
4.7.3 Inline-building
This section describes the ordering constraints that apply to formatting
an fo:inline or similar inline-level object.
An inline-level formatting object
which
constructs one or more inline-areas does so by
placing normal inline-areas and/or anchor inline-areas returned to
by its child
formatting objects as children of inline-areas which it
generates.
For each such formatting object
, it must be
possible to form an
ordered partition
consisting of ordered subsets
, ...,
of
the normal and/or anchor inline-areas and normal block-areas
returned by the child formatting objects,
such that the following are all satisfied:
Each subset consists of a sequence of inline-areas,
or of a single block-area.
The ordering of the partition follows
the ordering of the formatting object tree, as defined above.
The partitioning occurs at legal line-breaks, as defined above.
Forced line-breaks are respected, as defined above.
The partition follows the ordering of the area tree,
except for certain glyph substitutions and deletions, as
defined above.
4.8 Keeps and Breaks
Keep and break conditions apply to a class of areas, which are typically
page-reference-areas,
column-areas, and line-areas. The appropriate class for a given condition is referred
to as a
context
and an area in this class is a
context-area
As defined in Section
6.4.1 Introduction
page-reference-areas
are
areas generated by an fo:page-sequence using the
specifications in an fo:page-master, and
column-areas
are
normal-flow-reference-areas generated from a region-body, or
region-reference-areas generated from other types of region-master.
A keep or break condition is an open statement about a formatting object and the
tree relationships of the areas it generates with the relevant context-areas. These
tree relationships are defined mainly in terms of
leading
or
trailing
areas. If
is a descendant of
, then
is defined to
be
leading
in
if
has no preceding sibling which
is a normal area, nor does any of its ancestor areas up to but not including
. Similarly,
is defined to
be
trailing
in
if
has no following sibling which
is a normal area, nor does any of its ancestor areas up to but not including
. For any given formatting object, the
next
formatting object
in the flow is the first formatting object following (in the pre-order traversal order)
which is not a descendant of the given formatting object and
which generates and returns normal areas.
Break conditions are either break-before or break-after conditions. A break-before
condition is
satisfied
if the first area generated and returned
by the formatting object is
leading within a context-area. A break-after condition
depends on the next formatting object in
the flow; the condition
is satisfied if either there is no such next formatting object, or if the
first normal area generated and returned by that formatting object is leading in a context-area.
Break conditions are imposed by the
break-before
and
break-after
properties. A
refined value of
page
for these traits imposes a
break condition with a context
consisting of the page-reference-areas; a value of
even-page
or
odd-page
imposes a
break condition with a context of even-numbered page-reference-areas
or odd-numbered
page-reference-areas, respectively; a value of
column
imposes a
break condition with a
context of column-areas. A value of
auto
in a
break-before or break-after
trait imposes no break condition.
Keep conditions are either keep-with-previous, keep-with-next, or keep-together
conditions. A keep-with-previous condition on an object is satisfied if the first
area generated and returned by the formatting object is not leading within a
context-area, or if
there are no preceding areas in a post-order traversal of the area tree. A
keep-with-next condition is satisfied if the last area generated and returned by the
formatting object is not trailing within a context-area, or
if there are
no following areas in a pre-order traversal of the area tree. A keep-together
condition is satisfied if all areas generated and returned by the formatting object are
descendants of a single context-area.
Keep conditions are imposed by the "within-page", "within-column", and "within-line" components
of the "keep-with-previous", "keep-with-next", and
"keep-together" properties.
The refined value of each component specifies the
strength
of the keep condition
imposed, with higher numbers being stronger than lower numbers and the value
always
being stronger than all numeric values.
A component with value
auto
does not impose a keep condition. A "within-page" component imposes a keep-condition
with context consisting of the page-reference-areas; "within-column", with context consisting of
the column-areas; and "within-line" with context consisting of the line-areas.
The area tree is constrained to satisfy all break conditions imposed.
Each keep condition must also be satisfied, except when this would cause a
break condition or a stronger keep condition to fail to be satisfied. If not
all of a set of keep conditions of equal strength can be satisfied, then some
maximal satisfiable subset of conditions of that strength
must be satisfied (together with all break conditions
and maximal subsets of stronger keep conditions, if any).
4.9 Rendering Model
This section makes explicit the relationship between the area tree
and visually rendered output.
Areas generate three types of marks: (1) the area
background, if any, (2) the marks
intrinsic to the area (a glyph, image, or decoration) if any, and (3) the
area border, if any.
An area tree is rendered by causing marks to appear on an output medium in
accordance with the areas in the area tree. This section describes the
geometric location of such marks, and how conflicts between marks are to
be resolved.
4.9.1 Geometry
Each area is rendered in a particular location. Formatting object semantics
describe the location of intrinsic marks relative to the object's location,
i.e., the left, right, top, and bottom edges of its content-rectangle. This
section describes how the area's location is determined,
which determines the location of its intrinsic marks.
For each page, the page-viewport-area corresponds isometrically to the
output medium.
The page-reference-area is offset from the page-viewport-area as described
below in section
4.9.2 Viewport Geometry
All areas in the tree with an area-class of
xsl-fixed
are positioned such
that the left-, right-, top-, and bottom-edges of its
content-rectangle are
offset inward from the content-rectangle of its ancestor page-viewport-area
by distances specified by the
left-position
right-position
top-position
and
bottom-position
traits, respectively.
Any area in the tree which is the child of a viewport-area is rendered
as described in section
4.9.2 Viewport Geometry
All other areas in the tree are positioned such that the
left-, right-, top-,
and bottom-edges of its content-rectangle are offset inward
from the
content-rectangle of its nearest ancestor reference-area by distances
specified by the
left-position
right-position
top-position
and
bottom-position
traits, respectively. These are shifted down
and left by the values of the
top-offset
and
left-offset
traits, respectively, if the area
has a
relative-position
of
relative
4.9.2 Viewport Geometry
A reference-area which is the child of a viewport-area is positioned
such that
the start-edge and end-edge of its content-rectangle are
parallel to the
start-edge and end-edge of the content-rectangle of its parent
viewport-area. The start-edge of its content-rectangle
is offset from the start-edge of the content-rectangle of its parent viewport-area
by an
inline-scroll-amount
, and the before-edge of its content-rectangle is offset from the
before-edge of
the content-rectangle of its parent viewport-area by a
block-scroll-amount
If the block-progression-dimension of the reference-area is larger
than that
of the viewport-area and the
overflow
trait
for the reference-area is
scroll
then the inline-scroll-amount and block-scroll-amount are
determined by a scrolling mechanism, if any,
provided by the user agent. Otherwise, both are zero.
4.9.3 Visibility
The visibility of marks depends upon the location of the marks,
the
visibility
of the area, and the
overflow
of any ancestor
viewport-areas.
If an area has visibility
hidden
it generates no marks.
If an area has an
overflow
of
hidden
or when the environment is non-dynamic and the
overflow
is
scroll
then the area determines
clipping rectangle
, which is defined to be the
rectangle determined by the value of the
clip
trait of the area, and
for any mark
generated by one of its descendant areas, portions of the mark
lying outside
the clipping rectangle do not appear.
4.9.4 Border, Padding, and Background
The border- and padding-rectangles are determined relative to the
content-rectangle by the values of the common padding and border width
traits (border-before-width, etc.).
For any area, which is not a child of a viewport-area, the border is
rendered between the border-rectangle and the padding-rectangle in
accordance with the common border color and style traits. For a child of
a viewport-area, the border is not rendered.
For an area, which is not part of a viewport/reference pair, the
background is rendered. For an area that is either a viewport-area or a
reference-area in a viewport/reference pair, if the refined value of
background-attachment
is
scroll
and the block-progression-dimension of the reference-area is larger than
that of the viewport-area, then the background is rendered on the
reference-area and not the viewport-area, and otherwise it is rendered
on the viewport-area and not the reference-area.
The background, if any, is rendered in the
padding-rectangle, in accordance
with the
background-image
background-color
background-repeat
background-position-vertical
, and
background-position-horizontal
traits.
4.9.5 Intrinsic Marks
For each class of formatting objects, the marks intrinsic to its
generated areas are specified in the formatting object description.
For example, an fo:character object generates a glyph-area, and this
is rendered by drawing a glyph within that area's
content-rectangle in accordance with the area's font traits and
glyph-orientation
and
blink
traits.
In addition, other traits (for example the various score and score-color traits) specify
other intrinsic
marks. In the case of score traits (
underline-score
overline-score
and
through-score
), the score thickness and position
are specified by the nominal-font in effect; where the font fails to
specify these quantities, they are implementation-dependent.
4.9.6 Layering and Conflict of Marks
Marks are layered as described below, which defines a partial
ordering of which marks are
beneath
which other marks.
Two marks are defined to
conflict
if they apply to
the same point
in the output medium. When two marks conflict, the one which is
beneath the other does not affect points in the output medium where
they both apply.
Marks generated by the same area are layered as follows: the area
background is beneath the area's intrinsic marks, and the intrinsic
marks are beneath the border. Layering among the area's intrinsic
marks is defined by the semantics of the area's generating formatting
object and its properties. For example, a glyph-area's glyph drawing
comes beneath the marks generated for text-decoration.
The stacking layer of an area is defined by its stacking context and
its z-index value. The stacking layer of an area
is defined to be less
than that of an area
if some ancestor-or-self
A'
of
and
B'
of
have the same stacking context and
the z-index of
A'
is less
than the z-index of
B'
. If neither stacking layer is less than the
other then they are defined to have the same stacking layer.
If
and
are areas, and the stacking layer
of
is less than the stacking layer
of
, then all marks generated by
are beneath all marks generated by
If
and
are areas with the same
stacking layer, the backgrounds of
and
come beneath all other marks generated by
and
. Further, if
is an
ancestor of
(still with the same stacking layer), then
the background of
is beneath all the areas of
, and all the areas
of
are beneath the intrinsic areas (and border)
of
If
and
have the same stacking layer and
neither is an ancestor of the other,
then it is an error if either their backgrounds conflict or if a
non-background mark of
conflicts with a
non-background mark of
An implementation may recover by proceeding as if the marks from the
first area in the pre-order traversal order are beneath those of the
other area.
4.10 Sample Area Tree
[D]
A Typical Area Tree
5 Property Refinement / Resolution
Every formatting property may be specified on every formatting
object. For each formatting object class, however, only a subset of
the formatting properties are used; those that
apply
to the class.
During refinement the set of
properties
that apply to a formatting
object is transformed into a set of
traits
that
define constraints on the result of formatting. For many traits there
is a one-to-one correspondence with a property; for other traits the
transformation is more complex. Details on the transformation are
described below.
The first step in refinement of a particular formatting object
is to obtain the effective value of each property that applies to the
object. Any shorthand property specified on the formatting object is
expanded into the individual properties. This is further described in
5.2 Shorthand Expansion
. For any property that has not been specified
on the object the inherited (see
5.1.4 Inheritance
or initial value, as applicable, is used as the effective value.
The second step is to transform this property set into traits.
Note:
Although the refinement process is described in a series of
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.
5.1 Specified, Computed, and Actual Values, and Inheritance
For every property that is applicable to 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-construction process.
A specified value may not be in a
form that is directly usable; for example, it may be a
percentage or other expression
that must be converted into an absolute value.
A value resulting from such a conversion is called the
"computed value". Finally, the computed value may not be
realizable on the output medium 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."
5.1.1 Specified Values
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 specified on the formatting object.
In general, this is an error.
Since it has no parent, the root of the result tree
cannot use values from a parent formatting
object; in this case, the initial value is used if necessary.
5.1.2 Computed Values
Specified values may be absolute (i.e., they are not
specified relative to another value, as in "red" or "2mm")
or relative (i.e., they are specified relative to another value,
as in "auto", "2em", and "12%"), or they may be expressions.
For most absolute values, no
computation is needed to find the computed value. Relative values,
on the other hand, must be transformed into computed values: percentages
must be multiplied by a reference value (each property defines which value
that is), values with a relative unit (em)
must be made absolute by multiplying with the appropriate font size,
"auto" values must be computed by the formulas given with
each property, certain property
values ("smaller", "bolder") must be replaced
according to their definitions.
The computed value of any property that controls a border width
where the style of
the border is "none" is forced to be "0pt".
Some properties have more than one way in which the property value can be specified.
The simplest example of such properties are those which can be specified
either in terms of a direction relative to the writing-mode (e.g., padding-before)
or a direction in terms of the absolute geometric orientation of the viewport
(e.g., padding-top). These two properties are called the
relative property and the absolute property, respectively.
Collectively, they are called "corresponding properties".
Specifying a value for one property determines both a
computed value for the specified property and a computed value
for the corresponding property.
Which relative property corresponds to which absolute
property depends on the writing-mode. For example, if
the "writing-mode" at the top level of a document is
"lr-tb",
then "padding-start" corresponds to "padding-left", but if
the "writing-mode" is "rl-tb", then "padding-start"
corresponds to "padding-right".
The exact specification of how to compute the values of
corresponding properties is given in
5.3 Computing the Values of Corresponding Properties
In most cases, elements inherit computed values. However,
there are some properties whose specified value may be
inherited (e.g., some values for the "line-height"
property).
In the cases where child elements do not inherit the computed value,
this is described in the property definition.
5.1.3 Actual Values
A computed value is in principle ready to be
used, but a user agent may not be able to make
use of the value in a given environment. For
example, a user agent may only be able to render
borders with integer pixel widths and may, therefore,
have to adjust the computed width to an integral number
of media pixels. The actual
value is the computed value after any such adjustments have been applied.
5.1.4 Inheritance
Some of the properties applicable to formatting objects are "inheritable."
Such properties are so identified in the property description.
The inheritable properties can be placed on any formatting
object. The inheritable properties are propagated down the
formatting object tree from a parent to each child. (These properties
are given their initial value at the root of the result tree.)
For a given inheritable property, if that property is present on a
child, then that value of the property is used for that child
(and its descendants until explicitly re-set in a lower descendant);
otherwise, the specified value of that property on the child is the
computed value of that property on the parent formatting
object. Hence there is always a specified value
defined for every inheritable property for every
formatting object.
5.2 Shorthand Expansion
In XSL there are two kinds of shorthand properties; those originating
from CSS, such as "border", and those that arise from breaking apart
and/or combining CSS properties, such as "page-break-inside". In XSL
both types of shorthands are handled in the same way.
Note:
Shorthands are included only in the highest XSL conformance
level: "complete" (see
8 Conformance
).
The conformance level for each property is shown in
B.3 Property Table: Part II
Shorthand properties do not inherit from
the shorthand on the parent. Instead the individual properties that
the shorthand expands into may inherit.
Some CSS shorthands are interrelated; their expansion has one
or more individual properties in common.
CSS indicates that the user must specify the order of processing
for combinations of multiple interrelated shorthands and individual
interrelated properties. In XML, attributes are defined as unordered.
To resolve this issue, XSL defines a precedence order
when multiple interrelated shorthand properties or a shorthand property
and an interrelated individual property are specified:
They are processed in increasing precision (i.e., "border" is less precise
than "border-top", which is less precise than "border-top-color").
The individual properties are always more precise than any shorthand.
For the remaining ambiguous case, XSL defines the ordering to
be:
"border-style", "border-color", and "border-width"
is less precise than
"border-top", "border-bottom", "border-right",
and "border-left".
Processing is conceptually in the following steps:
Set the effective value of
all properties to their initial values.
Process all shorthands in increasing precision.
If the shorthand is set to "inherit": set the effective
value of each property that can be set by the shorthand to
the computed value of the corresponding property in the parent.
If the value of the shorthand is not "inherit": determine which
individual properties are to be set, and replace the
initial value with the computed value derived from the specified
value.
Process all specified individual properties.
Carry out any inheritance for properties that were
not given a value other than by the first step.
Note:
For example,
if both the "background"
and the "background-color" properties are specified on a given
formatting object:
process the "background" shorthand, then process the
"background-color" property.
5.3 Computing the Values of Corresponding Properties
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 on the object. See description
below.
The correspondence mapping from absolute to relative property
is as follows:
If the "writing-mode" specifies a block-progression-direction of
"top-to-bottom": "top" maps to "before", and "bottom" maps to "after".
If the "writing-mode" specifies a block-progression-direction of
"bottom-to-top": "top" maps to "after", and "bottom" maps to "before".
If the "writing-mode" specifies a block-progression-direction of
"left-to-right": "left" maps to "before", and "right" maps to "after".
If the "writing-mode" specifies a block-progression-direction of
"right-to-left": "left" maps to "after", and "right" maps to "before".
If the "writing-mode" specifies an inline-progression-direction of
"left-to-right": "left" maps to "start", and "right" maps to "end".
If the "writing-mode" specifies an inline-progression-direction of
"right-to-left": "left" maps to "end", and "right" maps to "start".
If the "writing-mode" specifies an inline-progression-direction of
"top-to-bottom": "top" maps to "start", and "bottom" maps to "end".
If the "writing-mode" specifies an inline-progression-direction of
"bottom-to-top": "top" maps to "end", and "bottom" maps to "start".
If the "writing-mode" specifies an inline-progression-direction of
"left-to-right" for odd-numbered lines, and "right-to-left" for
even-numbered lines: "left" maps to "start", and "right" maps to "end".
Note:
"reference-orientation" is a rotation and does not influence
the correspondence mapping.
5.3.1 Border and Padding Properties
The simplest class of corresponding properties are
those for which there are only two variants in the
correspondence, an absolute property and a relative
property, and the property names differ only in the
choice of absolute or
relative designation; for example, "border-left-color" and
"border-start-color".
For this class, the computed values of the corresponding
properties are determined as follows. If the corresponding
absolute variant of the property is specified on the formatting
object, its computed value is used to set the computed value of the
corresponding relative property. If the corresponding absolute property
is not explicitly specified, then the computed
value of the absolute property is set to the computed value of the
corresponding relative property.
If the corresponding relative property is specified on the
formatting object and the absolute property only specified by
the expansion of a shorthand, then the computed value of the
absolute property is set to the computed value of the corresponding
relative property.
Note that if both the absolute and the relative
properties are not
explicitly specified, then the rules for determining the specified
value will use either inheritance if that is defined for the property
or the initial value. The initial value must be the same for all possible
corresponding properties. If both an absolute and a corresponding relative
property are explicitly specified, then the above rule gives precedence to the
absolute property, and the specified value of the
corresponding relative property
is ignored in determining the computed value of the corresponding properties.
The (corresponding) properties that use the above rule to
determine their computed value are:
border-after-color
border-before-color
border-end-color
border-start-color
border-after-style
border-before-style
border-end-style
border-start-style
border-after-width
border-before-width
border-end-width
border-start-width
padding-after
padding-before
padding-end
padding-start
5.3.2 Margin, Space, and Indent Properties
The "space-before", and "space-after" properties (block-level
formatting objects), "space-start", and "space-end" properties
(inline-level formatting objects) are handled in the same way as the
properties immediately above, but the corresponding
absolute properties are in the set: "margin-top",
"margin-bottom", "margin-left", and "margin-right".
The .conditionality component of any space-before or space-after determined
from a margin property is set to "retain".
Note:
The treatment of the .conditionality component is for CSS2
compatibility.
Note:
The computed value of a CSS2 margin in the
block-progression-dimension specified as "auto" is 0pt. Any space-before
or space-after determined from a margin value of "auto" is set to 0pt.
There are two more properties, "end-indent"
and "start-indent" (block-level
formatting objects) which correspond to the
various absolute "margin" properties. For these properties,
the correspondence is more complex and involves the corresponding
"border-X-width" and "padding-X" properties,
where X is one of "left", "right", "top" or "bottom".
The computed values of these corresponding properties are determined
as follows:
If the corresponding absolute "margin" property is specified on the
formatting object and the formatting object generates a reference area
the computed value of the margin is used to calculate the computed
value of the corresponding "Y-indent" property,
where Y is either "start" or "end".
The computed value of the of the absolute "margin" property
is determined by the CSS descriptions of the properties
and the relevant sections (in particular section 10.3) of the
CSS Recommendation referenced by these properties.
The formulae for "start-indent"
and "end-indent" are":
start-indent = margin-corresponding
+ padding-corresponding + border-corresponding-width
end-indent = margin-corresponding
+ padding-corresponding + border-corresponding-width
If the corresponding absolute "margin" property is specified on the
formatting object and the formatting object does not generate a
reference area, the computed value of the margin and the computed values
of the corresponding "border-X-width" and "padding-X" properties are used to
calculate the computed value of the corresponding "Y-indent" property.
The formulae for "start-indent"
and "end-indent" are:
start-indent = inherited_value_of(start-indent) +
margin-corresponding + padding-corresponding +
border-corresponding-width
end-indent = inherited_value_of(end-indent) +
margin-corresponding + padding-corresponding +
border-corresponding-width
If the corresponding absolute margin property is not explicitly
specified, or if
the corresponding relative property is specified on the
formatting object and the absolute property only specified by
the expansion of a shorthand,
the corresponding absolute margin property is calculated
according to the following formulae:
margin-corresponding = start-indent -
inherited_value_of(start-indent) - padding-corresponding -
border-corresponding-width
margin-corresponding = end-indent -
inherited_value_of(end-indent) - padding-corresponding -
border-corresponding-width
Note:
If the "start-indent" or "end-indent" properties are not
specified their inherited value is used in these formulae.
5.3.3 Height, and Width Properties
Based on the writing-mode in effect for the formatting object,
either the "height", "min-height", and "max-height" properties, or
the "width", "min-width", and "max-width" properties are converted
to the corresponding block-progression-dimension, or
inline-progression-dimension.
The "height" properties are absolute and indicate the dimension
from "top" to "bottom"; the width properties the dimension from
"left" to "right".
If the "writing-mode" specifies a block-progression-direction of
"top-to-bottom" or "bottom-to-top" the conversion is as follows:
If any of "height", "min-height", or "max-height" is specified:
If "height" is specified then first set:
block-progression-dimension.minimum=
block-progression-dimension.optimum=
block-progression-dimension.maximum=
If "height" is not specified, then first set:
block-progression-dimension.minimum=auto
block-progression-dimension.optimum=auto
block-progression-dimension.maximum=auto
Then, if "min-height" is specified, reset:
block-progression-dimension.minimum=
Then, if "max-height" is specified, reset:
block-progression-dimension.maximum=
However, if "max-height" is specified
as "none", reset:
block-progression-dimension.maximum=auto
If any of "width", "min-width", or "min-width" is specified:
If "width" is specified then first set:
inline-progression-dimension.minimum=
inline-progression-dimension.optimum=
inline-progression-dimension.maximum=
If "width" is not specified, then first set:
inline-progression-dimension.minimum=auto
inline-progression-dimension.optimum=auto
inline-progression-dimension.maximum=auto
Then, if "min-width" is specified, reset:
inline-progression-dimension.minimum=
Then, if "max-width" is specified, reset:
inline-progression-dimension.maximum=
However, if "max-width" is specified
as "none", reset:
inline-progression-dimension.maximum=auto
If the "writing-mode" specifies a block-progression-direction of
"left-to-right" or "right-to-left" the conversion is as follows:
If any of "height", "min-height", or "max-height" is specified:
If "height" is specified then first set:
inline-progression-dimension.minimum=
inline-progression-dimension.optimum=
inline-progression-dimension.maximum=
If "height" is not specified, then first set:
inline-progression-dimension.minimum=auto
inline-progression-dimension.optimum=auto
inline-progression-dimension.maximum=auto
Then, if "min-height" is specified, reset:
inline-progression-dimension.minimum=
Then, if "max-height" is specified, reset:
inline-progression-dimension.maximum=
However, if "max-height" is specified
as "none", reset:
inline-progression-dimension.maximum=auto
If any of "width", "min-width", or "min-width" is specified:
If "width" is specified then first set:
block-progression-dimension.minimum=
block-progression-dimension.optimum=
block-progression-dimension.maximum=
If "width" is not specified, then first set:
block-progression-dimension.minimum=auto
block-progression-dimension.optimum=auto
block-progression-dimension.maximum=auto
Then, if "min-width" is specified, reset:
block-progression-dimension.minimum=
Then, if "max-width" is specified, reset:
block-progression-dimension.maximum=
However, if "max-width" is specified
as "none", reset:
block-progression-dimension.maximum=auto
5.3.4 Overconstrained Geometry
The sum of the start-indent, end-indent, and inline-progression-dimension
of the content-rectangle of an area should be equal to the
inline-progression-dimension of the content-rectangle of the closest
ancestor reference-area. In the case where a specification would
lead to them being different the end-indent (and thus the corresponding
margin) is adjusted such that the equality is true.
5.4 Simple Property to Trait Mapping
The majority of the properties map into traits of the same name.
Most of these also simply copy the value from the property.
These are classified as "Rendering", "Formatting", "Specification",
"Font selection", "Reference", and "Action" in the property table in
B.3 Property Table: Part II
For example, the property
font-style="italic"
is
refined into a
font-style
trait with a value of "italic".
Some traits have a value that is different
from the value of the property. These are classified as "Value change"
in the property table.
For example, the property
background-position-horizontal="left"
is refined into a
background-position-horizontal
trait
with a value of "0pt".
The value mapping for these traits is given below.
5.4.1 Background-position-horizontal and background-position-vertical Properties
A value of "top", "bottom", "left", "right", or "center" is
converted to a length as specified in the property definition.
5.4.2 Column-number Property
If a value has not been specified on a formatting object to which
this property applies the initial value is computed as specified
in the property definition.
5.4.3 Text-align Property
A value of "left", or "right" is converted to the writing-mode
relative value as specified in the property definition.
5.4.4 Text-align-last Property
A value of "left", or "right" is converted to the writing-mode
relative value as specified in the property definition.
5.4.5 z-index Property
The value is converted to one that is absolute; i.e., the refined value
is the specified value plus the refined value of z-index of its parent
formatting object, if any.
5.4.6 Language Property
A value being a 2-letter code in conformance with
[ISO639]
is converted to the corresponding
3-letter
[ISO639-2]
terminology code,
a 3-letter code in conformance with
[ISO639-2]
bibliographic code is converted to the corresponding 3-letter
terminology code, a value of 'none' or 'mul' is converted to 'und'.
5.5 Complex Property to Trait Mapping
A small number of properties influence traits in a more
complex manner. Details are given below.
5.5.1 Word spacing and Letter spacing Properties
These properties may set values for the
space-start
and
space-end
traits, as described in the property
definitions.
5.5.2 Reference-orientation Property
The
reference-orientation
trait is copied from
the reference-orientation property during refinement. During
composition an absolute orientation is determined
(see
4.2.2 Common Traits
).
5.5.3 Writing-mode and Direction Properties
The
writing-mode
direction
, and
unicode-bidi
traits
are copied from
the properties of the same name during refinement.
During composition these are used in the determination of
absolute orientations for the
block-progression-direction
inline-progression-direction
, and
shift-direction
traits
in accordance with
4.2.2 Common Traits
5.5.4 Absolute-position Property
If absolute-position has the value
"absolute" or "fixed", the values of the
left-position
top-position
, etc. traits
are copied directly from the
values of the "left", "top", etc. properties. Otherwise these traits'
values are left undefined during refinement and determined during
composition.
5.5.5 Relative-position Property
If relative-position has the value
"relative" then the values of the
left-offset
and
top-offset
traits are copied directly
from the "left" and "top"
properties. If the "right" property is specified but "left" is not,
then
left-offset
is set to the negative of the
value of "right". If neither
"left" nor "right" is specified the
left-offset
is 0.
If the "bottom"
property is specified but "top" is not, then
top-offset
is set to the
negative of the value of "bottom". If neither "top" nor "bottom" is
specified the
top-offset
is 0.
5.5.6 Text-decoration Property
The "text-decoration" property value provides values for
the
blink
trait and a set of
score and score-color traits. The
specified color
has the
value of the
color
trait of the formatting object
for which the "text-decoration" property is being refined.
A property value containing the token "underline" sets a value of
"true" to the
underline-score
trait, and a value of
specified color
to the
underline-score-color
trait.
A property value containing the token "overline" sets a value of
"true" to the
overline-score
trait, and a value of
specified color
to the
overline-score-color
trait.
A property value containing the token "line-through" sets a value of
"true" to the
through-score
trait, and a value of
specified color
to the
through-score-color
trait.
A property value containing the token "blink" sets a value of
"true" to the
blink
trait.
A property value containing the token "no-underline" sets a value of
"false" to the
underline-score
trait, and a value of
specified color
to the
underline-score-color
trait.
A property value containing the token "no-overline" sets a value of
"false" to the
overline-score
trait, and a value of
specified color
to the
overline-score-color
trait.
A property value containing the token "no-line-through" sets a value of
"false" to the
through-score
trait, and a value of
specified color
to the
through-score-color
trait.
A property value containing the token "no-blink" sets a value of
"false" to the
blink
trait.
5.5.7 Font Properties
The font traits on an area are indirectly derived from the combination
of the font properties, which are used to select a font, and the
font tables from that font.
The abstract model that XSL assumes for a font is described in
7.9.1 Fonts and Font Data
There is no XSL mechanism to specify a particular font; instead,
selected font
is chosen from the fonts available to the
User Agent based on a set of selection criteria. The
selection
criteria
are the following font properties:
"font-family",
"font-style",
"font-variant",
"font-weight",
"font-stretch", and
"font-size",
plus, for some formatting
objects, one or more characters.
The details of
how the selection criteria are used is specified in the
"font-selection-strategy" property (see
7.9.3 font-selection-strategy
).
The
nominal-font
trait is set to the selected font. In the
case where there is no selected font and the 'missing character' glyph
is displayed, the
nominal-font
trait is set to the font containing
that glyph, otherwise
(i.e., some other mechanism was used to indicate that a character
is not being displayed) the
nominal-font
is a
system font.
The
dominant-baseline-identifier
and
actual-baseline-table
traits are derived from the
value of the "dominant-baseline" property. The value of this property
is a compound value with three components: a baseline-identifier for
the dominant-baseline, a baseline-table and a baseline-table
font-size. The
dominant-baseline-identifier
is set from
the first component. The baseline-table font-size is used to scale the
the positions of the baselines from the baseline table and, then, the
position of the dominant-baseline is subtracted from the positions
of the other baselines to yield a table of offsets from the dominant
baseline. This table is the value of the
actual-baseline-table
trait.
5.6 Non-property Based Trait Generation
The
is-reference-area
trait is set to "true" for
specific formatting objects.
The description of these formatting objects specify explicitly that
this is the case.
For all other formatting objects it is set to "false".
5.7 Property Based Transformations
5.7.1 Text-transform Property
The case changes specified by this property are carried out during
refinement by changing the value of the "character" property
appropriately.
Note:
The use of the "text-transform" property is deprecated in XSL
due to its severe internationalization issues.
5.8 Unicode BIDI Processing
The characters in certain scripts are written horizontally from right
to left. In some documents, in particular those written with the
Arabic or Hebrew script, and in some mixed-language contexts, text in
a single (visually displayed) block may appear with mixed
directionality. This phenomenon is called bidirectionality, or "BIDI"
for short.
The Unicode BIDI algorithm
[UNICODE UAX #9]
defines a complex algorithm for
determining the proper directionality of text. The algorithm is based
on both an implicit part based on character properties, as well as
explicit controls for embeddings and overrides.
The final step of refinement uses this algorithm and the Unicode
bidirectional character type of each character to convert the implicit
directionality of the text into explicit markup in terms of formatting
objects. For example, a sub-sequence of Arabic characters in an
otherwise English paragraph would cause the creation of an inline
formatting object with the Arabic characters as its content, with a
"direction" property of "rtl" and a "unicode-bidi" property of
"bidi-override". The formatting object makes explicit the previously
implicit right to left positioning of the Arabic characters.
As defined in
[UNICODE UAX #9]
the Unicode BIDI algorithm
takes a stream of text as input, and proceeds in three main phases:
Separation of the input text into paragraphs. The rest of the algorithm
affects only the text between paragraph separators.
Resolution of the embedding levels of the text. In this phase, the
bidirectional character types, plus the Unicode directional formatting
codes, are used to produce
resolved embedding levels
. The
normative bidirectional character type for each character is specified
in the Unicode Character Database
[UNICODE Character Database]
Reordering the text for display on a line-by-line basis using the
resolved embedding levels, once the text has been broken into lines.
The algorithm, as described above, requires some adaptions to fit
into the XSL processing model. First, the final, text reordering step
is not done during refinement. Instead, the XSL equivalent of
re-ordering is done during area tree generation. The
inline-progression-direction
of each glyph is used to
control the stacking of glyphs as described in
4.2.5 Stacking Constraints
. The
inline-progression-direction
is determined at the block
level by the "writing-mode" property and within the inline formatting
objects within a block by the "direction" and "unicode-bidi"
properties that were either specified on inline formatting objects
generated by tree construction or are on inline formatting objects
introduced by this step of refinement (details below).
Second, the algorithm is applied to a sequence of characters coming
from the content of one or more formatting objects. The sequence of
characters is created by processing a fragment of the formatting
object tree. A
fragment
is any contiguous sequence of
children of some formatting object in the tree. The sequence is
created by doing a pre-order traversal of the fragment down to the
fo:character level. During the pre-order traversal, every fo:character
formatting object adds a character to the sequence. Furthermore,
whenever the pre-order scan encounters a node with a "unicode-bidi"
property with a value of "embed" or "bidi-override", add a Unicode RLO/LRO
or RLE/LRE character to the sequence as appropriate to the value of
the "direction" and "unicode-bidi" properties. On returning to that
node after traversing its content, add a Unicode PDF character. In
this way, the formatting object tree fragment is flattened into a
sequence of characters. This sequence of characters is called the
flattened sequence of characters
below.
Third, in XSL the algorithm is applied to
delimited text
ranges
instead of just paragraphs. A delimited text range is a
maximal flattened sequence of characters that does not contain any
delimiters. Any formatting object that generates block-areas is a
delimiter. It acts as a delimiter for its content. It also acts as a
delimiter for its parent's content. That is, if the parent has
character content, then its children formatting objects that generate
block-areas act to break that character content into
anonymous
blocks
each of which is a delimited text range. In a similar
manner, the fo:multi-case formatting object acts as delimiter for its
content and the content of its parent. Finally, text with an
orientation that is not perpendicular to the dominant-baseline acts as
a delimiter to text with an orientation perpendicular to the
dominant-baseline. We say that
text has an orientation
perpendicular to the dominant-baseline
if the glyphs that correspond
to the characters in the text are all oriented perpendicular to the
dominant-baseline.
Note:
In most cases, a delimited text range is the maximal sequence of
characters that would be formatted into a sequence of one or more
line-areas. For the fo:multi-case and the text with an orientation
perpendicular to the dominant-baseline, the delimited range may be a
sub-sequence of a line or sequence of lines. For example, in Japanese
formatted in a vertical writing-mode, rotated Latin and Arabic text
would be delimited by the vertical Japanese characters that
immediately surround the Latin and Arabic text. Any formatting objects
that generated inline-areas would have no affect on the determination
of the delimited text range.
For each delimited text range, the
inline-progression-direction
of the nearest ancestor (including self) formatting object that generates
a block-area determines the
paragraph embedding level
used
in the Unicode BIDI algorithm. This is the default embedding level
for the delimited text range.
Embedding levels
are numbers that indicate how deeply the
text is nested, and the default direction of text on that level. The
minimum embedding level of text is zero, and the maximum embedding
level is level 61. Having more than 61 embedding levels is an
error. An XSL processor may signal the error. If it does not signal
the error, it must recover by allowing a higher maximum number of
embedding levels.
The second step of the Unicode BIDI algorithm labels each character
in the delimited text range with a
resolved embedding level
The resolved embedding level of each character will be greater than
or equal to the paragraph embedding level. Right-to-left text will
always end up with an odd level, and left-to-right and numeric text
will always end up with an even level. In addition, numeric text
will always end up with a higher level than the paragraph level.
Once the resolved embedding levels are determined for the
delimited text range, new fo:bidi-override formatting objects with
appropriate values for the "direction" and "unicode-bidi" properties
are inserted into the formatting object tree fragment that was
flattened into the delimited text range such that the following
constraints are satisfied:
For any character in the delimited text range, the
inline-progression-direction
of the
character must match its resolved embedding level.
For each resolved embedding level
from the paragraph
embedding level to the maximum resolved embedding level, and for each
maximal contiguous sequence of characters
for which the
resolved embedding level of each character is greater than or equal to
There is an inline formatting object
which has as its
content the formatting object tree fragment that flattens to
and has a "direction" property consistent with the
resolved embedding level
Note:
need not be an inserted formatting object if the
constraint is met by an existing formatting object or by specifying
values for the "direction" and "unicode-bidi" properties on an
existing formatting object.
All formatting objects that contain any part of the sequence
are properly nested in
and retain the
nesting relationships they had in the formatting object tree prior to
the insertion of the new formatting objects.
Note:
Satisfying this constraint may require
splitting one or more existing
formatting objects in the formatting object tree each into a pair of
formatting objects each of which has the same set of computed property
values as the original, unsplit formatting object. One of the pair
would be ended before the start of
or start after the end
of
and the other would start after the start of
or would end before the end of
respectively. The created pairs must continue to nest properly to
satisfy this constraint. For example, assume Left-to-right text is
represented by the character "L" and Right-to-left text is represented by "R".

In the sub-tree

LL
LLLRRR
RR

assuming a paragraph embedding level of "0", the resolved embedding
levels would require the following (inserted and replicated) structure:

LL
LLL

RRR
RR


Note that the fo:inline with id equal to "A" has been split into two
fo:inlines, with only the first one retaining the original id of "A". Since id's
must be unique within the formatting object tree, the computed value of
any id must not be replicated in the second member of the pair.
No fewer fo:bidi-override formatting objects can be inserted and still
satisfy the above constraints. That is, add to the refined formatting
object tree only as many fo:bidi-override formatting objects, beyond the
formatting objects created during tree construction, as are needed to
represent the embedding levels present in the document.
5.9 Expressions
All property value specifications in attributes within an XSL stylesheet can be expressions. These expressions represent the value of the property specified. The expression is first evaluated and then the resultant value is used to determine the value of the property.
Note:
The expression language supports operations on a limited set of
datatypes. These do not include , , and .
Values of these datatypes must be strings in the expression language.
The definition of these datatypes specify the allowed form
of these strings.
5.9.1 Property Context
Properties are evaluated against a property-specific context. This context provides:
A list of allowed resultant types for a property value.
Conversions from resultant expression value types to an allowed type for the property.
The current font-size value.
Conversions from relative numerics by type to absolute numerics within additive expressions.
Note:
It is not necessary that a conversion be provided for all types. If no conversion is specified, it is an error.
When a type instance (e.g., a string, a keyword, a
numeric, etc.) is recognized in the expression it is evaluated against
the property context. This provides the ability for specific values to be
converted with the property context's specific algorithms or conversions
for use in the evaluation of the expression as a whole.
For example, the "auto" enumeration token for certain
properties is a calculated value. Such a token would be converted
into a specific type instance via an algorithm specified in the property definition.
In such a case the resulting value might be an absolute length specifying the width
of some aspect of the formatting object.
In addition, this allows certain types like relative numerics to be
resolved into absolute numerics prior to mathematical
operations.
All property contexts allow conversions as specified in
5.9.12 Expression Value Conversions
5.9.2 Evaluation Order
When a set of properties is being evaluated for a
specific formatting object in the formatting object tree
there is a specific order in which properties must be evaluated.
Essentially, the "font-size" property must be evaluated first before
all other properties. Once the "font-size" property has been evaluated,
all other properties may be evaluated in any order.
When the "font-size" property is evaluated, the current
font-size for use in evaluation is the font-size of the parent element.
Once the "font-size" property has been evaluated,
that value is used as the
current font-size for all property contexts of all properties value expressions
being further evaluated.
5.9.3 Basics
[1]
Expr
::=
AdditiveExpr
[2]
PrimaryExpr
::=
'('
Expr
')'
Numeric
Literal
Color
Keyword
EnumerationToken
FunctionCall
5.9.4 Function Calls
[3]
FunctionCall
::=
FunctionName
'(' (
Argument
( ','
Argument
)*)? ')'
[4]
Argument
::=
Expr
5.9.5 Numerics
A numeric represents all the types of numbers in an XSL expression.
Some of these numbers are absolute values. Others are
relative to some other set of values. All of these values use a floating-point number to represent the number-part of their definition.
A floating-point number can have any
double-precision 64-bit format IEEE 754 value
[IEEE 754]
These include a special "Not-a-Number" (NaN) value,
positive and negative infinity, and positive and negative zero. See
Section 4.2.3
of
[JLS]
for a summary of the key
rules of the IEEE 754 standard.
[5]
Numeric
::=
AbsoluteNumeric
RelativeNumeric
[6]
AbsoluteNumeric
::=
AbsoluteLength
[7]
AbsoluteLength
::=
Number
AbsoluteUnitName
[8]
RelativeNumeric
::=
Percent
RelativeLength
[9]
Percent
::=
Number
'%'
[10]
RelativeLength
::=
Number
RelativeUnitName
The following operators may be used with numerics:
Performs addition.
Performs subtraction or negation.
Performs multiplication.
div
Performs floating-point division according to IEEE 754.
mod
Returns the remainder from a truncating division.
Note:
Since XML allows
in names, the
operator (when not used as a UnaryExpr negation) typically needs to be
preceded by white space. For example the expression
10pt - 2pt
means subtract 2 points from 10 points. The expression
10pt-2pt
would mean a length value of 10 with a unit of "pt-2pt".
Note:
The following are examples of the
mod
operator:
5 mod 2
returns
5 mod -2
returns
-5 mod 2
returns
-1
-5 mod -2
returns
-1
Note:
The
mod
operator is the same as the
operator in Java and
ECMAScript and is not the same as the IEEE remainder operation, which
returns the remainder from a rounding division.
Numeric Expressions
[11]
AdditiveExpr
::=
MultiplicativeExpr
AdditiveExpr
'+'
MultiplicativeExpr
AdditiveExpr
'-'
MultiplicativeExpr
[12]
MultiplicativeExpr
::=
UnaryExpr
MultiplicativeExpr
MultiplyOperator
UnaryExpr
MultiplicativeExpr
'div'
UnaryExpr
MultiplicativeExpr
'mod'
UnaryExpr
[13]
UnaryExpr
::=
PrimaryExpr
| '-'
UnaryExpr
Note:
The effect of this grammar is that the order of precedence is (lowest precedence first):
+, -
*, div, mod
and the operators are all left associative. For example, 2*3 + 4 div 5 is equivalent to (2*3) + (4 div 5).
If a non-numeric value is used in an
AdditiveExpr
and there is no property context conversion from that type into an absolute numeric value, the expression is invalid and considered an error.
5.9.6 Absolute Numerics
An absolute numeric is an absolute length which is a pair consisting of a
Number
and a
UnitName
raised to a power. When an absolute length is written without a unit, the unit power is assumed to be zero. Hence, all floating point numbers are a length with a power of zero.
Each unit name has associated with it an internal ratio to some common
internal unit of measure (e.g., a meter). When a value is
written in a
property expression, it is first converted to the internal unit of measure
and then mathematical operations are performed.
In
addition, only the mod,
addition, and subtraction operators require that the numerics on
either side of the operation be absolute numerics of the same unit power.
For other operations, the unit powers may be different and the result
should be mathematically consistent as with the handling of powers in algebra.
A property definition may constrain an absolute length to a
particular power.
For example, when specifying font-size, the value is expected to be of
power "one".
That is, it is expected to have a single powered unit specified (e.g., 10pt).
When the final value of a property is calculated, the resulting power of the
absolute numeric must be either zero or one. If any other power is specified,
the value is an error.
5.9.7 Relative Numerics
Relative lengths are values that are
calculated relative to some other set of values. When written as part of an
expression, they are either converted via the property
context into an absolute numeric or passed verbatim as the property value.
It is an error if the property context has no available conversion
for the relative numeric and a conversion is required for expression
evaluation (e.g., within an add operation).
5.9.7.1 Percents
Percentages are values that are counted in 1/100 units. That is,
10%
as a percentage value is
0.10
as a floating point number.
When converting to an absolute numeric, the percentage is defined in the
property definition as being a percentage of some known
property value. If the percentage evaluates to
"auto" the complete expression evaluates to "auto".
For example, a value of "110%" on a "font-size"
property
would be evaluated to mean 1.1 times the current font size.
Such a definition of the allowed conversion for percentages is specified on
the property definition. If no conversion is specified, the resulting value
is a percentage.
5.9.7.2 Relative Lengths
A relative length is a unit-based value that is measured against the
current value of the
font-size
property.
There is only one relative unit of measure, the "em". The
definition of "1em" is equal to the current font size. For
example, a value of "1.25em" is 1.25 times the current font
size.
When an em measurement is used in an expression, it is converted according
to the font-size value of the current property's context.
The result of the expression is an absolute length.
See
7.9.4 font-size
5.9.8 Strings
Strings are represented either as
literals
or
as an
enumeration token
All properties contexts allow conversion from enumeration tokens to strings.
See
5.9.12 Expression Value Conversions
5.9.9 Colors
A color is a set of values used to identify a particular color from a color space.
Only RGB
[sRGB]
(Red, Green, Blue)
and ICC (International Color Consortium)
[ICC]
colors are included in this Recommendation.
RGB colors are directly represented in the expression language using a
hexadecimal notation. ICC colors can be specified through an rgb-icc
function.
Colors can also be specified through the system-color
function or through conversion from an
EnumerationToken
via the property context.
5.9.10 Keywords
Keywords are special tokens in the grammar that provide access to
calculated values or other property values.
The allowed keywords are defined in the following subsections.
5.9.10.1 inherit
The property takes the same
computed
value as the property
for the formatting object's parent object.
Note:
"inherit" is not allowed as an expression mixed with operations.
The same functionality is provided by the from-parent() function, which
can be mixed with operations.
5.9.11 Lexical Structure
When processing an expression,
white space (
ExprWhitespace
) may be
allowed before or after any expression token even though it is not
explicitly defined as such in the grammar. In some cases, white space
is necessary to make tokens in the grammar lexically distinct.
Essentially, white space should be treated as if it does not exist
after tokenization of the expression has occurred.
The following special tokenization rules must be applied in the
order specified to disambiguate the grammar:
If the character following an
NCName
(possibly after intervening
ExprWhitespace
) is
",
then the token must be recognized as
FunctionName
A number terminates at the first occurrence of a non-digit character other
than "
". This allows the unit token for
length quantities to parse properly.
When an
NCName
immediately follows a
Number
, it should be recognized as a
UnitName
or it is an error.
The
Keyword
values take precedence over
EnumerationToken
If a
NCName
follows a
numeric
it should be recognized as an
OperatorName
or it is an error.
Expression Lexical Structure
[14]
ExprToken
::=
'(' | ')' | '%'
Operator
FunctionName
EnumerationToken
Number
[15]
Number
::=
FloatingPointNumber
[16]
FloatingPointNumber
::=
Digits
('.'
Digits
?)?
| '.'
Digits
[17]
Digits
::=
[0-9]+
[18]
Color
::=
'#'
AlphaOrDigits
[19]
AlphaOrDigits
::=
[a-fA-F0-9]+
[20]
Literal
::=
'"' [^"]* '"'
| "'" [^']* "'"
[21]
Operator
::=
OperatorName
MultiplyOperator
| '+' | '-'
[22]
OperatorName
::=
'mod' | 'div'
[23]
MultiplyOperator
::=
'*'
[24]
Keyword
::=
'inherit'
[25]
FunctionName
::=
NCName
[26]
EnumerationToken
::=
NCName
[27]
AbsoluteUnitName
::=
'cm' | 'mm' | 'in' | 'pt' | 'pc' | 'px'
[28]
RelativeUnitName
::=
'em'
[29]
ExprWhitespace
::=
5.9.12 Expression Value Conversions
Values that are the result of an expression evaluation may be converted
into property value types. In some instances this is a simple verification
of set membership (e.g., is the value a legal country code). In other cases,
the value is expected to be a simple type like an integer and must be converted.
It is not necessary that all types be allowed to be converted. If the
expression value cannot be converted to the necessary type for the property value,
it is an error.
The following table indicates what conversions are allowed.
Type
Allowed Conversions
Constraints
NCName
Color, via the system-color() function.
Enumeration value, as defined in the property definition.
To a string literal
The value may be checked against
a legal set of values depending on the property.
AbsoluteNumeric
Integer, via the round() function.
Color, as an RGB color value.
If converting to an RGB color value, it must be a legal color value from the color
space.
RelativeLength
To an AbsoluteLength
The specific conversion to be applied is property specific and can be
found in the definition of each property.
Note:
Conversions of compound property values are not allowed; thus
for example,
space-before.optimum="inherited-property-value(space-before)" is invalid.
Permitted are, for example,
space-before="inherited-property-value(space-before)" and
space-before.optimum="inherited-property-value(space-before.optimum)"
since they do not require conversion.
5.9.13 Definitions of Units of Measure
The units of measure in this Recommendation have the following definitions:
Name
Definition
cm
See
[ISO31]
mm
See
[ISO31]
in
2.54cm
pt
1/72in
pc
12pt
px
See
5.9.13.1 Pixels
em
See
5.9.7.2 Relative Lengths
5.9.13.1 Pixels
XSL interprets a 'px' unit to be a request for the formatter to choose a
device-dependent measurement that approximates viewing one pixel on a
typical computer monitor. This interpretation is follows:
The preferred definition of one 'px' is:
The actual distance covered by the largest integer number of
device dots (the size of a device dot is measured as the distance
between dot centers) that spans a distance less-than-or-equal-to
the distance specified by the arc-span rule in
or superceding errata.
A minimum of the size of 1 device dot should be used.
This calculation is done separately in each axis,
and may have a different value in each axis.
However, implementors may instead simply pick a fixed conversion
factor, treating 'px' as an absolute unit of measurement (such as
1/92" or 1/72").
Note:
Pixels should not be mixed with other absolute units in
expressions as they may cause undesirable effects.
Also, particular caution should be used with inherited property values
that may have been specified using pixels.
If the User Agent chooses a measurement for a 'px' that
does not match an integer number of device dots in each axis it may
produce undesirable effects, such as:
moiré patterns in scaled raster graphics
unrenderable overlapping areas when the renderer rounds fonts
or graphics sizes upward to its actual dot-size
large spaces between areas when the renderer rounds fonts or
graphics sizes downward to its actual dot-size
unreadable results including unacceptably small text/layout
(for example, a layout was calculated at 72 dpi [dots per inch], but
the renderer assumed the result was already specified in device
dots and rendered it at 600 dpi).
Stylesheet authors should understand a pixel's actual size may
vary from device to device:
stylesheets utilizing 'px' units may not produce consistent
results across different implementations or different
output devices from a single implementation
even if stylesheets are expressed entirely in 'px' units
the results may vary on different devices
5.10 Core Function Library
5.10.1 Number Functions
numeric
floor
numeric
The
floor
function returns the largest (closest to
positive infinity) integer that is not greater than the argument.
The numeric argument to this function must be of unit power zero.
Note:
If it is necessary to use the
floor
function for a
property where a unit power of one is expected, then an expression
such as: "floor(1.4in div 1.0in)*1.0in" must be used.
This also applies to the ceiling,
round, and other such functions where a unit power of zero is required.
numeric
ceiling
numeric
The
ceiling
function returns the smallest (closest
to negative infinity) integer that is not less than the argument. The numeric
argument to this function must be of unit power zero.
numeric
round
numeric
The
round
function returns the integer that is
closest to the argument. If there are two such
numbers, then the one that is closest to positive infinity is
returned. The numeric argument to this function must be of unit power zero.
numeric
min
numeric
numeric
The
min
function returns the minimum of the
two numeric arguments. These arguments must have the same unit power.
numeric
max
numeric
numeric
The
max
function returns the maximum of the two
numeric arguments. These arguments must have the same unit power.
numeric
abs
numeric
The
abs
function
returns the absolute value of the numeric argument.
That is, if the numeric argument is negative, it returns the negation of
the argument.
5.10.2 Color Functions
color
rgb
numeric
numeric
numeric
The
rgb
function returns a specific color from the RGB
color space. The parameters to this function must be numerics (real numbers) with a
length power of zero.
color
rgb-icc
numeric
numeric
numeric
NCName
numeric
numeric
The
rgb-icc
function
returns a specific color from the ICC Color Profile. The color profile is specified by the name parameter (the fourth parameter). This color profile must have been declared in the fo:declarations formatting object using an fo:color-profile formatting object.
The first three parameters specify a fallback color from the sRGB color space. This color is used when the color profile is not available.
The color is specified by a sequence of one or more color values (real numbers) specified after the name parameter. These values are specific to the color profile.
color
system-color
NCName
The
system-color
function returns a system defined
color with a given name.
5.10.3 Font Functions
object
system-font
NCName
NCName
?)
The
system-font
function returns a
characteristic of a system font. The first argument is the
name of the system font and the second argument, which is optional,
names the property that specifies the characteristic. If the second
argument is omitted, then the characteristic returned is the same as
the name of the property to which the expression is being assigned.
For example, the expression
"system-font(heading,font-size)" returns the font-size
characteristic for the system font named "heading". This is equivalent to the
property assignment
'font-size="system-font(heading)"'.
5.10.4 Property Value Functions
object
inherited-property-value
NCName
?)
The
inherited-property-value
function returns the
inherited value of the property whose name matches the argument specified,
or if omitted for the property for which
the expression is being evaluated.
It is an error if this property is not an inherited property.
If the argument specifies a shorthand property and if the expression
only consists of the inherited-property-value function with an argument
matching the property being computed, it is interpreted as an expansion
of the shorthand with each property into which the shorthand expands,
each having a value of inherited-property-value with an argument
matching the property. It is an error if arguments matching
a shorthand property are used in any other way. Similarly,
if the argument
specifies a property of a compound datatype and if the expression
only consists of the inherited-property-value function with
an argument matching the property being computed,
it is interpreted as an expansion with each component of the
compound property having a value of inherited-property-value
with an argument matching the component. It is an error if
arguments matching a property of a compound datatype are used
in any other way.
The returned "inherited value" is
the computed value
of this property on this object's parent. For example,
given the following:

...







The background-color property on the fo:block is assigned
the value "red" because the (computed, after inheritance)
value of the color (not background-color) property on the
fo:list-item-body that is the parent of the fo:block is "red".
numeric
label-end
()
The
label-end
function returns the calculated
label-end value for lists. See the definition in
7.30.11 provisional-label-separation
numeric
body-start
()
The
body-start
function returns the
calculated body-start value for lists.
See the definition in
7.30.12 provisional-distance-between-starts
object
from-parent
NCName
?)
The
from-parent
function
returns a computed value (see
5.1 Specified, Computed, and Actual Values, and Inheritance
of the property whose name matches
the argument specified,
or if omitted for the property for which
the expression is being evaluated.
The value returned is that for the parent of the
formatting object for which the expression is evaluated.
If there is no parent, the value returned is the initial
value. If the argument specifies a shorthand property and if
the expression only consists of the from-parent function with an
argument matching the property being computed, it is
interpreted
as an expansion of the shorthand with each property into which
the shorthand expands, each having a value of from-parent with
an argument matching the property.
It is an error if arguments matching a shorthand property are used
in any other way.
Similarly, if the argument specifies a property of a compound datatype
and if the expression only consists of the from-parent function with
an argument matching the property being computed, it is interpreted
as an expansion with each component of the compound property having
a value of from-parent with an argument matching the component.
It is an error if arguments matching a property of a compound datatype
are used in any other way.
object
from-nearest-specified-value
NCName
?)
The
from-nearest-specified-value
function
returns a computed value of the property whose name matches
the argument specified,
or if omitted for the property for which
the expression is being evaluated.
The value returned is that for the closest ancestor of the
formatting object for which the expression is evaluated on
which there
is an assignment of the property in the XML result tree in the
fo namespace.
If there is no such ancestor, the value returned is the
initial value.
If the argument specifies a shorthand property and if
the expression only consists of the from-nearest-specified-value function with an
argument matching the property being computed, it is
interpreted
as an expansion of the shorthand with each property into which
the shorthand expands, each having a value of from-nearest-specified-value with
an argument matching the property.
It is an error if arguments matching a shorthand property are used
in any other way.
Similarly, if the argument specifies a property of
a compound datatype and if the expression only consists of
the from-nearest-specified-value function with an argument matching
the property being computed, it is interpreted as an expansion with
each component of the compound property having a value of
from-nearest-specified-value with an argument matching the component.
It is an error if arguments matching a property of a compound datatype
are used in any other way.
object
from-page-master-region
NCName
?)
The
from-page-master-region
function returns the
computed value of the property whose name matches the argument specified,
or if omitted for the property for which
the expression is being evaluated.
In XSL 1.1 this function may only be used as the value of the
"writing-mode" and "reference-orientation" properties.
In addition the argument of the function
must
be omitted.
If an argument is present, it is an error.
The computed value of the designated
property is taken from that property on the layout formatting object
being used to generate the region viewport/reference area pair.
If this function is used in an expression on a formatting object,
that is a descendant of an fo:page-sequence, then the computed value
is taken from the region specification that was used to generate
the nearest ancestor region reference area which has as
its descendants the areas returned by
If the argument specifies a property of a compound datatype and
if the expression only consists of the inherited-property-value function
with an argument matching the property being computed,
it is interpreted as an expansion with each component of
the compound property having a value of inherited-property-value with
an argument matching the component. It is an error
if arguments matching a property of a compound datatype are used
in any other way.
Note:
Consider the following example:

writing-mode="tb-rl" />

[Content in a language which allows either
horizontal or vertical formatting]

This example shows a very simple page layout specification.
There is a single simple-page-master, named "all-pages".
This page-master has two regions defined upon it, "xsl-region-body"
and "xsl-region-before". The region named "xsl-region-before" is
a page header that accepts static-content (said content is omitted
for simplicity in this example). The region named "xsl-region-body"
is assigned the content of the single fo:flow in the single
fo:page-sequence.
In this example, the definition of "xsl-region-body" has
a "writing-mode" property. As written, the computed value of
this property, "tb-rl", would have no effect on the writing-mode
used to fill the region because the writing-mode value used when
generating the region viewport/reference area pair would be the computed
value on the fo:page-sequence that uses the "xsl-region-body" region definition
to generate a region viewport/reference area pair.
Since no "writing-mode" property is specified on either the fo:root
nor its child, the fo:page-sequence, the initial value would be used
for the writing mode for the content that fills the region reference area.
The initial value of "writing-mode" is "lr-tb".
If, however, the above line that reads:

becomes
writing-mode="from-page-master-region()">
then the computed value of the "writing-mode" property on
the region definitions would be used when instantiating all the
viewport/reference area pairs. Thus for the xsl-region-body the
specification on the region definition for "xsl-region-body"
would be used and
the content would receive vertical formatting instead of
the default horizontal formatting.
Similarly for the xsl-region-before, the computed value of the
"writing-mode"
on the region definition would be used, in this case the
initial value of "lr-tb" inherited from fo:root and the content of the
xsl-region-before would be formatted horizontally.
object
from-table-column
NCName
?)
The
from-table-column
function
returns the inherited value of the property whose name matches the
argument specified,
or if omitted for the property for which
the expression is being evaluated,
from the fo:table-column whose column-number
matches the column for which this expression is evaluated and
whose number-columns-spanned also matches any span.
If there is no match for the number-columns-spanned, it is
matched
against a span of 1. If there is still no match, the initial
value is returned.
If the argument specifies a shorthand property and if the expression
only consists of the from-table-column function with an argument
matching the property being computed, it is interpreted as
an expansion of the shorthand with each property into which
the shorthand expands, each having a value of from-table-column with
an argument matching the property. It is an error if arguments matching
a shorthand property are used in any other way. Similarly,
if the argument specifies a
property of a compound datatype and if the expression only consists of
the from-table-column function with an argument matching
the property being computed, it is interpreted as an expansion
with each component of the compound property having a value of
from-table-column with an argument matching the component.
It is an error if arguments matching a property of a compound datatype
are used in any other way.
It is also an error to use this function on formatting objects
that are not an fo:table-cell or its descendants.
numeric
proportional-column-width
numeric
The
proportional-column-width
function
returns
units of proportional measure
where
is the argument given to this function.
The column widths are first determined ignoring the proportional
measures. The difference between the table-width and the sum of
the column widths is the available proportional width. One unit
of proportional measure is the available proportional width
divided by the sum of the proportional factors.
It is an error to use this function on formatting objects other
than an fo:table-column. It is also an error to use this function
if the fixed table layout is not used.
object
merge-property-values
NCName
?)
The
merge-property-values
function returns a value of the
property whose name matches the argument,
or if omitted for the property for which
the expression is being evaluated.
The value returned is the specified value on the last
fo:multi-property-set, of the parent fo:multi-properties,
that applies to the User Agent state.
If there is no such value, the computed value of the
parent fo:multi-properties is returned.
If the argument specifies a shorthand property and if the expression
only consists of the merge-property-values function with an argument
matching the property being computed, it is interpreted as an expansion
of the shorthand with each property into which the shorthand expands,
each having a value of merge-property-values with an argument matching
the property. It is an error if arguments matching a shorthand property
are used in any other way. Similarly, if the argument
specifies a property of a compound datatype and if the expression
only consists of the merge-property-values function with an argument
matching the property being computed, it is interpreted as
an expansion with each component of the compound property having a
value of merge-property-values with an argument matching the component.
It is an error if arguments matching a property of a compound datatype
are used in any other way.
Note:
The test for applicability of a User Agent state is
specified using the "active-state" property.
It is an error to use this function on formatting objects other
than an fo:wrapper that is the child of an fo:multi-properties.
5.11 Property Datatypes
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 "space-before" property may
be specified as:
space-before.minimum="2.0pt"
space-before.optimum="3.0pt"
space-before.maximum="4.0pt"
space-before.precedence="0"
space-before.conditionality="discard"
A short form of compound value specification may be used, in cases
where the datatype has some components and for the
datatype. In the first case the
specification consists of giving a value to an attribute
with a name matching a property name. Such a specification gives
that value to each of the components and the initial value
to all the non- components. For example:
space-before="4.0pt"
is equivalent to a specification of
space-before.minimum="4.0pt"
space-before.optimum="4.0pt"
space-before.maximum="4.0pt"
space-before.precedence="0"
space-before.conditionality="discard"
Note:
Since a value,
that is not interpreted as "auto",
is a valid value it may be used in a short form.
For the datatype the
specification consists of giving a value that is valid for a component
to an attribute
with a name matching a property name. Such a specification gives
that value to each of the components.
For example:
keep-together="always"
is equivalent to a specification of
keep-together.within-line="always"
keep-together.within-column="always"
keep-together.within-page="always"
Short forms may be used together with complete forms; the complete
forms have precedence over the expansion of a short form.
For example:
space-before="4.0pt"
space-before.maximum="6.0pt"
is equivalent to a specification of
space-before.minimum="4.0pt"
space-before.optimum="4.0pt"
space-before.maximum="6.0pt"
space-before.precedence="0"
space-before.conditionality="discard"
Compound values of properties are inherited as a unit and not
as individual components.
After inheritance any complete form specification
for a component is used to set its value.
If the computed value of a corresponding relative property is
set from the corresponding absolute property, the latter is used
in determining all the components of the former.
Note:
For example, assuming a block-progression-direction of
"top-to-bottom", in a specification of
margin-top="10.0pt"
space-before.minimum="4.0pt"
the explicit setting of one of the components of the corresponding
relative property will have no effect.
The following defines the syntax for specifying the
datatypes usable in property values:

A signed integer value which consists of an optional '+' or '-'
character followed by a sequence of digits.
A property may define additional constraints on the value.
Note:
A '+' sign is allowed for CSS2 compatibility.

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.
A property may define additional constraints on the value.

A signed length value where a 'length' is a real number plus a unit
qualification.
A property may define additional constraints on the value.

A compound datatype, with components:
minimum, optimum, maximum. Each component is a .
If "minimum" is greater than optimum, it will be treated as if it had
been set to "optimum".
If "maximum" is less than optimum, it will be treated as if it had
been set to "optimum".
A property may define additional constraints on the values,
and additional permitted values and their semantics; e.g. 'auto'
or .

A compound datatype, with components:
length, conditionality. The length component is a .
The conditionality component is either "discard" or "retain".
A property may define additional constraints on the values.

A compound datatype, with components:
block-progression-direction, and inline-progression-direction.
Each component is a .
A property may define additional constraints on the values.

A compound datatype, with components:
minimum, optimum, maximum, precedence, and conditionality.
The minimum, optimum, and maximum components are s.
The precedence component is either "force" or an .
The conditionality component is either "discard" or "retain".
If "minimum" is greater than optimum, it will be treated as if it had
been set to "optimum".
If "maximum" is less than optimum, it will be treated as if it had
been set to "optimum".

A compound datatype, with components:
within-line, within-column, and within-page. The value of each
component is either "auto", "always", or an .

A representation of an angle consisting of
an optional '+' or '-' character immediately followed by
a immediately followed by an angle unit identifier.
Angle unit identifiers are:
'deg' (for degrees),
'grad' (for grads), and
'rad' (for radians).
The specified values are normalized to the range 0deg to 360deg.
A property may define additional constraints on the value.

A signed real percentage which consists of an optional '+' or '-'
character followed by a sequence of digits followed by an optional '.'
character and sequence of digits followed by '%'.
A property may define additional constraints on the value.

A single Unicode character
valid in accordance with production [2] of
[XML]
or
[XML 1.1]
For example, "c" or "∂".

A sequence of characters.
Note:
Given the allowable Expression Value Conversions
5.9.12 Expression Value Conversions
),
a property value of type must be a quoted value,
an NCName, or a expression that evaluates to a ;
anything else (e.g., an integer) is an error.
An implementation may recover from this error by treating the
unevaluated property value as a string.

A string of characters representing a name.
It must conform to the definition of an
NCName
in
[XML Names]
or
[XML Names 1.1]

A string of characters identifying a font.

Either a string of characters representing a keyword or a color
function defined in
5.10.2 Color Functions
The list of keyword color names is:
aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive,
purple, red, silver, teal, white, and yellow.

A string of characters conforming to an ISO 3166
[ISO3166-1]
[ISO3166-2]
, and
[ISO3166-3]
country code.

A string of characters conforming to either a
[ISO639-2]
3-letter terminology
or bibliographic code
or a
[ISO639]
2-letter code
representing the name of a language.