Copyright © 2009 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 First Public Working Draft containing notes for an eventual XSL-FO 2.0 Recommendation. The XSL Working Group has spent a lot of time working on non-rectangular page regions. Since this work-in-progress was not public, and since there is still a lot of work to be done, the Working Group decided to focus for a while on other areas of the Requirements [XSL 2.0 Requirements]. This draft, then, reflects those other areas, but does not include the work on non-rectangular regions and new page masters. 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 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 Initial Caps
2.1.1 Initial Caps
2.1.1.1 initial-cap-lines
2.1.1.2 initial-cap-lines-before
2.1.1.3 initial-cap-kern-lines
2.1.1.4 initial-cap-indent
2.2 Marginalia
2.2.1 Extension Regions
2.2.1.1 The extension-region-start Region
2.2.1.2 The extension-region-end Region
2.2.1.3 distance
2.2.2 Formatting Objects for Marginalia
2.2.2.1 fo:marginalia
2.2.2.2 fo:marginalia-body
2.2.2.3 marginalia-destination-area
2.2.2.4 marginalia-relative-align
2.3 Vertical Positioning
2.3.1 Feathering
2.3.1.1 justify-by-modifying
2.3.2 Correlating vertical position
2.3.2.1 block-progression-unit
2.3.3 Vertical alignment within a page or column
2.3.4 Vertical alignment specific for the last column
2.3.4.1 display-align-last-column
2.3.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 Considerations
3.2.1.1 Considerations
3.2.2 Repeat contents of split spanned cell
3.2.3 Cell borders extending beyond the table
3.2.3.1 3.5.1 Considerations
3.2.4 Adjacent borders
3.2.5 Borders on break
3.2.6 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.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 References
A.1 Normative References
A.2 Other References
B 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.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 1 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:
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 blog-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.
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 2 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 2. 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
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 1, 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.
XSL Definition:
| Value: | <length> | <percentage> | auto | inherit |
| Initial: | 0pt |
| Applies to: | fo:inline |
| Inherited: | yes |
| Percentages: | refer to width of enlarged glyph |
| Media: | visual |
Since the exact size of the initial must be computed by the formatter, a trait is used to control its positioning, as the distance for an indent cannot in general be known in advance. The "initial-cap-indent" is most often 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.
The value must not be negative.
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 3 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.
Open issue
The specification will need to handle non-rectangular regions too here; this is work in progress. [no specific bugillz 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.
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-viewpot-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.
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.
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.
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.
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).
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.
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.
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 FOs 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.
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.
Should other values of "overflow" property to allowed for the "table-overflow" property, e.g. "visible", "hidden", "scroll", and "error-if-overflow"?
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?
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
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
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.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
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 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. The next 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.
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.
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'.
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".
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".
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 refers 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.
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.
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.
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.
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 |
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 hyphenation-push-syllable-count specifies the minimum number of syllables in a hyphenated word after the hyphenation character. This is the minimum number of syllables in the word pushed to the next line after the line ending with the hyphenation character.
XSL Definition:
| Value: | <number> |
| Initial: | 1 |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
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 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.
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.
Requirement:
See the XSL-FO 2.0 Requirements Document, section 5.7.3
Allow users to specify language-specific hyphenation exceptions.
XSL Definition:
| Value: | lt;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 either <uri-specification>, to specify a resource containing the exception words, or "none", when no exceptions are used.
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.
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: | 1 |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
The "word-widows" property specifies the minimum number of words 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 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.
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 is creating a document about requirements for general Japanese layout realized with technologies like CSS, SVG and XSL-FO. The document is currently in draft stage and is being developed further by the Japanese participants in the task force. This document will be an input to the XSL working group as a source of requirements.
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 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 [TODO add bibref to ppml.podi.org], 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.
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].
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, Microsoft; Liam Quin, W3C.
