Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The Extensible Stylesheet Language (XSL) has two parts:
a language for transforming XML documents (XSLT), and
an XML vocabulary for specifying formatting semantics (XSL-FO).
This document describes features and changes introduced for version 2.0 of the XSL-FO part of XSL.
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 http://www.w3.org/TR/.
This document is a Working-Group Draft containing proposals for an eventual XSL-FO 2.0 Recommendation. Public feedback is solicited. The Working Group (actually the Formatting Objects Subgroup) is short of resources, and would be interested in organizations or individuals in a position to help us work on the Specification.
Comments on this document should be made using bugzilla, at bugzilla; comments can also be sent by email to xsl-editors@w3.org (see the public archive), and members of the XSL-FO Task Force will enter them into bugzilla; see www.w3.org/XML/2008/xsl-fo-bugzilla.html for instructions on using bugzilla to report issues.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced as part of the W3C XML Activity by the XSL Working Group.
General public discussion of XSL takes place on the XSL-List and on the www-xsl-fo@w3.org mailing lists; the www-xsl-fo list is probaby most appropriate for general questions about the 2.0 work.
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.
1 Introduction and Overview
2 Pagination and Layout
2.1 Non-rectangular areas
2.1.1 fo:page-master
2.1.2 fo:shape
2.1.3 fo:region
2.1.4 fo:shape-name-specifier
2.1.5 fo:shape-path-specifier
2.1.6 fo:shape-background-specifier
2.1.7 fo:shape-border-specifier
2.1.8 Common Wrap Properties
2.1.8.1 wrap
2.1.8.2 wrap-path
2.1.8.3 wrap-side
2.2 Copyfitting
2.2.1 Summary
2.2.2 Copyfit: basic approach and definitions
2.2.3 Objects and properties for copyfit
2.2.3.1 copyfit-by-modifying
2.2.3.1.1 Value list simplification
2.2.3.1.2 Priority
2.2.3.2 force-page-count (adding new values)
2.3 Initial Caps
2.3.1 Initial Caps
2.3.1.1 initial-cap-lines
2.3.1.2 initial-cap-lines-before
2.3.1.3 initial-cap-kern-lines
2.3.1.4 initial-cap-indent
2.4 Marginalia
2.4.1 Extension Regions
2.4.1.1 The extension-region-start Region
2.4.1.2 The extension-region-end Region
2.4.1.3 distance
2.4.2 Formatting Objects for Marginalia
2.4.2.1 fo:marginalia
2.4.2.2 fo:marginalia-body
2.4.2.3 marginalia-destination-area
2.4.2.4 marginalia-relative-align
2.5 Vertical Positioning
2.5.1 Feathering
2.5.1.1 justify-by-modifying
2.5.2 Correlating vertical position
2.5.2.1 block-progression-unit
2.5.3 Vertical alignment within a page or column
2.5.4 Vertical alignment specific for the last column
2.5.4.1 display-align-last-column
2.5.5 Vertical justification across pages and columns
3 Tables and Lists
3.1 Decimal Alignment
3.1.1 Considerations
3.2 Table header/footer on boundaries
3.2.1 fo:conditional-table-layout-reference
3.2.2 Split tables
3.2.2.1 table-overflow
3.2.3 Repeat contents of split spanned cell
3.2.4 Cell borders extending beyond the table
3.2.4.1 3.5.1 Considerations
3.2.5 Adjacent borders
3.2.6 Borders on break
3.2.7 Spanning cell over all row and columns
3.3 Layout master set
3.3.1 Interleaving layout-master set
3.3.1.1 Formatting Objects Summary
3.3.1.2 "Declarations and Pagination and Layout Formatting Objects" introduction
3.3.1.3 fo:root
3.3.1.4 fo:page-sequence
3.3.1.5 fo:layout-master-set
3.3.1.6 'master-name'
3.3.1.7 'master-reference'
3.3.1.8 'flow-name'
3.3.1.9 'flow-name-reference'
3.3.1.10 'region-name'
3.3.1.11 'region-name-reference'
3.3.2 Change master every n pages
3.3.2.1 sequence-repeats
3.3.2.2 page-position
3.3.2.3 fo:repeatable-page-master-alternatives
3.3.2.4 fo:conditional-page-master-reference
3.4 Spreads
3.4.1 fo:spread-page-master
3.4.1.1 Would also affect text in:
3.5 Bleeds and Trim
3.5.1 bleed-box, trim-box
4 Composition
4.1 Improved font support
4.2 Force line justification
4.2.1 last-line-minimum-deficit
4.2.2 hyphenation-permitted-minimum-deficit
4.3 Alignment around breaks
4.3.1 text-align-before-break
4.3.2 text-align-after-break
4.4 hanging-punctuation
4.5 Tabs and tab stops
4.5.1 tab-stops
4.5.2 tab-alignment-character
4.6 Word and letter spacing
4.6.1 word-spacing-critical-length
4.7 Hyphenation and line breaking
4.7.1 hyphenation-push-syllable-count
4.7.2 hyphenation-remain-syllable-count
4.7.3 syllable-widows
4.7.4 hyphenation-exceptions
4.7.5 word-widows
4.7.6 min-length-of-last-line
5 Further improved non-Western language support
6 Images
6.1 Images
6.1.1 Rotate an image by arbitrary amounts
6.1.2 Callouts
6.1.3 Multi-page images
7 Color Support
8 Collaboration with SVG
8.1 Masks
8.2 Rotation and Transformations
A Changes since last publication
B References
B.1 Normative References
B.2 Other References
C List of properties (Non-Normative)
D Acknowledgements (Non-Normative)
This document describes initial design notes for version 2.0 of the Formatting Object (FO) part of the Extensible Stylesheet Language (XSL). The final document will be a complete specification, but the early Working Drafts, including this one, give only design notes and discussion of new features and changes.
There are a number of open issues in this document; please let us (the XSL-FO subgroup of the XSL Working Group) know if you have comments on them, using bugzilla: see the Status section at the start of this document for instructions.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.1.1
Add support for non-rectangular areas wherever appropriate. This is for areas where the content needs to be flowed inside an non-rectangular shape.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.1.2
Run text on a path including flowing from one path to another. This goes further than simply including SVG, as we're also supporting the line breaking rules that XSL-FO provides. Text should be able to flow from one line to the next line of the multiline paths but it needs to be explicitly specified what each line of the path is, as we do not intend to stack paths automatically. The intent is to apply the normal line building properties to text on a path.
(This draft does not yet address this requirement)
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.1.2
Add support for runarounds or intrusions (text flowing around illustrations, regions and other objects). This is related to effects obtained by overlapping areas of either rectangular or non-rectangular shape in any suitable combination, but it doesn't really require non-rectangular areas.
Allow one object to intrude into another.
Support intrusions into all 4 sides
Support specifying pull-quotes without the need to repeat the content of the pull-quote. This is related to 2.2.9.4 Generalized markers [and will be addressed in that section]
Support cut-outs
The objects (both the intruder as well as the object intruded upon) may be of arbitrary shape
Allow users to specify the relations between the objects that are impacted by the intrusion
For non-rectangular areas, XSL-FO 2.0 uses shapes expressed in SVG [SVG]. Regions and block containers can have associated shapes.
Intrusions and cut-outs are seen as two ways of looking at one shape affecting another, and are both modeled as intrusions.
Relative priority between shapes is handled using the z-index property.
Common Usage:
The fo:page-master is used in the generation of pages and specifies the geometry of the page. The page may be subdivided into an arbitrary number of regions, each called an fo:region.
Note:
The region has similar behaviour to a region-body, this means that an fo:page-master is formed by an arbitrary number of body-like regions. Regions are positioned absoulutely into the page and have a concept of z-index.
Areas:
The fo:page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence.
When the fo:page-master is used to generate a page, a viewport/reference pair is generated, consisting of a page-viewport-area and a page-reference-area. The page-viewport-area represents the physical bounds of the output medium. The page-reference-area represents the portion of the page on which content is intended to appear; that is, the area inside the page margins.
In addition, when the fo:page-master is used to generate a page, viewport/reference pairs that correspond to the regions that are the children of the fo:page-master are also generated.
Figure 1. The z-index property. A large shape called Region A is filled with text, and has z-index of zero. A smaller shape, called region B, wholly contained within region A, also contains text (coloured red). Region B has a z-index of 1, so that the text in region A is pushed away from it. If both regions had the same z-index, the text would ovelap.
Trait Derivation:
Same as fo:simple-page-master
Constraints:
Same as fo:simple-page-master
Contents:
(region)+
The following properties apply to this formatting object:
[7.10 Common Margin Properties-Block]
[7.xx.1 "bleed-box"]
[7.25.8 "master-name"]
[7.25.13 "page-height"]
[7.25.15 "page-width"]
[7.20.3 "reference-orientation"]
[7.xx.2 "trim-box"]
[7.27.7 "writing-mode"]
Common Usage:
Used in constructing a shape outline. This object defines a shape using a child from a SVG Documents to describe the region's shape. The permitted structure of this child is that defined for that namespace.
The definition of the shape using the fo:shape permits the shape re-use among different regions similarly to the concept of page-masters.
The fo:shape may define background, border and padding properties. These are applied to the SVG shape's path. In the case the SVG shape already defines a border (using the stroke attribute) and/or a background (using a fill attribute) the fo properties are overimposed to the SVG document.
Contents:
The fo:shape object has a child from an SVG Document to describe a region's shape. The permitted structure of this child is that defined by SVG [SVG].
Example 1: Path based shape
<fo:shape shape-name="trapezoid"> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <svg:path d="M ... z " /> </svg:svg> </fo:shape> <fo:shape shape-name="free-hand"> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <svg:path d="M ... z" /> </svg:svg> </fo:shape>
Example 2: Showing border, padding and background.
<fo:shape shape-name="circle" border-width="2pt" border-color="black" padding-width="10pt"> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <circle cx="250" cy="250" r="200"/> </svg:svg>> </fo:shape>
Figure 2. The bounding box of a shaped region (here specified as a circle) is the smallest rectangle that completely contains the shape, and is here called the region bounding-box. The border and padding follow the outline of the shape itself.
The following properties apply to this formatting object:
[7.10 Common Margin Properties-Block]
[7.xx.1 "bleed-box"]
[7.25.8 "master-name"]
[7.25.13 "page-height"]
[7.25.15 "page-width"]
[7.20.3 "reference-orientation"]
[7.xx.2 "trim-box"]
[7.27.7 "writing-mode"]
Common Usage:
Used in constructing a page-master, the behavior of each fo:region is similar to the behavior of fo:region-body of XSL-FO 1.1. A region specifies a viewport/reference pair that is located in an absoulte position within the fo:page-master. The "overflow"trait controls how much of the underlying region-reference-area is visible; that is, whether the region-reference-area is clipped by its parent region-viewport-area.
Note:
Typically, for paged media, the areas returned by the fo:flow formatting object in a fo:page-sequence are made to be descendants of a sequence of region-reference-areas that correspond to region-bodies. These region-reference-areas are all area descendants of page-areas for which the page-master included an fo:region-body. If the fo:flow flow is assigned to some other region, then the areas returned by the fo:flow are constrained to be descendants of region-reference-areas generated using the assigned region-master.
The fo:region may be also be used to provide multiple columns. When the column-count trait is greater than one, then the region will be subdivided into multiple columns.
Note:
We need to say more about how this works, or to give a reference
Areas:
Same as fo:region-body
Trait Derivation:
Same as fo:region-body
Constraints:
Same as fo:region-body
Contents:
(shape-name-specifier, shape-path-specifier?, shape-background-specifier*, shape-border-specifier*)
Example
<fo:page-master master-name="only" page-height="11in" page-width="8.5in" margin-top="3pt" margin-bottom="3pt" margin-left="3pt" margin-right="3pt"> <fo:region absolute-position="absolute" top="0.8636in" left="1.125in" width="6.75in" height="7.75in" region-name="region_A" z-index="0" wrap="shape" wrap-sides="both" wrap-path="shape"> ... shape reference specifier(s) ... </fo:region> <fo:region absolute-position="absolute" top="1.3in" left="1.4in" width="3.6in" height="5.4in" region-name="region_B" z-index="1"> ... shape reference specifier(s) ... </fo:region> </fo:page-master>
The following properties apply to this formatting object:
[7.5 Common Absolute Position Properties]
[7.7 Common Border, Padding, and Background Properties]
[7.10 Common Margin Properties-Block]
[7.1x Common Wrap Properties]
[7.20.1 "clip"]
[7.25.2 "column-count"]
[7.25.3 "column-gap"]
[7.13.4 "display-align"]
[ 7.15.6 "height"]
[7.20.2 "overflow"]
[7.25.17 "region-name"]
[7.20.3 "reference-orientation"]
[7.15.14 "width"]
[7.27.7 "writing-mode"]
[7.28.9 "z-index"]
The shape assignment model allows a region to point to one or more regions that are used to define:
content path: where the region's content is bound to wrap
wrapping path: where the region's intruded content is bound to wrap around
border: one or more shapes used to define a border that is beyond standard FO border capabilities or it is designed ad-hoc
background: one or more shapes used to define a background effect that is beyond standard FO background capabilities
Note:
This draft does not yet cover the interactions between non-rectangular shapes and footnotes.
Shape assignment model illustration
Example 3. Full Shape and Region use and re-use.
<fo:layout-master-set> <fo:shape shape-name="hexagon"> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <svg:path d="M ... z " /> </svg:svg> </fo:shape> <fo:shape shape-name="intruder-bag"> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <svg:path d="M ... z " /> </svg:svg> </fo:shape> <fo:shape shape-name="border-bag"> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <svg:path d="M ... z " /> </svg:svg>> </fo:shape> <fo:shape shape-name="bag"> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <svg:path d="M ... z " /> </svg:svg> </fo:shape> <fo:page-master master-name="only" page-height="11in" page-width="8.5in" margin-top="3pt" margin-bottom="3pt" margin-left="3pt" margin-right="3pt"> <fo:region absolute-position="absolute" top="0.8636in" left="1.125in" width="10in" height="12in" region-name="region_A" z-index="0"> <fo:shape-name-specifier shape-name-reference="bag" width="100%" height="100%" display-align="center" /> <fo:shape-path-specifier shape-name-reference="intruder-bag" width="100%" height="100%" display-align="center" /> <fo:shape-border-specifier shape-name-reference="border-bag" width="100%" height="100%" display-align="center" /> <fo:fo:shape-background-specifier shape-name-reference="hexagon" width="80%" height="80%" relative-position="relative" top="6in" left="6in" /> <fo:fo:shape-background-specifier shape-name-reference="hexagon" width="60%" height="60%" relative-position="relative" top="4in" left="4in" /> <fo:fo:shape-background-specifier shape-name-reference="hexagon" width="40%" height="40%" relative-position="relative" top="2in" left="2in" /> <fo:fo:shape-background-specifier shape-name-reference="hexagon" width="20%" height="20%" relative-position="relative" top="1in" left="1in" /> </fo:region> </fo:page-master> </fo:layout-master-set>
Common Usage:
The fo:shape-name-specifier is used to specify the shape indicating where flow is wrapped around.
@@ please translate the previous sentence into English
Contents
EMPTY
The following properties apply to this formatting object:
[shape-name-reference similar to flow-name-reference]
[7.13 Common Relative Position Properties]
[7.13.4 "display-align"]
[ 7.15.6 "height"]
[7.15.14 "width"]
Common Usage:
The fo:shape-path-specifier is used to specify the intrusion path created from this region when intruding other regions.
Contents
EMPTY
The following properties apply to this formatting object:
[shape-name-reference similar to flow-name-reference]
[7.13 Common Relative Position Properties]
[7.13.4 "display-align"]
[ 7.15.6 "height"]
[7.15.14 "width"]
Common Usage:
The fo:shape-background-specifier is used to specify the backround shape design.
Contents:
EMPTY
The following properties apply to this formatting object:
[shape-name-reference similar to flow-name-reference]
[7.13 Common Relative Position Properties]
[7.13.4 "display-align"]
[ 7.15.6 "height"]
[7.15.14 "width"]
Common Usage:
The fo:shape-border-specifier is used to specify the backround shape design.
Contents:
EMPTY
The following properties apply to this formatting object:
[shape-name-reference similar to flow-name-reference]
[7.13 Common Relative Position Properties]
[7.13.4 "display-align"]
[ 7.15.6 "height"]
[7.15.14 "width"]
The common wrap properties are used to express the runaround interaction between regions. Regions interact based on their z-index values. Regions with higher z-index are considered overlapping regions with lower z-index.
wrap
XSL Definition:
Value: | skip | path | none |
---|---|
Initial: | skip |
Percentages: | N/A |
Applies to: | fo:region @@? |
Inherited: | no |
Media: | visual |
Use the "wrap" property to specify flow run-around.
Values have the following meanings:
The content in the flow will skip the entire intrusion area continuing from the first available un-intruded allocation area
The runaround contour is determined following the wrap-path property strategy
This is the default behavior. No runaround is applied. If regions are overlapping their content will overlap.
Open issue: 8858
do we have the right default here? Maybe it should be wrap=wrap-path, defaulting to bounding-box, or maybe it should be skip.
Open issue: 8859
this also needs to relate to floats: we have basically defined a sort of centre float here. Should we allow float: left/right/none to take a percentage too?
wrap-path
XSL Definition:
Value: | shape | bounding-box | auto |
---|---|
Initial: | shape |
Percentages: | N/A |
Applies to: | fo:region @@? |
Inherited: | no |
Media: | visual |
When two or more shaped areas interact, the "wrap-path" property determines how text and other inline objects in one area flow around the shape of the other area.
Values have the following meanings:
This is the default behavior. The path is custom and it is indicated using the shape-path-specifier within the shape-assignment for the region. If there is no shape-map associated with the intruded region the behaviour is defaulted to bounding-box.
The path is determined by the bounding-box of the overlapping region
The path is inferred as follows:
clip-path embedded in the content of the intruding region.
path detection through image color threshold or alpha-channel (transparency) in the content in the intruding region.
If neither of these are available, or the implementation does not support them, the path is defaulted to the bounding-box.
wrap-side
XSL Definition:
Value: | all | start | end | inner | outer | largest | smallest |
---|---|
Initial: | shape |
Percentages: | N/A |
Applies to: | fo:region @@? |
Inherited: | no |
Media: | visual |
The "wrap-side" property indicates what strategy should be applied for the runaround.
Values have the following meanings:
This is the default behavior. Runaround is performed, if possible, on both sides of the intruding area.
The run-around is performed only in the start side of the intruding area.
The runaround is performed only in the end side of the intruding area.
The runaround is performed only in the inner side of the intruded area. The inner side is the side nearer to the spread "spine". The spread spine is considered the contact line between the two pages forming the spread. If the region is not part of a spread the inner property is evaluated as start.
The runaround is performed only in the outer side of the intruded area. The outer side is the side farther from the spread "spine". The spread spine is considered the contact line between the two pages forming the spread. If the region is not part of a spread the outer property is evaluated as end.
The runaround is performed only in the largest area available as result of the intrusion.
The runaround is performed only in the smallest area available as result of the intrusion.
Note:
What about V-shaped or W-shaped intrusions?
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.1.4
Add support for copyfitting, for example to shrink or grow content (change properties of text, line-spacing, ...) to make it constrain to a certain area. This is going to be managed by a defined set of properties, and in the stylesheet it will be possible to define the preference and priority for which properties should be changed. That list of properties that can be used for copyfitting is going to be defined.
Additionally, multiple instances of alternative content can be provided to determine best fit.
This includes copyfitting across a given number of pages, regions, columns etc, for example to constrain the number of pages to 5 pages.
Add the ability to keep consistency in the document, e.g. when a specific area is copyfitted with 10 pt fonts, all other similar text should be the same.
Allowing copyfitting on fo:flow-assignment, fo:region-body and fo:region objects. Future revisions of the specs may include copyfitting for other objects too.
Introducing the concept of “list of prioritized properties to be adjusted for copyfitting”.
Adding a new property "copyfit-by-modifying" that specifies such lists.
Exploiting range values of existing properties to specify how (and how much) each property can be adjusted for copyfitting. Introducing the idea of "elasticity".
Adding new values to the property "force-page-count" to model copyfit into a fixed number of pages or a multiple of a number.
Note:
how to express alternative content: what happens if it is not possible? how to express consistency and relationships among copyfitted areas? how to copyfit irregular shapes?
Many options exist to copyfit content to a certain area. For example, a user could add some space between paragraphs, widen or narrow spaces before and after titles, images and tables, modify the line height of some paragraphs, etc. All these fine tunings, and their multiplicity of combinations, lead to different results, and different users could have different preferences.
In order to give users such control, XSL-FO allows users to express copyfitting strategies through "copyfit properties lists". A copyfit properties list is an ordered sequence of properties names (or group of names) that a formatter is allowed to modify in order to do copyfitting. The order of the names in the list follows the priority rules described below.
Copyfit properties list can be associated to fo:objects by using the property "copyfit-by-modifying"[@@]. The "copyfit-by-modifying" property applies to fo:flow-assignment, fo:region and fo:region-body in this specification. This makes possible to use implicit flow maps and to copyfit a single flow to a single region, multiple flows to a single region or even multiple flows to multiple regions.
If that property is defined on both a fo:flow-assignment and a fo:region-* involved by that assignment, the value is taken from the fo:flow-assignment definition.
Future versions of this specification may add copyfit capabilities to other fo:objects.
Note:
Copyfit capabilites could be useful in other contexts too. For instance, users might be interested in copyfit text into a block-container or into a table cell. The discussion about the scope of copyfitting is still open.
Note:
Copyfit is activated by setting the property "copyfit-by-modifying" of fo:flow-assignment, fo:region or fo:region-body objects. That actually performs two logically separated tasks: the request of copyfitting to a given area and the definition of strategies to copyfit. Copyfitting could have been activated by using other properties too. For instance, by introducing a new boolean property or by extending the values of "display-align". Such a solution is still under investigation. Alternatively, "copyfit-by-modifying" could be said to take effect only if display-align is "copyfit". Some clarification is also needed about the relation between copyfitting and vertical justification, which could be both seen as slightly different instances of the same general concept.
Note:
The property "display-align-last" may also need to be added if copyfitting will be activated with "display-align" (in analogy with text-align and text-align-last). The idea is to have a value "relative" meaning that: if display-align is copyfit, then the alignment of the last page, and of any page ending with a forced break, will be "before", otherwise the value for display-align is used for all pages.
It is important to note that “copyfit-by-modifying” only states the copyfitting strategy, and does not define the actual property ranges the application is allowed to modify. These are instead expressed (as in an XSL-FO 1.1 document) throughout the flow and its descendant formatting objects: this provides a great expressing power in a simple way, as, for example, it allows for different fo:block to have different adjusting properties.
For example: fill-by-modifying=”space-before word-spacing” means that the application is allowed to modify the actual value of the space-before and word-spacing properties. Although the “copyfit-by-modifying” property is defined in the fo:flow-assignment object, the variations are defined in the “space-before” and “word-spacing” properties of the blocks within the actual flow. In most cases values of these properties are actually inherithed. The application should try to copyfit text by choosing appropriate values for the space-before traits (using a value either greater or smaller that the .optimum one but still between the relevant .minimum and .maximum) of each block.
In fact, many FO properties (dating back to the initial XSL-FO specification) can be given a length range value, expressed using a .minimum, .optimum and .maximum components; others (allowed-height-scale, allowed-width-scale) can be given a list of numeric values; font-family can be given a list of values.
A property having a range value can create some elasticity: the dimensions of the areas generated by the affected formatting objects can stretch or shrink from an optimal value. An FO subtree is said to have inline elasticity if there are properties involved in the line building process that have some degree of elasticity; similarly, an FO subtree is said to have block elasticity if there are properties involved in the block stacking process that have some degree of elasticity. It should be noted that a length range in an inline-related property can involve both inline and block elasticity (as, for example, a variation in word-spacing may result in the creation of fewer or more lines), while a range in a block-related property only creates block elasticity.
The presence of some elasticity is the first condition to allow copyfitting. Properties with range or list values, in fact, can be adjusted in order to achieve the expected result.
On the other hand, elasticity does not automatically imply that content will be copyfitted. It may happen that properties listed in “copyfit properties list” do not have elasticity while other do. In that case the formatter cannot copyfit text and should warn the user.
If properties listed in the “copyfit properties list” do have elasiticy but the formatter is not able to copyfit text – because of syntax errors, limitated support of required copyfit strategies, etc. – the formatter should warn the user too.
An example of copyfit declaration and application is shown below:
<fo:flow flow-name="A"> <fo:block word-spacing.minimum=”1pt” word-spacing.maximum=”4pt” line-height.minimum=”8pt” line-height.maximum=”14pt”> In the second century of the Christian Era . . . were guarded by ancient renown and disciplined valor. </fo:block> <fo:block word-spacing.minimum=”1pt” word-spacing.maximum=”4pt” line-height.minimum=”8pt” line-height.maximum=”14pt”>The gentle but powerful. . . . and devolved on the emperors all the executive powers of government. </fo:block> <fo:block word-spacing.minimum=”1pt” word-spacing.maximum=”4pt” line-height.minimum=”8pt” line-height.maximum=”14pt”>During a happy period of more than fourscore years . . . to describe the prosperous condition of their empire; </fo:block> </fo:flow> <fo:flow flow-name="B"> <fo:block word-spacing.minimum=”1pt” word-spacing.maximum=”4pt” line-height.minimum=”8pt” line-height.maximum=”14pt”>Quo usque tandem abutere, . . . nihil hic munitissimus habendi senatus locus, nihil horum ora voltusque moverunt? </fo:block> <fo:block word-spacing.minimum=”1pt” word-spacing.maximum=”4pt” line-height.minimum=”8pt” line-height.maximum=”14pt”>Patere tua consilia non sentis. . . Senatus haec intellegit. consul videt; hic tamen vivit. . . nostrum. </fo:block> <fo:block word-spacing.minimum=”1pt” word-spacing.maximum=”4pt” line-height.minimum=”8pt” line-height.maximum=”14pt”>Nos autem fortes viri . . . in nos [omnes iam diu] machinaris. </fo:block> </fo:flow> <fo:flow-map flow-map-name="E1"> <fo:flow-assignment copyfit-by-modifying=”word-spacing”> <fo:flow-source-list> <fo:flow-name-specifier flow-name-reference="A"/> </fo:flow-source-list> <fo:flow-target-list> <fo:region-name-specifier region-name-reference="R"/> </fo:flow-target-list> </fo:flow-assignment> <fo:flow-assignment copyfit-by-modifying=”line-height”> <fo:flow-source-list> <fo:flow-name-specifier flow-name-reference="B"/> </fo:flow-source-list> <fo:flow-target-list> <fo:region-name-specifier region-name-reference="S"/> </fo:flow-target-list> </fo:flow-assignment> </fo:flow-map>
The two fo:flow-assignment use different strategies to copyfit. Flow A is copyfitted by only adjusting the word-space of each block (that will be a value between 1pt and 4pt), while flow B is copyfitted by adjusting line-height of each block (that will be a value between 8pt and 14pt).
Note:
The definition of “copyfit-by-modifying” in a fo:flow-assignment object provides great flexibility to the copyfit process. In fact, different blocks may have different values of the same property that are all within the allowed ranges. Though any result that satisfies the specified constraints would conform to this specification, current typographic practice would tend to use the available elasticity with uniformity within the same page-sequence or, at least, whitin the same page. So, for example, if two fo:blocks having the same values for space-before happen to generate areas for a copyfitted page, and the application has to use this elasticity, the result most use will expect would have both spaces being set to an identical value.
copyfit-by-modifying
XSL Definition:
Value: | <property-name-list> |
---|---|
Initial: | everything |
Applies to: | fo:flow-assigment, fo:region, fo:region-body |
Inherited: | no |
Percentages: | N/A |
Fallback: | everything |
This property is used to copyfit text into a region and to define strategies for copyfitting.
Copyfitting is defined as follows: for each reference area generated by that region, the before-edge of the its content-rectangle is placed coincident with the before-edge of the allocation-rectangle of the first child area, and the after-edge of the its content-rectangle should be placed coincident with the after-edge of the allocation-rectangle of the last child area. If the application is not able to achieve copyfitting and the accumulated block-progression-dimension of areas is less the the block-progression-dimension of the reference area (which could happen either for lack of elasticity in the content or for partial support by the formatter), the areas are placed into the reference area according to the value of display-align.
The value is a whitespace separated list of names (property names and / or shorthand names), possibly grouped in subsets by a single level of parenthesis; formally, it can be defined by these rules:
prioritized-list-of-names = [<priority-group>]* priority-group = <property-name> | <shorthand-name> | ([<property-name> | <shorthand-name>]+)
where
"property-name" can be the name of any property defined by the XSL-FO recommendation;
a shorthand-name stands for a pre-defined sequence of property names:
inline-spacing = word-spacing letter-spacing leader-length
block-spacing = space-before space-after
....
any = any property having a range value
An XSL-FO implementation is expected to simplify the value list as follows:
remove empty paren pairs, ()
"(" name ")" is equivalent to name
if property-name refers to a property that cannot accept either range values (.minimum, .optimum, .maximum) or multiple values (such as font-family), it can be removed; the application should warn the user about the uselessness of using that property name.
if property-name refers to a property the application is not able to adjust autpmatically to copyfit content, it can be removed; the application should warn the user about the application limitation.
if a priority group contains the shorthand "any", than the other property names or shorthand names can be removed
every priority group following "any" must be discarded; a processor should warn the user about any discarded priority groups.
At the end of the simplification process the property value could be the empty list. This means that there is no elasticity that the application is able to handle, and the output will not be copyfitted as requested. The default value of "any" has been chosen to reduce the likelihood of this.
Items in the simplified value list are given a decresing priority: the first item's priority is greater than that of the second one, and so on; values between parenthesis have the same priority. The application has to respect this priority assignment while performing copyfitting:
we define "active properties set" as the set of properties whose value the application is allowed to choose at a certain time during the copyfitting; initially, the active properties set contains the values of the first priority group;
The application has to check whether it is possible to copyfit the content using the current active properties set (choosing an appropriate value between their .minimum and .maximum, or among the available ones)
if there is a way to copyfit the content, the output should reflect that particular choice of values, without touching the other properties (i.e. using their .optimum values); otherwise, the next priority group should be added to the active properties set.
Points to note:
the described behaviour follows an incremental approach rather than a combinatorial one; in other words, the number of attempts the application could need to perform is linear in the size of the property list, instead of growing exponentially.
the main aim of the prioritized property list is for the user to be sure that some properties will be adjusted (moving away from their optimal value) only “as a last resort”; this confidence allows the users to give many properties a length range value without fearing for the resulting quality of the output
in any given moment during the copyfitting process, the application has complete freedom concerning the use of the available elasticity (coming from the active properties in that moment); in other words, it is not forced by this specification to exhaust the elasticity of a property before using the one of a different property
force-page-count(adding new values)
XSL Definition:
Value: | auto | even | odd | end-on-even | end-on-odd | no-force | <number> | inherit |
---|---|
Initial: | auto |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Applies to: | fo:page-sequence |
"Force-page-count" is used to impose a constraint on the number of pages in a page-sequence. In the event that this constraint is not satisfied, an additional page will be added to the end of the sequence. This page becomes the "last" page of that sequence.
A positive integer giving the number of pages to be created. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1. @@ I think this should be an error - Liam
Indicates that the number of pages to be created must be multiple of <number>. If the value <number> is a non-positive integer or a non-integer value, the value of the property is equal to "auto".
Note:
Copyfit into columns is not discussed yet.
Note:
copyfitting across multiple regions is not yet addressed.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.1.7
Add support for raised initial capitals and n-line dropped capitals. This includes support for the first n characters.
Large initial capital letters are often used for the first paragraph of a new section or chapter. Many scripts have precise alignment conventions for how the initial letter should be positioned relative to the text in the paragraph.
There are three main types of initial letter.
The first of these is called a [raised initial]; it is set in a larger size then the main text, and space must be left for it in the block progression direction. No special support is needed for raised initials, as an fo:inline can be used with an increased font-size.
The second sort is a margin initial; it protrudes into the margin in the inline progression direction, and is often larger than the paragraph text. This is treated as a special case of the third sort of initial capital, because of its vertical alignment requirements.
The third sort of initial letter is often called a drop capital (often abbreviated to "drop cap"). The initial letter is large enough that it extends in the block-progression direction to the Nth following baseline; the drop capital in Figure 14 is sized such that its baseline aligns with the baseline of the fourth line of text in the paragraph, and the top aligns with the cap-height on the first line; this is called a 4-line drop cap.
Note:
The height of the letter D is thus one cap-height plus three line-heights (including vertical spacing); this will not in general be equal to four times the font size, and an implementation may need to use an algorithm such as binary search to discover the correct font size given the number of lines to span.
Note:
If the line spacing varies over the course of the paragraph, the resulting size of an initial cap is implementation dependent: it must either be positioned using the inherited line spacing where the initial occurs, or must correctly take into account the varying line spacing, and align with the appropriate actual line of text.
Several properties are used on an "fo:inline" element as follows:
initial-cap-lines
XSL Definition:
Value: | <number> | <distance> |
---|---|
Initial: | 0 |
Applies to: | fo:inline |
Inherited: | yes |
Percentages: | refer to inherited font size |
Media: | visual |
This property specifies the number of lines spanned by the initial letter.
A value of 1.0 would indicate a regular-sized letter, and a value of 4 would indicate that the first character (or glyph) contained in the "fo:inline" bearing this property must be sized such that its baseline is aligned with the baseline of the 4th line of the containing block, and the cap-height aligned with the cap-height of the first line.
For a vertical script, the corresponding leading and trailing alignments points must be used.
If a distance is given instead of a unitless number, it is to be used instead of computing the distance in terms of line heights; in this case the formatter is not expected to guarantee alignment of the baseline of the initial with that of the nearest text baseline.
Open issue: 7562
An alternative design for initial caps and the initial-cap-lines property would be to say that the value of "auto" for font-size would mean that the font-size was computed from the number of lines.
If the "fo:inline" should happen to format to more than one glyph, the second and subsequent glyphs should be drawn at the same size as the first, even if after line-breaking this results in the first character no longer aligning with the fourth baseline.
If the value is negative, an implementation MAY interpret it as as "dropping" backwards (e.g. upwards for horizontal top-to-bottom scripts).
A non-integral value represents a proportion, so that a value of 3.5 would indicate that the initial should be half-way between the baselines of the third and fourth lines of text.
A value of zero MUST taken to be the same as the default value of 1.0, and is in effect ignored.
If the containing block does not have enough content to span the given number of lines, the initial SHOULD be formatted as if there was enough content, and the size of the initial cap MUST then be included in the block-progression-direction dimension of the block.
If there is not enough room left in the column, page or region, the initial must be taken onto the next page along with the text.
When the "initial-cap-lines" property is set on a formatting object that is not at the start of the block, any preceding text should be pushed out into the margin; this is often used for quote marks.
initial-cap-lines-before
XSL Definition:
Value: | <number> | <distance> |
---|---|
Initial: | 0pt |
Applies to: | fo:inline |
Inherited: | yes |
Percentages: | Not applicable. |
Media: | visual |
Sometimes an initial capital extends before the start of the text as well as perhaps continuing for several lines.
The "initial-cap-lines-before" property indicates that the initial is to be formatted at a size such that it protrudes in the block-progression-direction to the given distance or number of lines.
Figure 15 shows a Greek initial capital that protrudes above the first line (as measured from the cap height of the first line of text) as well as extending below it.
A value of zero indicates that the leading edge of the initial is to align exactly with that of capital letters in the regular text size.
If the value is negative, an implementation MAY interpret it as as "dropping" forwards.
Figure 15. Sample Greek Paragraph Starting With Two-Line Initial Capital Protruding Before and After.
Open issue: 7563
Need a clear description of margins, spacing, and initial caps
initial-cap-kern-lines
XSL Definition:
Value: | <length> | <integer> |
---|---|
Initial: | 0 |
Applies to: | fo:inline |
Inherited: | yes |
Percentages: | refer to initial-cap-lines-after |
Media: | visual |
The "initial-cap-kern-lines" property indicates the number of lines of text that should be abutted to the large intial.
A value of 1 would indicate that the first line of text should be set as close as possible, taking into account the shape of the enlarged glyph.
If a distance is given, such as 3cm, any lines whose baselines fall within that distance of the starting reference point of the initial cap are abutted.
The value must not be negative. The default value of zero indicates that no lines are to be kerned closer, and hence all lines are set using the margin.
Note:
In Figure 14, the first line is set close, and subsequent lines are set vertically using the "margin" trait of the "fo:inline" element where it is next to the text.
initial-cap-indent
XSL Definition:
Value: | <length> | <percentage> | auto | inherit |
---|---|
Initial: | 0pt |
Applies to: | fo:inline |
Inherited: | yes |
Percentages: | refer to width of enlarged glyph |
Media: | visual |
The exact font size of the initial is in general computed by the formatter, so the exact distance for an indent must also be computed.
The initial-cap-indent property distance (either as an absolute value or as a percentage of the actual formatted initial cap width) by which the initial is indented in the inline progression direction.
The "initial-cap-indent" is most often either zero or negative, moving the initial into the margin; a value of -50% leaves the glyph centered on the edge of the containing content area. A value of 20% indents the initial (and hence the first n lines of text) by one fifth (20%) of the width of that glyph.
The enlarged initial is moved in the inline-progression-direction by the given amount.
The enlarged initial is moved in the inline-progression-direction by the given percentage of the size of the glyph.
The indent is computed based on any text that precedes the "fo:inline" container in the same block; if the initial is not at the start of a line, the default behaviour (with a "initial-cap-indent" of zero, the default value) is to put such text in the margin: this is most often an opening quote or other punctuation. With a value of auto, the initial is placed wherever it occurs, and the resulting trait value is computed by the formatter.
Note:
Note: this section needs to be revised in the light of the new general fo:region
The region-body has two extension-regions, called extension-region-start and extension-region-end, which implicitly specify corresponding reference-areas called "start-marginalia-reference-area" and "end-marginalia-reference-area".
The extent in the inline-progression-direction of each extension-region is indicated in the "extent" attribute of the "fo:extension-region-*" declaration, while the block-progression-dimension of the area is the same of the region-body.
Figure 16 shows the current XSL-FO 1.1 page model extended to also include these regions.
An example declaration of these regions is shown below:
<fo:simple-page-master master-name="only" page-height="29.7cm" page-width="21cm" margin-top="1cm" margin-bottom="2cm" margin-left="2.5cm" margin-right="2.5cm"> <fo:region-body margin-top="3cm" margin-bottom="1.5cm" margin-left="2cm" margin-right="2cm"/> <fo:extension-region-start extent="1cm" distance="0.5cm"/> <fo:extension-region-end extent="1cm" distance="0.5cm"/> <fo:region-before precedence="true" extent="3cm"/> <fo:region-after precedence="true" extent="1.5cm"/> <fo:region-start extent="1cm"/> <fo:region-end extent="1cm"/> </fo:simple-page-master>
The element "fo:extension-region-*" also defines other properties of the region such as border, padding, background, etc.
It is an error if a marginalia is contained in a page whose "fo:simple-page-master" does not contain any "fo:extension-region" declaration.
Open issue: 7564
Should users be able to direct marginalia to another region, or only to a predefined marginalia area?
Open issue: 7565
Extension regions may be confusing on a single page master. So far everything is computed relative to the beginning of the page. What about using multiple region bodies of XSL-FO 1.1? That solution would give users more freedom but would require them to impose alignment constraint among regions.
Open issue: 7566
The spec needs to clarify the relation between marginalia and footnotes. In particular, we need to decide whether the marginalia areas can collapse if there's no marginalia. Do we want such a dynamic behavior? There is a note in the requirement document about marginalia and footnotes but it seems to be mainly related to numbering issues.
Common Usage:
Used to define a rectangular region that extends from the region-body along the "start" direction to contain marginalia, if they exist.
Note:
The specification will need to handle non-rectangular regions too here; this is work in progress. [no specific bugillza item for this: it is pervasive]
Areas:
The extension-region-start specifies a viewport/reference pair that is located on the "start" side of the region-body, meaning that the before edge of the extension-region is aligned with the before-edge of the region-body and the end-edge of this region is parallel to the start-edge of the region-body, at a distance specified by the "distance"attribute.
Constraints:
None.
Contents:
Empty.
Common Usage:
Used to define a rectangular region that extends from the region-body along the "end" direction to contain marginalia, if they exist.
The "extension-region-end" region specifies a viewport/reference pair that is located on the "end" side of the region-body. The before-edge of this region is aligned with the before-edge of the region-body and the start-edge of this region is parallel to the end-edge of the region-body, at a distance specified by the "distance" attribute.
Constraints:
None.
Contents:
Empty.
distance
XSL Definition:
Value: | <length> | <percentage> |
---|---|
Initial: | 0pt |
Inherited: | no |
Percentages: | refer to the corresponding inline-progress-dimension of the page-viewport-area. |
Media: | visual |
Specifies the distance between the edge of the region-body and the edge of the extension region to which it applies.
If it applies to fo:extension-region-end, it indicates the distance between the start-edge of the extension region and the end-edge of the region-body. If it applies to to:extension-region-start it indicates the distance between the end-edge of the extension region and the start-edge of the region-body.
Values have the following meanings:
This is an unsigned length. Negative values are treated as if they were zero.
The value is a percentage of the corresponding inline-progression-dimension of the page-viewport-area.
Common Usage:
The fo:marginalia formatting obiect is intended to be used to produce marginalia, positioned in a separate area external to the start-edge or end-edge of the region-body.
Areas:
The fo:marginalia formatting object does not generate any areas. The fo:marginalia formatting object returns the areas generated and returned by its child fo:inline formatting object. The fo:inline element is optional.
Note:
The fo:inline formatting object is also useful for numbered marginalia, requirement 2.2.3.1.
If the fo:inline is empty, the fo:marginalia object does not generate any area.
Additionally the fo:marginalia formatting object returns the block-areas with area class "xsl-marginalia" generated by its fo:marginalia-body child. The areas with area-class "xsl-marginalia" are placed as children of the marginalia-reference-area in the corresponding extension region.
Constraints:
An fo:marginalia is not permitted to have an fo:marginalia, fo:float, fo:footnote, or fo:marker as a descendant. Additionally, an fo:marginalia is not permitted to have as a descendant an fo:block-container that generates an absolutely positioned area.
The term "marginalia-body-area" is defined to mean the first area generated and returned by the fo:marginalia-body, child of the fo:marginalia.
The term "anchor-area" is defined to mean the line area parent of the area generated by the fo:inline child of the fo:marginalia. If the fo:marginalia does not generate any area, the anchor-area is the previous line area in the pre-order visit of the area tree.
These terms are used to specify how to align a marginalia with the text it refers to, setting the "marginalia-relative-align" property. See details below.
Contents:
(inline?,marginalia-body)
The following properties apply to this formatting object:
marginalia-destination-area: to indicate the marginalia-reference-area where the block-areas generated by the child "fo:marginalia-body" will be placed. This property can be inherited.
Possible values of this attribute are:
"start": the content of the marginalia will be placed in the extension-region-start region
"end": the content of the marginalia will be placed in the extension-region-end region
"inner": the content of the marginalia will be placed in the extension-region-end region of an even page and in the extension-region-start of an odd page region
"outer": the content of the marginalia will be placed in the extension-region-start region of an even page and in the extension-region-end of an odd page
marginalia-relative-align: to indicate the alignment of the marginalia with respect to the text it refers to. This property specifies the alignment, in the block-progression-direction, between two areas.
Possible values of this attribute are:
"before": the before-edge of the marginalia-body-area is placed aligned with the before-edge of the anchor-area.
"baseline": the distance between the baseline of the marginalia-body-area is the same as the distance between the baseline of the anchor-area.
Common Usage:
The fo:marginalia-body is used to generate the marginalia content.
Areas:
The fo:marginalia-body generates and returns one or more block-level areas with area-class "xsl-marginalia". The areas with area-class "xsl-marginalia" are placed as children of the marginalia-reference-area in the corresponding extension region.
Constraints:
The fo:marginalia-body is only permitted as a child of an fo:marginalia.
The position of a marginalia in the page (i.e., the corresponding marginalia-reference-area) is indicated in the "marginalia-destination-area" attribute of the "fo:marginalia formatting object."
Areas with area-class equal to "xsl-marginalia "are defined to be "stackable", indicating that they are supposed to be stacked, in the block-progression-direction within their marginalia-reference-area. In addition a "special stacking rule" has to be applied for placing marginalia in the marginalia-reference-area.
The term "marginalia-body-area" is defined to mean the first area generated and returned by the fo:marginalia-body. The term "anchor-area" is defined to mean the line area parent of the area generated by the fo:inline child of the fo:marginalia. If the fo:marginalia does not generate any area, the anchor-area is the previous line area in the pre-order visit of the area tree.
The offset of the before-edge of the marginalia-body-area from the before-edge of the marginalia-reference-area cannot be smaller than the offset of the before-edge of the anchor-area from the before-edge of the region-reference-area. This constraint makes marginalia anchored to the text they refer to.
The "marginalia-relative-align"property of the fo:marginalia formatting object allows users to further specify the alignment of a marginalia with the text it refers to.
The following properties apply to this formatting object:
Common accessibility properties; id; index-class; index-key.
marginalia-destination-area
XSL Definition:
Value: | start | end | inner | outer | inherit |
---|---|
Initial: | start |
Applies to: | fo:marginalia |
Inherited: | yes |
Percentages: | Not applicable. |
Media: | visual |
Specifies the marginalia-reference-area in which to place the block-areas generated by the child fo:marginalia-body to which it applies.
Values have the following meanings:
The content of the marginalia will be placed in the extension-region-start region.
The content of the marginalia will be placed in the extension-region-end region.
The content of the marginalia will be placed in the extension-region-end region on even pages and in the extension-region-start region on odd pages.
The content of the marginalia will be placed in the extension-region-start region on even pages and in the extension-region-end region on odd pages.
marginalia-relative-align
XSL Definition:
Value: | before | baseline | end | inherit |
---|---|
Initial: | before |
Applies to: | fo:marginalia |
Inherited: | yes |
Percentages: | Not applicable. |
Media: | visual |
Specifies the alignment of the marginalia with respect to the text to which it refers. This property specifies the alignment, in the block-progression-direction, between two areas.
Values have the following meanings:
The before-edge of the marginalia-body-area is aligned with the before-edge of the anchor-area.
The distance between the baseline of the marginalia-body-area is the same as the distance between the baseline of th anchor-area extension-region-start region.
The after-edge of the marginalia-body-area is aligned with the after-edge of the anchor-area.
A general comment: vertical positioning (and justification) is connected to regions and columns, and that work is not yet complete. In addition, the term Vertical in this section should be taken to mean block-progression-direction.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.4.1
Add support for feathering, to vertically adjust lines. Feathering is vertical justification with very small amounts.
Feathering is the process of filling a block of text to available space, such as the height of the page, for example by adding a small (and ideally imperceptible) amount of space between each line of text. The formatter adjusts the space-before and space-after traits of the stacked block-areas and line-areas in order to fill the reference area.
The before-edge of the allocation-rectangle of the first child area is placed coincident with the before-edge of the content-rectangle of the reference-area. The after-edge of the allocation-rectangle of the last child area is placed coincident with the after-edge of the content-rectangle of the reference-area. The difference between the sum of allocation rectangles and the block progression dimension of the reference area is distributed between each pair of adjacent areas.
One proposal is to add a new value for the property "justify-by-modifying" (itself new for XSL-FO 2.0) indicating that vertical justification is done by adjusting space-before and space-end properties. Space-specifiers (minimum, optimum and maximum) are used to specify constraints on the amount of space to be added.
A alternative approach (somewhat simpler, but not included in this document) might be to add a new value, "feathering", for the property "display-align". In that case, we assume that spaces are equally distributed between each pair of adjacent areas filling the reference area.
justify-by-modifying
XSL Definition:
Value: | <whitespace-separated list of property names> |
---|---|
Initial: | the empty list |
Applies to: | fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end and fo:block-container |
Inherited: | no |
Percentages: | Not applicable. |
Media: | visual |
Specifies a list of properties whose values can be adjusted in order to do vertical justification.
Different strategies can be applied: adjusting spaces between lines, feathering, widening or narrowing spaces before and after images and tables, stretching or compressing text, changing word-spacing, adjusting the character-spacing, etc.
This property does not specify the variation ranges, which will be defined using the existing properties.
Values have the following meanings:
the list of FO properties (such as "space-before", "space-after", "word-spacing", "letter-spacing", and so on) to be adjusted to fill the reference area.
feathering: the content is justified by adding/removing small amount of space between areas (see requirement 2.2.4.1). The formatter decides where spaces end up;
the content is justified by equally distributing spaces between each pair of adjacent areas;
the content is justified by changing "word-spacing" and "letter-spacing".
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.4.2
Add support for correlating vertical position so that lines of text on two adjacent pages, columns or regions are visually next to each other. Also support alignment of the two sides of the same sheet, so that the lines of text on the back side and front side of the sheet are aligned. Note that this requirement is different from optical alignment. The problem arises if pages/columns contain objects whose height is different than the normal line-height. Some space must be added before/after those objects in order to adjust the layout.
To address this we introduce a new property that specifies a "normalized line height" that must be used as an atomic unit of height. That property specifies a length that the block progression-dimension of each generated area must be a multiple of. Spaces are added before/after each generated area in order to adjust the block progression-dimension. In a multi-column region, the same value is used for all columns.
A provisional name is "block-progression-unit", whose value is a length.
block-progression-unit
XSL Definition:
Value: | <length> |
---|---|
Initial: | 0pt |
Applies to: | fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end, fo:block-container |
Inherited: | yes |
Percentages: | Not applicable. |
Media: | visual |
When this property is set and non-zero, the block progression dimension of each generated area must be rounded up to the nearest multiple of the property value.
A value of zero means that there is no such constraint on the area block progression dimension.
The block progression dimension of each generated area should be rounded up to the nearest greater value that is an integer multiple of the specified length. The difference between the original block progression dimension and the rounded one MUST be transformed into a space-before and / or a space-after (according to the area position and the space conditionality).
For example, suppose that a region has block-progression-unit="12pt". Each block <fo:block line-height="10pt" line-stacking-strategy="font-height" >Text ......</fo:block> will have a block progression dimension equal to N * 12pt (the block progression dimension of each line area is not changed). So, if the block creates eight line areas, the first two placed at the bottom of a page and the other six at the beginning of the next page, the first block area will be given a block progression dimension equal to 24pt (with a 4pt space-before) and the second block will have a 60pt block progression dimension with no extra space.
The property applies to fo:region-* and fo:block-container, and defines how to adjust the block progression dimension of the first-level block formatting objects (the direct children of either fo:flow or fo:static-content).
The intended consequence is that lines of text on facing pages will line up, and also that show-through of lines printed on the other side of a page will be reduced, because the lines of text are printed in corresponding places on each side of the paper.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.4.3
Add support for vertical alignment, such as centering the content of the columns or aligning to the bottom within pages, regions or columns.
Note:
This section does not yet take new work on columns into account.
For this, we use the existing "display-align" property:
In a multi-column region the same value is used for all columns, apart from the last one (specified with the property "display-align-last-column").
Applies to: fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end and fo:block-container.
Note:
Property "display-align" also applies to: fo:external-graphic, fo:instream-foreign-object, fo:inline-container, and fo:table-cell. A similar issue exists for vertical justification.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.4.4
Allow users to do alignment specific to the last column.
display-align-last-column
XSL Definition:
Value: | <auto | before | center | after | inherit |
---|---|
Initial: | auto |
Applies to: | fo:region-body |
Inherited: | no |
Percentages: | Not applicable. |
Media: | visual |
Specifies how to align the last column of a multi-column region. This property specifies the alignment, in the block-progression-direction, of the areas that are the children of a reference-area.
Note:
This will need to be integrated with the columns-everywhere proposal.
Values for the property have the following meaning:
If the "relative-align" property applies to this formatting object the "relative-align" property is used. If not, this value is treated as if "before" had been specified.
The before-edge of the allocation-rectangle of the first child area is placed coincident with the before-edge of the content-rectangle of the reference-area;
The child areas are placed such that the distance between the before-edge of the allocation-rectangle of the first child area and the before-edge of the content-rectangle of the reference-area is the same as the distance between the after-edge of the allocation-rectangle of the last child area and the after-edge of the content-rectangle of the reference-area;
The after-edge of the allocation-rectangle of the last child area is placed coincident with the after-edge of the content-rectangle of the reference-area.
Note:
This section does not yet take new work on columns into account. A fo:column object may be introduced in a future draft.
Note:
fo:region-body is the only multi-column region XSL-FO 1.1, but there’s a requirement to extend multi-column regions (2.2.11.6).
Note:
This property could be used to do column-balancing. Not discussed yet.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.4.5
Add support for adjusting properties to do vertical justification within a page, a region or a column, as well as across regions.
We extend the display-align
property
with a
new value "justify". It is also important to allow users to specify
which properties should be modified in order to do vertical
justification. Feathering is one of the possibilities. Other
solutions might be: widening or narrowing spaces before and after
images and tables, stretching or compressing text, changing
word-spacing, adjusting the character-spacing, etc. Thus, we
introduce a property indicating a list of properties that the
formatter is allowed to change, called
"justify-by-modifying", as described under
feathering.
Note:
The display-align property also applies to: fo:external-graphic, fo:instream-foreign-object, fo:inline-container, and fo:table-cell.
Open issue: 7567
should vertical justification also apply to fo:table-cell, for instance? What other areas?
Open issue: 7568
Should there be a new specific property for vertical justification, instead of a special value for "display-align"?
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.1
To improve decimal alignment, extend the character alignment in table cells to permit a specification of the horizontal position of the alignment point within the column.
Text alignment is ordinarily the same for all cells in a column, so the natural choice is to specify the "text-align" property on the fo:table-column and specify 'text-align="from-table-column()"' on all the fo:table-cell objects in that column. To specify a value other than the default for a specific fo:table-cell in the table-column, use that value in the "text-align" property.
The only accepted value for fo:table-column would be "left", "right", and "decimal" (newly added). When the value is "decimal", each cell's text is aligned on the decimal separator as determined by the locale setting, e.g. "." or ",".
In Microsoft Excel or spreadsheet, the alignment of text in a cell is usually done based on the data's type, e.g. alphabetic text is usually aligned to the left, numbers are usually aligned to the right, and Boolean values are usually aligned to the center. Do we also need to extend the "text-align" property to allow automatic alignment? Should decimal alignment could be a special case for number alignment?
Text in the cells with a single table may be numbers and strings with mixed fonts and properties. Do we also need to provide a guide of the fallback mechanism if the alignment point cannot be determined?
Consider a long table that has tens of thousands of rows. Aligning a column with decimal alignment will have huge impact on the performance on the rendering of the table, since the formatter must know the position of the decimal point in the cell in every row of the column before it can start to calculate the appropriate alignment for all the cells.
Also, inspired by the OASIS table model, should we add a new property only available for either table-cell or table-column called "text-align-charoff". This property would be used if and only if "text-align" is given a single-character string as its value. The value for the "text-align-charoff" property would be the same as the OASIS table model, i.e. specifying a percentage of current column width between the start-edge (as determined based on the "writing-mode") and the point at where the character is aligned. For example, the default value "50" would specify that the character is aligned at the center of the column.
<table-cell text-align="'.'">...
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.2
Be able to specify different instances of what the table header or footer should be depending on the different boundaries (page, column and region). This also would allow specifying that certain headers must be omitted at certain boundaries.
Similar to fo:page-sequence-master-alternatives and selecting page masters, provide new formatting objects for selecting alternative headers and footers for tables: fo:table-header-alternatives, fo:table-footer-alternatives, fo:conditional-table-header-reference, and fo:conditional-table-footer-reference.
fo:table-header-alternatives is a child object of fo:table-header. It doesn't have any properties.
fo:table-footer-alternatives is a child object of fo:table-footer. It does not have any properties.
fo:conditional-table-header-reference is a child of
fo:table-header-alternatives. It has a header-position
property.
fo:conditional-table-footer-reference is a child of
fo:table-footer-alternatives. It has a footer-position
property.
The valid values for both "header-position" and "footer-position" are "page", "column" and "region". If a fo:conditional-table-header or fo:conditional-footer-reference doesn't have "header/footer-position" property, it's the default reference for the table.
Sample XSL FO snippet:
<fo:table> <fo:table-header> <fo:table-header-alternatives> <fo:conditional-table-header-reference> ... </fo:conditional-table-header-reference> <fo:conditional-table-header-reference header-position="page"> ... </fo:conditional-table-header-reference> <fo:conditional-table-header-reference header-position="column"> ... </fo:conditional-table-header-reference> ... </fo:table-header-alternatives> </fo:table-header> <fo:table-footer> <fo:table-footer-alternatives> </fo:table-footer-alternatives> </fo:table-footer> <fo:table-body> ... </fo:table-body> </fo:table>
It's relatively cumbersome to use different formatting objects that distinguish alternative headers from alternative footers, so a single object could be introduced to represent the concept e.g. a fo:table-layout-alternatives. Its parent object would determine whether this object represents a header or a footer. The reference object would correspondingly be named fo:conditional-table-layout-reference.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.3
Allow users to specify that tables can be split horizontally. It should be possible to have a column repeated when the table is split horizontally, by specifying a row header. There should be a way to keep the split parts visually next to each other depending on binding edge.
In case a table is split over multiple pages and both the rows and columns don’t fit a page, allow users to specify which table part comes out in which order (rows first or columns first).
When printing from spreadsheet applications, printing a table that overflows a single page as series of pages, usually with repeated header rows and columns, is common. Within XSL FO, overflow behavior is specified with the "overflow" property, but the XSL 1.1 "overflow" property has similar semantics to CSS and does not sufficiently handle overflow on tables.
XSL Definition:
Value: | paginate-column-first | paginate-row-first | auto |
---|---|
Initial: | auto |
Applies to: | fo:table |
Inherited: | no |
Percentages: | Not applicable. |
Media: | paged |
Values have the following meanings:
Paginate columns before rows
Paginate rows before columns.
This is the default behavior. The User Agent determines the pagination method.
The "table-overflow" property specifies the method for paginating a large table into multiple pages.
Open issue: 8860
Should other values of "overflow" property be allowed for the "table-overflow" property, e.g. "visible", "hidden", "scroll", and "error-if-overflow"?
Note:
Normally, we would expect the row header and the column header to be repeated during the pagination, but do we need to add another property to allow the user to override the default behavior or to suppress the behavior? Maybe table-omit-header-at-break and table-omit-footer-at-break apply to the alternatives and/or conditional references.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.4
Allow users to specify that when a spanned cell in a table is split, the entire cell contents should be repeated on each table instance. This applies to splitting as well as spanning in the block-progression-direction as well as the inline-progression-direction.
In paged media, a table cell may be split, either vertically or horizontally or both, because another table cell in the same row or column overflows its available area. Additionally, a table cell that spans multiple rows or columns may be split because the rows or columns that it spans are paginated on separate pages.
Allow the "overflow" property to be applied to fo:table-cell and add the "repeat" value that applies only to fo:table-cell.
When the value is "repeat", the content of the fo:table-cell will be repeated on the next page.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.5
Allow the column lines to extend down or right the table to visually indicate that the table continues. When this happens, any vertical border should be extended beyond the bottom border for the last row or right column [on the page].
This applies to pagination of tables split vertically, horizontally or both vertically and horizontally.
XSL 2.0 defines the following properties: "border-break", "border-before-break", "border-after-break", "border-start-break" and "border-end-break". Their allowed values are: "auto", "hidden" and "extend".
When the value is "extend", the respective border is extended till the end of the area.
When the "border-collapse" property is set to be "collapse", which value of the "border-break" value takes higher priority? "extend"?
When the "border-collapse" property is set to be "separate", if one of the adjacent borders set the "border-break" property to be "auto" or "hidden", but the other is set to be "extend", the rendered table border will looks like this:
Open issue: 8861
Do we need to set the "border-break" style at the fo:table-row level and fo:table-column level, or at table-cell level as proposed here?
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.6
When one formatting object is immediately preceding another in block-progression-dimension, be able to specify what to do with their adjacent borders.
Allow the "border-collapse" property on other formatting objects in addition to fo:table-cell, e.g. fo:block and fo:inline.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.7
Allow having different borders when a break occurs so that a formatting object is split, e.g. a cell that splits, have a thinner border for the split.
Define properties "border-break-style", "border-start-break-style", "border-end-break-style", "border-before-break-style", and "border-after-break-style". The properties' values are the same as for the "border-style" property, and the same border conflict resolution rules CSS border conflict resolution rules apply.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.5.8
The current specification of XSL says that number-rows-spanned and number-columns-spanned should be a positive integer. Other specifications, such as HTML 4.01, allow 0 as a value, which means that all rows or columns of the current table section are spanned over. This behavior may be added to XSL 2.0, either by allowing 0 as a value, or some other solution.
Allow "0" as a value for the "number-rows-spanned" and "number-columns-spanned" properties, with the same semantics as for HTML 4.01 as described at http://www.w3.org/TR/html4/struct/tables.html#adef-colspan
Open issue: 8862
It would be better to use "all" as a value, but that is not compatible with HTML. Should we allow either?
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.12.1
Be able to define layout-master-sets not only at the top of the FO tree, but also interleaving page-sequences, to allow users to define and change masters, such as simple-page-master and page-sequence master, on the fly instead of having to specify all the masters in the beginning of the FO tree. When traversing the FO tree in pre-order traversal, the master must be defined before it may be referenced by a master-reference property.
Note:
This section is currently worded as a set of changes to XSL-FO 1.1
There are two parts to fulfilling this requirement: modifying allowed contents to allow extra "fo:layout-master-set" elements to appear, and adjusting the wording of the spec to say what happens when it occurs.
Allowed contents
For fo:page-sequence-wrapper, allow fo:layout-master-set where you can now have fo:page-sequence or fo:page-sequence-master:
Change the content model from:
(page-sequence|page-sequence-wrapper)*
to:
(layout-master-set,declarations?,bookmark-tree?, (layout-master-set|page-sequence|page-sequence-wrapper)+)
Changes
The following changes to XSL 1.1 are proposed to satisfy this requirement:
Change:
The fo:layout-master-set is a wrapper around all masters used in the document.
To:
The fo:layout-master-set is a wrapper around masters used in the document.
Change:
The children of the fo:root formatting object are a single fo:layout-master-set, an optional fo:declarations, an optional fo:bookmark-tree, and a sequence of one or more fo:page-sequences and/or fo:page-sequence-wrapper elements.
To:
The children of the fo:root formatting object are a fo:layout-master-set, an optional fo:declarations, an optional fo:bookmark-tree, and a sequence of one or more fo:layout-master-set and/or fo:page-sequences and/or fo:page-sequence-wrapper elements.
Change:
The fo:layout-master-set defines the geometry and sequencing of the pages
To:
The fo:layout-master-sets define the geometry and sequencing of the pages
Change:
The children of the fo:layout-master-set are the pagination and layout specifications and flow-map specifications.
To:
The children of the fo:layout-master-sets are the pagination and layout specifications and flow-map specifications.
Change:
This is the top node of the formatting object tree. It holds an fo:layout-master-set formatting object (which holds all masters used in the document), an optional fo:declarations, an optional fo:bookmark-tree, and one or more fo:page-sequence or fo:page-sequence-wrapper objects.
To:
This is the top node of the formatting object tree. It holds an fo:layout-master-set formatting object, an optional fo:declarations, an optional fo:bookmark-tree, and one or more of fo:layout-master-set, fo:page-sequence or fo:page-sequence-wrapper objects. An fo:layout-master-set holds masters used in the document.
Change the contents to:
(layout-master-set,declarations?,bookmark-tree?, (layout-master-set|page-sequence|page-sequence-wrapper)+)
Change:
If the flow-map-reference is specified, the flow-map in effect is the one described by the fo:flow-map child of the fo:layout-master-set having a flow-map-name matching the specified value of flow-map-reference on the fo:page-sequence.
To:
If the flow-map-reference is specified, the flow-map in effect is the one described by the closest preceding fo:flow-map (this is a child of a preceding fo:layout-master-set) having a flow-map-name matching the specified value of flow-map-reference on the fo:page-sequence.
Change:
The fo:layout-master-set is a wrapper around all masters used in the document. This includes page-sequence-masters, page-masters, and flow-maps.
To:
The fo:layout-master-set is a wrapper around masters used in the document. This includes page-sequence-masters, page-masters, and flow-maps.
Change:
Names identify masters, may not be empty and must be unique.
To:
Names identify masters, MUST NOT be empty and must be unique within an fo:layout-master-set.
Change:
A master-name must be unique across all page-masters and page-sequence-masters.
To:
A master-name must be unique across all page-masters and page-sequence-masters within an fo:layout-master-set.
Change:
The names need not be unique, but may not be empty and must refer to a master-name that exists within the document.
To:
The names need not be unique, but MUST NOT be empty and must refer to a master-name that exists within the current or a preceding fo:layout-master-set.
Change:
If the name is empty or if a name-conflict is encountered, an error shall be reported. A processor may then continue processing.
To:
If the name is empty, an error shall be reported. A processor may then continue processing.
If a name-conflict is encountered, the last specified master-name is used.
Some difficulties here: 'flow-name-reference' is a "soft" reference; the flows currently always occur after these references; this current constraint is too loose even for XSL 1.1:
The name identifies a flow; it MUST NOT be empty and must refer to a flow-name that exists within the document.
The definition of fo:flow-map at least includes:
The source list is a sequence of flow names whose corresponding fo:flow objects (in the referring fo:page-sequence) are treated as a single fo:flow for composition purposes.
where "(in the referring fo:page-sequence)" seems a more useful constraint than "within the document".
Change:
The name identifies a region; it may not be empty and must refer to a region-name that exists within the document.
To:
The name identifies a region; it MUST NOT be empty and must refer to a region-name that exists within the current or a preceding fo:layout-master-set.
or it may be best to leave it as-is.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.12.2
Have sets of pages repeatable within the same page-sequence.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.12.3
Allow specifying that every n-th page, a different master should be used. This is a specific case of 2.2.12.2 Repeatable sub-sequence-specifier. For example, use master A for page 1, 2, 3, 4, then master B for page 5, then master A again for 6, 7, 8, 9 then master B for page 10, etc...
To address this requirement, three changes to XSL 1.1 are proposed:
Add 'sequence-repeats' to 'fo:repeatable-page-master-alternatives'
Allow numbers in 'page-position'
Adjust 'fo:repeatable-page-master-alternatives' and 'fo:conditional-page-master-reference' definitions accordingly
sequence-repeats
XSL Definition:
Value: | <number> | no-limit | inherit |
---|---|
Initial: | no-limit |
Inherited: | no |
Percentages: | Not applicable. |
Media: | all |
Specifies the number of pages in a cyclic sub-sequence of pages that may be generated before the cycle repeats.
The values are as follows:
No constraint is specified.
The maximum number of pages in the sub-sequence cycle.
The value is an integer greater than or equal to 0.
If a fractional value or a value less than 0 is specified, it will be rounded to the nearest integer greater than or equal to 0.
A value of 0 indicates this sub-sequence-specifier will not be used.
page-position
XSL Definition:
Value: | <number> | only | first | last | rest | any | inherit |
---|---|
Initial: | any |
Inherited: | no |
Percentages: | Not applicable. |
Media: | all |
This property forms part of a selection rule to determine if the referenced page-master is eligible for selection at this point in the page-sequence or, when the "sequence-repeats" property value is not "no-limit", at this point in the sub-sequence cycle.
The values have the following meanings:
This master is eligible for selection if the value is equal to the current page number or, when the "sequence-repeats" property value is not "no-limit", at this point in the sub-sequence cycle.
Note:
For example: when "sequence-repeats" is 'no-limit', '4' is true for the fourth page in the page-sequence only; when "sequence-repeats" is '4', '4' is true for the fourth, eighth, twelfth, etc. pages in the page-sequence; and when "sequence-repeats" is '6', '4' is true for the fourth, tenth, sixteenth, etc. pages.
The value is an integer greater than or equal to 0.
If a fractional value or a value less than 0 is specified, it will be rounded to the nearest integer greater than or equal to zero.
A value of 0 indicates this master-reference will not be used.
A value greater than the "sequence-repeats" value, when "sequence-repeats" is not 'no-limit', is false.
This master is eligible for selection if this is the only page (i.e. the page is both first and last) page in the page-sequence.
This master is eligible for selection if this is the first page in the page-sequence.
This master is eligible for selection if this is the last page in the page-sequence.
This master is eligible for selection if this is not the first page nor the last page in the page-sequence.
This master is eligible for selection regardless of page positioning within the page-sequence.
Note:
Several of these values can be true simultaneously; for example, 'any' is always true, 'only' is true when both 'first' and 'last' are true, and 'first' and '1' are both true for the first page in a page-sequence. For that reason, it is necessary to order the fo:conditional-page-master-references so that the least inclusive test is performed before the more inclusive test which are also true.
Common Usage:
The fo:repeatable-page-master-alternatives formatting object is the most complex sub-sequence-specifier. It specifies a sub-sequence consisting of repeated instances of a set of alternative page-masters. The number of repetitions may be bounded or potentially unbounded. The repetitions may also be cyclic. Which of the alternative page-masters is used at any point in the sequence depends on the evaluation of a condition on the use of the alternative.
Typical conditions include testing whether the page which is generated using the alternative is:
The first or last page in a page-sequence;
Blank;
The nth page in a page-sequence or a page cycle
The full set of conditions allows different page-masters to be used for the first page, for odd and even pages, for blank pages, etc.
Note:
Because the conditions are tested in order from the beginning of the sequence of children, the last alternative in the sequence usually has a condition that is always true and this alternative references the page-master that is used for all pages that do not receive some specialized layout.
Areas:
The fo:repeatable-page-master-alternatives formatting object generates no area directly. This formatting object is used by the fo:page-sequence formatting object to generate pages.
Constraints:
The children of the fo:repeatable-page-master-alternatives are fo:conditional-page-master-references. These children are called alternatives.
The sub-sequence of pages mapped to this sub-sequence-specifier satisfies the constraints of this sub-sequence-specifier if (a) the sub-sequence of pages consists of zero or more pages, (b) each page is generated using the fo:simple-page-master referenced by the one of the alternatives that are the children of the fo:repeatable-page-master-alternatives, (c) the conditions on that alternative are true, (d) that alternative is the first alternative in the sequence of children for which all the conditions are true, and (e) the length of the sub-sequence is less than or equal to the value of maximum-repeats.
Contents:
(conditional-page-master-reference+)
The following properties apply to this formatting object:
maximum-repeats; sequence-repeats
Common Usage:
The fo:conditional-page-master-reference is used to identify a page-master that is to be used when the conditions on its use are satisfied. This allows different page-masters to be used, for example, for even and odd pages, for the first page in a page-sequence, for the third page in a page-sequence cycle, or for blank pages. This usage is typical in chapters of a book or report where the first page has a different layout than the rest of the chapter and the headings and footings on even and odd pages may be different as well. Selecting page-masters based on position within a cycle is typical of bulk-mailed correspondence that is to be folded into envelopes by a folding machine.
Areas:
The fo:conditional-page-master-reference formatting object generates no area directly. It is used by the fo:page-sequence formatting object to generate pages.
Constraints:
The fo:conditional-page-master-reference has a reference to the fo:simple-page-master which has the same master-name as the master-reference trait on the fo:conditional-page-master-reference.
There are three traits, page-position, odd-or-even, and blank-or-not-blank that specify the sub-conditions on the use of the referenced page-master. All three sub-conditions must be true for the condition on the fo:conditional-page-master-reference to be true.
Note:
Since the properties from which these traits are derived are not inherited and the initial value of all the properties makes the corresponding sub-condition true, only the subset of traits that are derived from properties with specified values must have their corresponding sub-condition be true.
The sub-condition corresponding to the page-position trait is true if the page generated using the fo:conditional-page-master-reference has the specified position in the sequence of pages generated by the referencing page-sequence; namely, "first", "last", "only" (both first and last), "rest" (not first nor last) or "any" (all of the previous) or a number equal to the page number (or the number within the page cycle). The referencing page-sequence is the fo:page-sequence that referenced the fo:page-sequence-master from which this fo:conditional-page-master-reference is a descendant.
The sub-condition corresponding to the odd-or-even trait is true if the value of the odd-or-even trait is "any" or if the value matches the parity of the page number of the page generated using the fo:conditional-page-master-reference.
The sub-condition corresponding to the blank-or-not-blank trait is true, if (1) the value of the trait is "not-blank" and the page generated using the fo:conditional-page-master-reference has areas generated by descendants of the fo:flow formatting objects; if (2) the value of the trait is "blank" and the page generated using the fo:conditional-page-master-reference is such that there are no areas from any fo:flow to be put on that page (e.g., (a) to maintain proper page parity due to (i) a break-after or break-before value of "even-page" or "odd-page" or (ii) at the start or end of the page-sequence or (b) because the constraints on the areas generated by descendants of the fo:flow formatting objects would not be satisfied if they were descendant from this page); or if (3) the value of the trait is "any".
Note:
A "blank page" is a page generated under (2) of the sub-condition corresponding to "blank-or-not-blank" above. This has nothing to do with whether the page appears completely blank to the reader.
Contents:
EMPTY
The following properties apply to this formatting object:
master-reference; page-position; odd-or-even; blank-or-not-blank
<fo:page-sequence-master master-name="name"> <fo:repeatable-page-master-alternatives sequence-repeats="4"> <conditional-page-master-reference page-position="1" master-reference="page-1-of-4"/> <conditional-page-master-reference page-position="2" master-reference="page-2-of-4"/> <conditional-page-master-reference page-position="3" master-reference="page-3-of-4"/> <conditional-page-master-reference page-position="4" master-reference="page-4-of-4"/> </fo:repeatable-page-master-alternatives> <fo:page-sequence-master>
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.17
Be able to treat two facing pages (a two page spread) as a single unit. For example to allow images to cross the page boundaries.
Common Usage:
Used to define a two-page spread consisting of an even and odd page facing each other. The fo:spread-page-master refers to fo:simple-page-masters for the geometries of the pages and the definition of the pages' regions. The fo:spread-page-master may define additional regions that may be generated on one of the pages or may span both pages in the spread.
Areas:
The fo:spread-page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence.
When the fo:spread-page-master is used to generate pages, three viewport/reference pairs are generated, consisting of a spread-viewport-area and a spread-reference-area for the spread plus a page-viewport-area and a page-reference-area for each of the two pages. The page-viewport-areas represents the physical bounds of the output medium. The page-reference-areas represents the portion of the pages on which content is intended to appear; that is, the area inside the page margins.
When the "binding-edge" trait is "top", the two pages are generated such that the after-edge of the even page is adjacent to the before-edge of the odd page.
In addition, when the fo:spread-page-master is used to generate pages, viewport/reference pairs that correspond to the regions that are the children of the fo:spread-page-master are also generated. These regions are placed relative to the page-height and the page-width of the spread-viewport-area.
When a regions that is a child of the fo:spread-page-master has the same "region-name" as a region that is a child of the fo:simple-page-master for the even- or odd-page, only the child of the fo:spread-page-master generates areas.
Regions that are children of the fo:spread-page-master may span the two pages.
Constraints:
When a fo:spread-page-master is used in the generation of a spread, the block-progression-dimension and inline-progression-dimension of the content-rectangle of the spread-viewport-area are determined using the computed values of the "page-height" and "page-width" properties of the page-masters for the two pages and the "binding-edge" property of the fo:root.
If the value of the media-usage trait is bounded-in-one-dimension or unbounded, only the even-page single-page-master-reference is used.
Contents:
(single-page-master-reference, single-page-master-reference, region*)
The following properties apply to this formatting object:
master-name; writing-mode
Pagination FOs introduction, Currently http://www.w3.org/TR/xsl11/#pag-intro.
*-master-reference FOs
Depends on:
binding edge.
Note:
"page-viewport-areas" no longer represent the physical bounds of the output medium.
Open issue: 7569
What should retrieve-index-mark do for index hits on a double-page spread?
Requirement:
See the XSL-FO 2.0 Requirements Document, section 2.2.18
Add support for bleeds. For example, bleeds allow an image to go beyond the page boundaries so that when you print, bind and cut the paper you don’t have any white space showing.
The bleed is expressed at the page level and identifies the amount of content printed outside the page. The design is responsible for creating and placing content that goes into the bleed, for instance a larger background image or an absolutely positioned image. The trim indicates the correct page size after the trimming (cutting) has been applied. It could be the same as the page size but can also be slightly bigger for binding purposes.
Two properties on the fo:simple-page-master control bleed and trim
bleed-box,
trim-box
XSL Definition:
Value: | x1 y2 x2 y2 |
---|---|
Initial: | 0 0 0 0 |
Applies to: | page reference area |
Inherited: | no |
Percentages: | Not applicable. |
Media: | paged |
The bleed-box property defines the size and position of a notional rectangle around the page in which ink might appear: an implementation should not normally render any content outside the bleed box, although it is not an error conition if content is placed there. The primary purpose of the bleed box is so that when a trimming machine cuts the printed page to size, graphics or other content can go all the way to the edge of the page, by virtue of being printed slightly beyond the place where the blade cuts. Hence, the trim box, whose size and position is specified by the trim-box property, is usually inside the bleed-box.
The values are as follows:
A relative offset from the page reference area origin, used to position the origin of the bleed and trim boxes, respectively. The coordinate system is the same as for the page reference area. The numbers are disances, may be negative.
Relative offsets from the corner of the page reference area that is diagonally opposite to its origin; if x1, y1, x2 and y2 are all zero (the default values) the rectangle will thus be the same size as, and in the same position as, the page reference area. The numbers are disances, may be negative.
Open issue
We also need to add these to "fo:page-master" when that is defined. [no bugzilla entry for this item]
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.1.1
This may include SVG font capabilities, such as referring to an external font pointed to with a URI, or being able to define fonts like SVG fonts.
In preparation. The XSL-FO Subgroup wants to align with CSS, SVG and with the emerging consensus on Web fonts for downloadable font support, and to see what font properties will be available. A future draft of this document is likely to contain a more detailed section here.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.2
Allow users to force line justification when the line length is within a certain range. For example, normally the last line of a paragraph would not be justified, but if the last line is longer than a certain threshold, justify it anyway.
last-line-minimum-deficit
XSL Definition:
Value: | <length> | <percentage> | inherit |
---|---|
Initial: | 0pt |
Applies to: | fo:block |
Inherited: | yes |
Percentages: | refer to width of containing block |
Media: | visual |
The last-line-minimum-deficit property specifies a length (x) for the minimum line length deficit for the last line-area of a block-area. More precisely, it specifies a constraint on the last line-area child of the last block-area L generated and returned by the formatting object, such that the inline-progression L is either equal to the available width (w) in the inline-progression-dimension (as the term is used in the "justify" value of "text-align"), or is less than or equal to w minus x.
Values for the property have the following meaning:
The minimum line length deficit is a fixed length.
The minimum line length deficit is a percentage of the containing block width.
The value must not be negative.
hyphenation-permitted-minimum-deficit
XSL Definition:
Value: | <length> | <percentage> | inherit |
---|---|
Initial: | 100% |
Applies to: | all elements |
Inherited: | yes |
Percentages: | refer to width of containing block |
Media: | visual |
This property specifies a length (x) for the hyphenation margin for a block. More precisely, it specifies a limitation on the effect of a "hyphenate" value of "true"; hyphenation may be used in the line-breaking algorithm within a given line-area when otherwise the inline-progression-dimension of the line area would be less than the available width in the inline-progression-dimension by an amount greater than x.
Values have the following meanings:
The permitted minimum deficit is a fixed length.
The permitted minimum deficit is a percentage of the containing block width.
The value must not be negative.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.3
Add properties to specify what the alignment should be for the 'last line before a break' and the 'first line after a break'.
text-align-before-break
XSL Definition:
Value: | relative | start | center | end | justify | inside | outside | left | right | inherit |
---|---|
Initial: | relative |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
This property describes how inline content of the last line before a break is aligned.
Values have the same meanings as in the definition of "text-align-last".
text-align-after-break
XSL Definition:
Value: | relative | start | center | end | justify | inside | outside | left | right | inherit |
---|---|
Initial: | relative |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
This property describes how inline content of the first line after a break is aligned. Values have the same meanings as in the definition of "text-align-last".
hanging-punctuation
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.4
Add support for hanging punctuation, both for western [and] non-western languages.
XSL Definition:
Value: | none | <list of characters> |
---|---|
Initial: | none |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
This property describes which characters are allowed to hang outside the margins.
Note:
This should refer to a "list of characters" datatype, which we have not yet defined.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.4
Add support for tabs and tab stops that people are used to from word processors. The main requirement for this seems to be compatibility with other formats, mainly word processor formats.
tab-stops
XSL Definition:
Value: | list of pairs of { left | right | center | decimal } and <length> |
---|---|
Initial: | empty list |
Applies to: | all elements |
Inherited: | yes |
Percentages: | refer to width of nearest ancestor reference-area |
Media: | visual |
This property specifies a sequence of tab stop locations relative to the content-rectangle of the closest ancestor reference-area.
Note:
Need to specify overflow and interaction between wide content and tab stops.
Each symbol, length pair in the list has the following meaning:
A left tab stop is set at the given location.
A right tab stop is set at the given location.
A center tab stop is set at the given location.
A decimal tab stop is set at the given location. The character value to be aligned is specified by the tab-alignment-character property.
The lengths must not be negative.
Note:
Decimal/character alignment needs to be the same as proposed for tables.
Note:
At this stage of work, we are using the terms left and right rather than start and end.
word-spacing-critical-length
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.6.3
Allow users to specify the priority between word and letter spacing.
XSL Definition:
Value: | <length> |
---|---|
Initial: | 0pt |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
This property specifies a length (x) for the word spacing to allow before invoking letterspacing. More precisely, it specifies a limitation on the effect of a "letterspacing" value; letterspacing may be used in the line-breaking algorithm within a given line-area when otherwise the word-spacing value would be greater than x.
Values have the following meanings:
The permitted minimum deficit is a fixed length.
The value must not be negative.
hyphenation-push-syllable-count
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.7.1
Allow specifying the number of syllables in addition to the number of characters to control hyphenation.
XSL Definition:
Value: | <number> |
---|---|
Initial: | 1 |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
The "hyphenation-push-syllable-count" property specifies the minimum number of syllables permitted in a hyphenated word after the hyphenation character. Formatters must not insert hyphens during line breaking in places that would result in word fragments violating this proerty.
Values have the following meanings:
A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.
hyphenation-remain-syllable-count
XSL Definition:
Value: | <number> |
---|---|
Initial: | 1 |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
The hyphenation-remain-syllable-count specifies the minimum number of syllables in a hyphenated word before the hyphenation character. This is the minimum number of syllables in the word left on the line ending with the hyphenation character.
Values have the following meanings:
A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.
syllable-widows
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.7.2
Add syllable level widow and orphan controls
XSL Definition:
Value: | <number> |
---|---|
Initial: | 1 |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
The "syllable-widows" property specifies the minimum number of syllables in the last line-area of a block-area.
Values have the following meanings:
A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.
The syllable-widows specifies the minimum number of syllables in the last line-area of the block-area for which it is in effect.
hyphenation-exceptions
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.7.3
Allow users to specify language-specific hyphenation exceptions.
XSL Definition:
Value: | <uri-specification> | none | inherit |
---|---|
Initial: | none |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
This property specifies a set of hyphenation-exception words to be used by the hyphenation algorithm.
Values for this property are as follows:
No exceptions are used.
A URI specification giving a reference to the resource containing the exception words.
Note:
We have not defined a format for this resource.
word-widows
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.7.5
Add word level widow and orphan control.
XSL Definition:
Value: | <number> |
---|---|
Initial: | 0 |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
The "word-widows" property specifies the minimum number of words or partial words in the last line-area of a block-area.
When a word is hyphenated, the remaining portion, a partial word, brought down onto the next line, is to be considered to be a whole word for the purpose of counting words.
Values have the following meanings:
A positive integer. If a non-positive or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.
The permitted minimum deficit is a percentage of the containing block width.
The "word-widows" property specifies the minimum number of words in the last line-area of the block-area for which it is in effect.
min-length-of-last-line
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.7.6
Be able to specify the minimum length of the last line.
XSL Definition:
Value: | <length> |
---|---|
Initial: | 1 |
Applies to: | all elements |
Inherited: | yes |
Percentages: | refer to width of containing block |
Media: | visual |
The min-length-of-last-line
property
specifies the minimum inline-progression-dimension of the the last
line-area in a block-area.
Values have the following meanings:
Specifies a fixed minimum line length.
The minimum line length is a percentage of the containing block width.
The value must not be negative
Requirement:
See the XSL-FO 2.0 Requirements Document, section 6
Improve support for non-Western languages, such as Mongolian, Indic languages, Thai, Japanese, Chinese, etc. The working group invites language experts to identify language specific features that are currently not yet supported by XSL.
Specifically, the Japanese Layout Taskforce has published a document about requirements for general Japanese layout realized with This draft, then, technologies like CSS, SVG and XSL-FO [Requirements for Japanese Text Layout]. This document is being used as an input to the XSL Working Group as a source of requirements, and is currently being discussed within the Group.
The XSL-FO task force is monitoring the Japanese Layout Task Force work closely, and has participated in meetings.
Open issue: 7570
Should there be a list of image formats that MUST be supported, e.g. PNG?
Requirement:
See the XSL-FO 2.0 Requirements Document, section 7.3
Allow rotating images over arbitrary angles.
XSL-FO can already do this for multiples of 90 degrees; other angles are awaiting completion of the shaped areas work in this document, because if you rotate a rectangle by an angle that is not a multiple of 90 degrees, you get a diamond, and this specification does not (yet) handle non-rectangular inline objects.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 7.4
Add support for callouts. Callouts are labels in a picture, overlaying text on top of a graphic (which typically needs to be translatable). Allow users to make live links from the image or map to the text and vice versa.
For callouts, e.g. adding captions to an image, with arrows pointing to the text, one approach that makes sense here is to use SVG, remembering that allowing fo:blocks inside the SVG may fall out of the work with SVG.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 7.5
Add support for access to individual images in multi-page image formats such as TIFF, PDF or SVG 1.2.
This may be a case of wanting a URI fragment identifier for a specific page of a PDF, or layer of TIFF; for SVG this is a liaison item. If a media type doesn't define a fragment type, we could add an extra property.
Open issue: 7571
What if you don't know in advance how many layers there are in advance in, say, a TIFF image, and want to print them all as pages?
Requirement:
See the XSL-FO 2.0 Requirements Document, section 9.6
Improved color support including things that SVG Print does. For example add device-specific CMYK color. Add support for the color names that are supported in SVG. Fills/Shading/Vignettes.
A function is added to support calibrated CMYK colors:
color cmyk-ICC-color(r, g, b, NCName, cyan, magenta, yellow, black)
Two functions are added to support the direct specification of the cartesian and polar forms of the CIE L*ab color space:
color cie-lab-color(r, g, b, Lightness, a-value, b-value) color cie-lchab-color(r, g, b, Lightness, chroma, hue)
A function is introduced to support named-icc-colors (e.g. Pantone™).
color rgb-named-color(r, g, b, NCName, namedColor)
Four new functions are added to support device-dependent (uncalibrated) color (e.g. calibration swatches, registration marks).
color gray-device-color (r,g,b, devGray) color rgb-device-color (r,g,b, devR, devG, devB) color cmyk-device-color (r,g,b, devC, devM, devY, devK)
A conformance class is introduced for implementations which correctly process color managed colors (i.e. do not rely on the fallback colors).
A conformance class is introduced for implementations which correctly process color managed images (i.e. apply, or pass through to a formatter, any embedded ICC profile).
Requirement:
See the XSL-FO 2.0 Requirements Document, section 10
For XSL-FO 2.0 we want to have a close collaboration between the XSL and SVG working groups. Wherever possible we will try to use SVG functionality rather than reinventing our own.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 10.1
Add support for applying a mask (or clip shape) to an object.
Masks in SVG are only applied to viewports. It would be a good practice to do the same and apply it only to block-containers or regions. Masks are declared in the defs space in SVG and then referenced. This enables re-use and complex effects (e.g. Mask with Gradient and so on...)
The approach is to introduce an fo:mask object inside the fo:declarations that contains a valid SVG document providing the mask definition. An XSL-FO renderer can then use an SVG agent to compute the mask and then apply it to the FO rendering result.
<fo:root xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <fo:declarations> <fo:mask mask-name="myFOMask" content-type="image/svg" content-reference-id="svg:mask[@id='svgMask']"> <svg:svg width="8cm" height="3cm" viewBox="0 0 800 300" version="1.1"> <svg:desc>Example mask01 - content masked with gradient against red background</svg:desc> <svg:defs> <svg:linearGradient id="Gradient" gradientUnits="userSpaceOnUse" x1="0" y1="0" x2="800" y2="0"> <svg:stop offset="0" stop-color="white" stop-opacity="0" /> <svg:stop offset="1" stop-color="white" stop-opacity="1" /> </svg:linearGradient> <svg:mask id="svgMask" maskUnits="userSpaceOnUse" x="0" y="0" width="800" height="300"> <svg:rect x="0" y="0" width="800" height="300" fill="url(#Gradient)" /> </svg:mask> </svg:defs> ... </svg:svg> </fo:mask> </fo:declarations> ... <fo:block-container mask-reference-name="myFOMask"> ... </fo:block-container> ... </fo:root>
Requirement:
See the XSL-FO 2.0 Requirements Document, section 10.2
Support rotations on any type of object (not just images) over arbitrary angles.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 10.3
Allow applying SVG type transformations to XSL areas.
An SVG-like transform function is introduced for all sort of operations emulating what SVG and PPML do ([SVG], [PPML]) as a property, on "fo:block-container", with the following functions as values:
standard CTM matrix;
move the origin;
resize;
rotate about the origin;
shear by distorting horizontally;
shear by distorting vertically.
The behaviour can be completely inherited from SVG [SVG].
Open issue: 7572
Some Web browsers support transform and translate functions in CSS, but do not account for the resulting shape in page layout! We need to see what the correct CSS behaviour should be, and/or align with one or other spec; [it is most useful for the resulting shape to be able to create intrusions, especially if we use layers and z-axis to manage conflicts, so you can choose whether or not to have an intrusion].
Since 2009-09-29:
Added 2.2.12.2, change master every n pages
Added non-rectangular shapes
Added copyfitting
Added list of properties
Clarified word-widow definition
Several new issues linked to bugzilla, and others made into notes.
Various editorial changes
The following properties are defined in this document, or were defined in XSL-FO 1.1 and are modified here.
The bleed-box property defines the size and position of a notional rectangle around the page in which ink might appear: an implementation should not normally render any content outside the bleed box, although it is not an error conition if content is placed there. The primary purpose of the bleed box is so that when a trimming machine cuts the printed page to size, graphics or other content can go all the way to the edge of the page, by virtue of being printed slightly beyond the place where the blade cuts. Hence, the trim box, whose size and position is specified by the trim-box property, is usually inside the bleed-box.
When this property is set and non-zero, the block progression dimension of each generated area must be rounded up to the nearest multiple of the property value.
This property is used to copyfit text into a region and to define strategies for copyfitting.
Specifies how to align the last column of a multi-column region. This property specifies the alignment, in the block-progression-direction, of the areas that are the children of a reference-area.
Specifies the distance between the edge of the region-body and the edge of the extension region to which it applies.
"Force-page-count" is used to impose a constraint on the number of pages in a page-sequence. In the event that this constraint is not satisfied, an additional page will be added to the end of the sequence. This page becomes the "last" page of that sequence.
This property describes which characters are allowed to hang outside the margins.
This property specifies a set of hyphenation-exception words to be used by the hyphenation algorithm.
This property specifies a length (x) for the hyphenation margin for a block. More precisely, it specifies a limitation on the effect of a "hyphenate" value of "true"; hyphenation may be used in the line-breaking algorithm within a given line-area when otherwise the inline-progression-dimension of the line area would be less than the available width in the inline-progression-dimension by an amount greater than x.
The "hyphenation-push-syllable-count" property specifies the minimum number of syllables permitted in a hyphenated word after the hyphenation character. Formatters must not insert hyphens during line breaking in places that would result in word fragments violating this proerty.
The hyphenation-remain-syllable-count specifies the minimum number of syllables in a hyphenated word before the hyphenation character. This is the minimum number of syllables in the word left on the line ending with the hyphenation character.
The initial-cap-indent property distance (either as an absolute value or as a percentage of the actual formatted initial cap width) by which the initial is indented in the inline progression direction.
The "initial-cap-kern-lines" property indicates the number of lines of text that should be abutted to the large intial.
This property specifies the number of lines spanned by the initial letter.
The "initial-cap-lines-before" property indicates that the initial is to be formatted at a size such that it protrudes in the block-progression-direction to the given distance or number of lines.
Specifies a list of properties whose values can be adjusted in order to do vertical justification.
The last-line-minimum-deficit property specifies a length (x) for the minimum line length deficit for the last line-area of a block-area. More precisely, it specifies a constraint on the last line-area child of the last block-area L generated and returned by the formatting object, such that the inline-progression L is either equal to the available width (w) in the inline-progression-dimension (as the term is used in the "justify" value of "text-align"), or is less than or equal to w minus x.
Specifies the marginalia-reference-area in which to place the block-areas generated by the child fo:marginalia-body to which it applies.
Specifies the alignment of the marginalia with respect to the text to which it refers. This property specifies the alignment, in the block-progression-direction, between two areas.
The min-length-of-last-line
property
specifies the minimum inline-progression-dimension of the the last
line-area in a block-area.
This property forms part of a selection rule to determine if the referenced page-master is eligible for selection at this point in the page-sequence or, when the "sequence-repeats" property value is not "no-limit", at this point in the sub-sequence cycle.
Specifies the number of pages in a cyclic sub-sequence of pages that may be generated before the cycle repeats.
The "syllable-widows" property specifies the minimum number of syllables in the last line-area of a block-area.
This property specifies the character used for alignment for a decimal tab.
This property specifies a sequence of tab stop locations relative to the content-rectangle of the closest ancestor reference-area.
This property describes how inline content of the first line after a break is aligned. Values have the same meanings as in the definition of "text-align-last".
This property describes how inline content of the last line before a break is aligned.
The bleed-box property defines the size and position of a notional rectangle around the page in which ink might appear: an implementation should not normally render any content outside the bleed box, although it is not an error conition if content is placed there. The primary purpose of the bleed box is so that when a trimming machine cuts the printed page to size, graphics or other content can go all the way to the edge of the page, by virtue of being printed slightly beyond the place where the blade cuts. Hence, the trim box, whose size and position is specified by the trim-box property, is usually inside the bleed-box.
This property specifies a length (x) for the word spacing to allow before invoking letterspacing. More precisely, it specifies a limitation on the effect of a "letterspacing" value; letterspacing may be used in the line-breaking algorithm within a given line-area when otherwise the word-spacing value would be greater than x.
The "word-widows" property specifies the minimum number of words or partial words in the last line-area of a block-area.
Use the "wrap" property to specify flow run-around.
When two or more shaped areas interact, the "wrap-path" property determines how text and other inline objects in one area flow around the shape of the other area.
The "wrap-side" property indicates what strategy should be applied for the runaround.
This specification was developed and approved for publication by the W3C XSL Working Group (WG). WG approval of this specification does not necessarily imply that all WG members voted for its approval.
During the development of XSL 2.0 the members of the XSL FO Subgroup were:
Sharon Adler, IBM; Klaas Bals, Inventive Designers; Anders Berglund, IBM; Jeff Caruso, Pageflex; Fabio Giannetti, HP; Tony Graham, Menteith Consulting; Paul Grosso, PTC-Arbortext; Angelo Di Iorio, University of Bologna; Xin (Edward) Jiang, (Oracle, and then Microsoft); Liam Quin, W3C; Zarella Rendon, PTC-Arbortext.
In addition, many members of the public, including users and implementors, have given useful feedback in he form of comments.