XSL Requirements Version 2.0

2.1.1 Animations

Add support for animations

2.1.2 Advanced images

Cropping and scaling images, including bleed and non-rectangluar cropping. It should also be possible to specify how the image should interact with things such as baseline, for example for mathematical formulas.

2.1.3 Kerning and ligatures

Allow to specify constraints to control kerning and ligatures.

2.1.4 Non-rectangular areas

Add support for non-rectangluar areas.

2.1.5 Rounded corners

Add support for rounded corners.

2.1.6 Border styles

Add support for more border styles.

2.1.7 Runarounds

Runarounds (text flowing around illustrations, regions and other objects, with non-rectangluar shapes). This is related to non-rectangular areas.

2.1.8 Color support

Improved color support. E.g. add device-specific CMYK color, Fills/Shading/Vignettes, Masks, Opacity. Add support for the color names that are supported in SVG.

2.2.1 Copyfitting

Add support for copyfitting. E.g. to shrink or grow content (change properties of text, line-spacing, rotation, ...) to make it constrain to a certain area, or provide alternative content when the original content doesn't fit. This is going to be managed by a defined set of properties, that list of going to be defined.

2.2.2 Values of properties

Add support for getting the formatting properties associated to the area as opposed to the content. E.g. specify that the width of a formatting object is equal to the width of another formatting object. This also involves inheritance of properties down the area tree (as opposed to the formatting object tree in previous versions of XSL).

2.2.3 Footnotes

Add support for specifying the fontsize of footnotes to be taken from the area tree, instead of from the formatting object tree.

2.2.4 Properties of parts of areas

Add support for specifying the properties on the specified number of lines or certain parts in areas, e.g. the first 5 cm of the area should be in bold.

2.2.5 Expression Language

Modify the expression language to allow expressions that are only computable at a very late stage.

Allow to calculate expressions and output their result on area tree, traits, markers or text content. E.g. to calculate the subtotal of a certain page (as opposed to a running total that is already supported in XSL 1.1 with table markers.

2.4.1 Fonts

2.4.2 Initial Caps

Add support for initial caps, more specifically for dropped and raised caps.

Editorial note: Klaas Bals
Shouldn't we also mention adjacent caps? . Some links with images: raised caps , dropped caps , adjacent caps and some more information that could be useful when determining the properties related to initial caps.

2.4.3 Hanging punctuation

Add support for hanging punctuation, both for western as non-western languages.

2.4.4 Tabs and tab stops

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.

<fo:block fo:tab-stops="left:108.0pt:space left:252.0pt:space left:360.0pt:space">...</fo:block>

2.4.4.2 Sample snippet for tabs: Alternative 1

For specifying a tab, one could use an element called fo:tab

<fo:tab font-size="12.0pt" font-family="Times New Roman"/>

Notice that it has general fo:inline properties associated to it, because such information need to be preserved when the output is RTF.

Also, when xdofo:tab-stops attribute is not present, xdofo:tab uses the default tab stop setting, e.g. tab-stop-style is "left", tab-width is 0.5in, tab-style is space.

When rendering the following snippet:

<fo:block xdofo:tab-stops="left:108.0pt:dots left:252.0pt:rule left:360.0pt:hyphen" text-align="start" padding-top="0.0pt" end-indent="5.4pt" padding-bottom="0.0pt" height="0.0pt" widows="2">
  <fo:inline height="13.392pt" font-family="Times New Roman" white-space-collapse="false" font-size="12.0pt">Tab0</fo:inline>
  <fo:tab font-size="12.0pt" font-family="Times New Roman"/>
  <fo:inline height="13.392pt" font-family="Times New Roman" white-space-collapse="false" font-size="12.0pt">Tab1</fo:inline>
  <fo:tab font-size="12.0pt" font-family="Times New Roman"/>
  <fo:inline height="13.392pt" font-family="Times New Roman" white-space-collapse="false" font-size="12.0pt">Tab2</fo:inline>
  <fo:tab font-size="12.0pt" font-family="Times New Roman"/>
  <fo:inline height="13.392pt" font-family="Times New Roman" white-space-collapse="false" font-size="12.0pt">Tab3</fo:inline>
</fo:block>

this would lead to the following result:

<fo:leader leader-length="tab-stop"/>

2.4.5 Alignment and justification

2.4.6 Word and letter spacing

2.5.1 Number of syllables

Allow to specify the number of syllables in addition to the number of characters to control hyphenation.

2.5.2 Hyphenation exceptions

Allow specifying language-specific hyphenation exceptions. This could for example be done by providing a pointer (e.g., <uri-specification>) to a list of language-specific hyphenation exceptions.

Editorial note: Klaas Bals
This requirement originates from Paul Grosso, in his email at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0003 . http://www.arbortext.com/namespace/XslFoExtensions/ati-xsl-fo-extensions.html#hyphenation contains some markup of XSL-FO extensions from Arbortext.

2.5.3 Line breaks without hyphen character

Allow the specification of a set of characters after which the composition process may introduce a line break without inserting a hyphen character.

Editorial note: Klaas Bals
This requirement originates from Paul Grosso, in his email at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0003 . http://www.arbortext.com/namespace/XslFoExtensions/ati-xsl-fo-extensions.html#hyphenation contains the documentation of the hyphenation XSL-FO extensions from Arbortext.

2.5.4 Word widows

Add word level widow and orphan control. For example, don't allow single word, 3 words, etc. on a single line or at the start of page.

2.6.1 Leading and feathering

Add support leading, including feathering, to vertically adjust lines.

2.6.2 Optical Vertical Alignment

Add support for optical vertical alignment so that lines of two adjacent pages, columns or regions are visually next to each other.

Editorial note: Klaas Bals
This could for example be done by adding a new value "round-to-line-height" to the "block-progression-dimension" property, or alternatively to add a new value "synchronized" to the "line-stacking-strategy" property. These specifics were suggested by Werner Donne

2.6.3 Vertical justification across pages and columns

Allow adjusting line spacing between lines to do vertical justification across pages, or within columns.

Editorial note: Klaas Bals
Shouldn't we do vertical justification across regions?

2.7.1 Label spacing

Add support to control label spacing in lists.

2.7.2 Decimal alignemnt

To improve decimal alignment, extend the character alignment in table cells to permit a specification of the position of the alignment point when using the text-align propery with the value <string>; for example via a text-align-position property on fo:table-column with values <length>|<percentage>|inherit

2.7.3 Table header/footer on bounaries

Be able to specify different instances of what the table header or footer should be depending on the different boundaries (page, column, region) etc.

2.7.4 Split tables

Allow to split tables horizontally, also with a column header that is repeated. There should be a way to keep them visually next to each other depending on binding edge.Repeat top row also on second page.

Editorial note: Klaas Bals
Comment 22 has a faily detailed proposal for this.

2.7.5 Adjacent borders

When two tables are contiguous, be able to specify what to do with their adjacent borders.

2.8.1 Additional numbering

Add support for line number, column number and region number.

2.8.2 Cross-references

Add more intelligent cross references to page numbers that can place the text 'see above on this page' or 'see opposite page'. This should also allow to refer to a region on a page (e.g. near the top, bottom etc.).

2.8.3 Calculations with page numbers

It should be possible to do calculations with page numbers.

2.8.4 Page numbers

More control should be possible over the page numbers, for example to have multiple series of page numbers in the whole documents or to specify that page numbers should not increment on certain pages (for example the backside containing the 'conditions of sale' shouldn't be numbered).

2.8.5 Z-index

Improve absolute position, layering and positioning by extending the Z-index property so that it can cross formatting object boundaries.

2.8.6 Callouts

Callouts

Editorial note: Klaas Bals
What exactly does this mean? Does anyone have a description and graphic for this?

2.8.7 Region-before and -after

2.8.8 List all markers

The ability to list all markers on the page (e.g. to list all indexterms on the page).

2.8.9 Binding edge

Add support for specifying the binding edge.

2.8.10 Content Driven Adjustable Page Master Layout

Professional authoring environments give designers the possibility of applying fitting strategies to the content. These fitting strategies usually involve either fitting the content to the frame or fitting the frame to the content. When this second option is selected, the frame is either expanded or reduced from its original size and left where formally placed in the document. This is mainly because the page design is intended to be executed by the designer, which will adjust the surrounding elements to best fit the content driven adjusted frame.

Editorial note: Klaas Bals
This requirement originates from Fabio Giannetti's email at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0006.html . I couldn't copy the images from the PDF file properly. Fabio, please send me the images again, if possible in original format, SVG format and PNG format. Thanks.

In the case of automatic rendering, the possibility of fitting the FO region to the content can be as appealing as fitting the content to the region. However it is important that the rendering engine automatically considers the neighbor regions to provide an aesthetically pleasing result.

In order to do this, some extension to the regions could be introduced allowing the expression of spatial relationships between some of the regions. In this way a designer can define the ranges in which the content driven regions can expand or contract and also the required surrounding region adjustments.

This adds the benefit of ensuring a designer controllable result as well as controlling the finite number of steps in computing the possible combinations.

2.8.10.1 Use cases

The content driven adjustable page masters uses the proposed XSL-FO 2.0 complex page master model, using SVG to express non-rectangular regions. An example of facing non rectangular areas can be:

<fo:complex-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-arbitrary region-name="circle" content-type="image/svg+xml" z-index="2"
		width="150pt" height="150pt" top="50pt" left="50pt">
		<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="100%" height="100%">
			<svg:circle cx="240" cy="200" r="200" />
		</svg:svg>
	</fo:region-arbitrary>
	<fo:region-arbitrary region-name="square" content-type="image/svg+xml" z-index="1"
		width="100pt" height="100pt" top="50pt" left="200pt">
		<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="100%" height="100%">
			<svg:rect width="100" height="100" />
		</svg:svg>
	</fo:region-arbitrary>
</fo:complex-page-master>
							

The rendered results is illustrated below.

A first instance of the use case illustrates a small table with two columns. In this situation the content fits perfectly within the assigned region. Increasing the table size by adding more columns, e.g. five, substantially changes the re-flowing capabilities of the content. More horizontal space it is now required.

No matter what the composition engine is trying to do this will produce a horizontal overflow.

If the regions are flexible and they can adjust their size and position relative to each other, the rectangular region can grow in width and the circle region can shift leftwards, thus preserving a similar text runaround ratio.

The resulting effect is illustrated in the figure below.

A possible markup notation to address this behaviour is to leverage the optimum, minimum and maximum subproperties for dimension and/or positions and a function to retrieve dimensions and/or positions from other regions within the page.

The following example illustrates the concept.

<fo:complex-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-arbitrary region-name="circle" content-type="image/svg+xml" z-index="2" width="150pt" height="150pt" top="50pt" left="200pt+(from-region-width('rectangle')-100pt)">
		<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="100%" height="100%">
			<svg:circle cx="240" cy="200" r="100%" />
		</svg:svg>
	</fo:region-arbitrary>
	<fo:region-arbitrary region-name="rectangle" content-type="image/svg+xml" width.optimum="100pt" width.minimum="100pt" width.maximum="200pt" height="300pt" top="50pt" left="50pt" z-index="1">
		<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="100%" height="100%">
			<svg:rect width="100%" height="100%" />
		</svg:svg>
	</fo:region-arbitrary>
</fo:complex-page-master>
						

Every time the content fails to fit a given region, and subsequently produces overflow, the page flexibility mechanism is activated. Another factor to be taken into consideration is the aspect ratio of images. Layout adjustment can be more complex involving than only facing regions and can act according to the width, height, position and run-around effects.

The following figure presents a case with two separate flows and a region containing an image producing a runaround.

If the image changes considerably in size and aspect ratio, the entire design is badly affected.

If the page regions can adjust their sizes and reposition themselves, it is possible to obtain a neater result, as shown in the next illustration

The region has resized itself following the image content size and it has maintained the relative center of the original region.

A possible mark-up notation to achieve this can be:

<fo:region-arbitrary region-name="image-region" content-type="image/svg+xml" z-index="2" width="from-content-width()" height="from-content-height()" top="10pt+(from-content-height() div 2)" left="90pt+(from-content-width() div 2)">
	<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="100%" height="100%">
		<svg:rect width="100%" height="100%"/>
	</svg:svg>
</fo:region-arbitrary>

The proposed solution can be achieved by introducing in the format two new types of functions. The first type gather sizes from the region content itself meanwhile the second enables a cross reference between regions within the page. In addition, a concept of min, max and optimum can be leveraged, from existing paradigms, to provide size ranges.

2.8.11 Columns

2.8.12 Floats

Improve support for floats.

2.8.13 Footnotes

Improve support for footnotes.

2.8.14 Marginalia

2.8.15 page-number-range-citation

Add a page-number-range-citation formatting object, similar to the page-number-citation, but then specifically for citing page ranges. This could make the specification cleaner as it would make the index-page-citation-list essentially the generation of page-number-citation or page-number-range-citation FOs, rather than a combination of page-number-citation and "pairs of page number citations with page range separtors".

Editorial note: Klaas Bals
Eliot Kimber suggested this at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2004Jul/0006 .

2.8.16 Interleaving layout-master-set

Allow layout-master-set in between page-sequences, to improve streaming large XSL-FO instances, with the additional constraint that the full layout-master-set must always be consistent before a page-sequence starts.

2.8.17 Repeatable subsequence specifier

Allow to specify a repeatable subsequence specifier in page sequence masters. This would be a construct to indicate the repetition of an arbitrary collection of sub-sequences (a sort of grouping of page sequence masters that itself has a max-repeats property).

Editorial note: Klaas Bals
Comment 39 of Ken Holman explains the details of this: http://www.w3.org/Style/XSL/Group/2002/10/FO-comments#03JanMar-0025 .

2.8.18 Complex-page-master

Introduce a 'complex page master' that allows more complex page layouts with intruding regions, layering, background content, overlays, etc.

2.9.1 Annotations that appear in output

Add support for adding annotations that appear in the output, e.g. comments or text highlighting in PDF.

2.9.2 PDF base URL

Add support for setting the PDF base URL.

Editorial note: Klaas Bals
Nikolai Grigoriev suggested using xml:base for this, but if I recall correctly this seemed to be the wrong use of xml:base.

2.9.3 Print specific properties

Specifying print specific properties such as input/output trays, duplex/simplex, etc.

2.10.1 inline-container allocation rectangle

Evaluate whether the fo:inline-container should have a different allocation rectangle that in the previous XSL specification.

Editorial note: Klaas Bals
This was discussed in the 2006-05-02 telcon as agenda item 11 .

2.10.2 'Hierarchy'

Evaluate whether the word "hierarchy" in fo:retrieve-marker and fo:retrieve-table-marker make the text hard to read.

Editorial note: Klaas Bals
This was discussed in the 2006-07-18 telcon as agenda item 7 .

2.10.3 Vertical alignement

Clear out things related to vertical alignment. A message of Steve Zilles contains some proposed changes: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Mar/0026

2.10.4 Inheritance of indents

In previous versions of XSL, all properties, including indents were inherited the same, where in some environments it may be more practical to be able to choose where the values come from. Previous comments were sent in by users of XSL, for example see http://www.w3.org/2001/08/28-XSL-PR-DOC.html Comment 20 item 3, as well as http://www.w3.org/Style/XSL/2006/01/xsl11-lc-DoC#05OctDec-0024 .

The working group want to allow users to specify the way that indents are inherited, to be able to support the current behaviour (default inheritance) as well as the other behaviour (no inheritance at reference area boundaries).

2.10.5 Scripts and Baseline Shifts

Improved alignment of scripts and baseline shifts.

Editorial note: Klaas Bals
This requirement comes from the errata dicussions. I was asked to include the full list of links and the history. This list and history is outlined in the minutes of the March 20th 2007 Telcon (Agenda item 5) at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Mar/0023.html

2.11.1 Change pages/List of effective pages (LOEP)

In many military and aircraft manuals it is necessary to generate a list of pages that have changed since the last revision. This list may have to include the LOEP pages themselves. For example, if the LOEP goes from one page to two in the new version, the LOEP must list itself in the list.

Editorial note: Klaas Bals
This requirement originates from Eliot Kimber in his email http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0007.html .

2.11.2 Maintain original page boundaries

In order to be able to do point pages, it is necessary to tell the XSL-FO formatter that is must maintain the original page boundaries, and only generate new pages with new page boundaries when the content becomes too big to fit on an original page. In that case only an additional page must be inserted to fit the 'overflowed content'.

2.11.3 Master index across documents

Creation of a master index across multiple documents, where it's necessary to know what page index entries fall on in order to then generate a new document that is the master index and that reflects page numbers from all the documents to be reflected in the master index.

Editorial note: Klaas Bals
This requirement originates from Eliot Kimber in his email http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0007.html .

2.11.4 Hyperlink management

Hyperlink management where a link management system has to maintain a correlation between elements as authored and their location in different renditions in order to allow the correct rendering of other documents that link to these documents. This is often called the "cross-document xref case" but it's more general than that, but the case where you want to reflect the page number of the reference in the target document is the most obviously compelling.

For example, say we have two publications, Pub1 and Pub2, with an element-to-element hyperlink between Pub1 and Pub2. The desired rendition effect is that in the PDF rendering of Pub1 there is a navigable hyperlink to the rendering of the target element in Pub2 where the link in Pub1 includes the page number of the target in Pub2.

Since in the general case you cannot predict from the link and target as authored what the linking artifacts will be in a given rendition, you must have a way of going from source constructs to their rendered result at rendition time. This means you need some sort of system that manages the correlation between elements as authored and their renderings and the rendition-specific link artifacts needed to create working links to a specific rendition of the target.

In the case of PDF, for example, this means correlating source elements to PDF documents and anchors. Thus, you would expect a link management system to maintain a table like this:

In order to populate this table for a given publication you need to know what the anchor and page number information is, which only the FO renderer knows.

Given this information an XSLT processor can then generate the appropriate linking artifacts in the linking rendition.

This approach provides a complete and general solution to generating and managing cross-publication links that does not need to depend on any sort of conventions or constraints (for example, assuming a one-to-match between input element IDs and target anchors).

Editorial note: Klaas Bals
This requirement originates from Eliot Kimber in his email http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0007.html .

2.12.1 References to CSS

Reduce or eliminate references to CSS from the XSL specification.

2.12.2 Units of measurement

Defining units of measurement in XSL-FO. This can currently already be be done in XSLT or by using XML entities.

2.12.3 MathML

Improve integration with MathML.

2.12.4 Meta data

Specify how meta-data can be attached to individual objects.

2.12.5 Multi-column layout in block-containers

Add support for multi-column layout in block-containers. Currently, only regions can have multiple columns.

2.12.6 xml:base

Add support for xml:base.

Editorial note: Klaas Bals
Nikolai Grigoriev suggested some text for adding support for xml:base to XSL, but if I recall correctly his intention was to support the PDF base URL which seemed to be different from xml:base.

2.12.7 Background-color on change-bar

Add support to specify a background-color on fo:change-bar.

Editorial note: Klaas Bals
Eliot Kimber suggested this.

2.12.8 Block-progression-dimension of generated areas

Allow to specify the maximum block-progression-dimension of the sum generated area's instead of the maximum block-progression-dimension of each generated instance.

2.12.9 Text flow around areas

Allow to have text flow around absolute or relative positioned areas.

2.12.10 Enhanced page master selection

Enhance the page master selection mechanism to support the following requirement related to multiple regions: When having two regions A and B, both layed out next to each other on a single page-master, once flow A is exhausted, go to a different page master that only has B as a region (and vice versa)

2.12.11 Side-by-side

Introduce a way to position objects next to each other. In the current specifications, existing objects such as tables or lists have to be misused to get this behaviour, or inline-container has used but that has the disadvantage that is can not cross boundaries (like pages or columns).

2.12.12 Multi-page images

Add support for access to individual images in multi-page image formats such as TIFF, PDF or SVG 1.2.

2.12.13 Schema for XSL

Provide a schema for XSL-FO.