Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The XSL 1.0 and XSL 1.1 specifications defines the features and syntax for the Extensible Stylesheet Language (XSL), a language for expressing stylesheets. This document enumerates the collected requirements for a 2.0 version of XSL.
Editorial note: Klaas Bals | |
Can we refer to 'XSL-FO' instead of 'XSL'? |
This current Working Draft is an internal Working Group document.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C. This document is the first public XSL 2.0 Requirements working draft.
This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by the W3C membership .
This document has been produced as part of the W3C Style activity , following the procedures set out for the W3C Process. The document has been written by the XSL Working Group ( W3C members only ).
Comments on this document should be sent to the W3C mailing list xsl-editors@w3.org (archived at http://lists.w3.org/Archives/Public/xsl-editors/ ). A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/ .
1 Introduction
1.1 Sample XML and XSL snippets
1.2 Backwards compatibility
2 Detailed requirements
2.1 Integration with SVG
2.1.1 Animations
2.1.2 Advanced images
2.1.3 Kerning and ligatures
2.1.4 Non-rectangular areas
2.1.5 Rounded corners
2.1.6 Border styles
2.1.7 Runarounds
2.1.8 Color support
2.2 Add support for 'layout driven' documents
2.2.1 Copyfitting
2.2.2 Values of properties
2.2.3 Footnotes
2.2.4 Properties of parts of areas
2.2.5 Expression Language
2.3 Further improved non-Western language support
2.4 Improvements related to inline text, alignment, justification etc.
2.4.1 Fonts
2.4.1.1 Improved font support
2.4.1.2 Unicode ranges
2.4.1.3 Opentype Features
2.4.2 Initial Caps
2.4.3 Hanging punctuation
2.4.4 Tabs and tab stops
2.4.4.1 Sample snippet for tab stops
2.4.4.2 Sample snippet for tabs: Alternative 1
2.4.4.3 Sample snippet for tabs: Alternative 2
2.4.5 Alignment and justification
2.4.5.1 Force line justification
2.4.5.2 Controlling spacing with justification
2.4.5.3 Alignment around breaks
2.4.6 Word and letter spacing
2.4.6.1 Exluding characters or unicode classes
2.4.6.2 Mixing scripts
2.4.6.3 Skewing
2.4.6.4 Punctuation Spacing
2.5 Hyphenation and line breaking
2.5.1 Number of syllables
2.5.2 Hyphenation exceptions
2.5.3 Line breaks without hyphen character
2.5.4 Word widows
2.6 Line Spacing
2.6.1 Leading and feathering
2.6.2 Optical Vertical Alignment
2.6.3 Vertical justification across pages and columns
2.7 Improvements related to tables and lists
2.7.1 Label spacing
2.7.2 Decimal alignemnt
2.7.3 Table header/footer on bounaries
2.7.4 Split tables
2.7.5 Adjacent borders
2.8 Improvements related to page layouts, page numbers and positioning on page
2.8.1 Additional numbering
2.8.2 Cross-references
2.8.3 Calculations with page numbers
2.8.4 Page numbers
2.8.5 Z-index
2.8.6 Callouts
2.8.7 Region-before and -after
2.8.7.1 Position region-before or -after content near text
2.8.7.2 Variable-size region-before and region-after
2.8.8 List all markers
2.8.9 Binding edge
2.8.10 Content Driven Adjustable Page Master Layout
2.8.10.1 Use cases
2.8.11 Columns
2.8.11.1 Column balacing depending on page layout
2.8.11.2 Improve column balancing
2.8.11.3 Column spanning
2.8.12 Floats
2.8.13 Footnotes
2.8.14 Marginalia
2.8.14.1 Keep marginalia together with other objects
2.8.14.2 Large marginalia
2.8.14.3 Marginalia lines
2.8.15 page-number-range-citation
2.8.16 Interleaving layout-master-set
2.8.17 Repeatable subsequence specifier
2.8.18 Complex-page-master
2.9 Improvements for specific output formats or devices
2.9.1 Annotations that appear in output
2.9.2 PDF base URL
2.9.3 Print specific properties
2.10 Potential clarifications to previous specification
2.10.1 inline-container allocation rectangle
2.10.2 'Hierarchy'
2.10.3 Vertical alignement
2.10.4 Inheritance of indents
2.10.5 Scripts and Baseline Shifts
2.11 Feedback from pagination stage
2.11.1 Change pages/List of effective pages (LOEP)
2.11.2 Maintain original page boundaries
2.11.3 Master index across documents
2.11.4 Hyperlink management
2.12 Other improvements
2.12.1 References to CSS
2.12.2 Units of measurement
2.12.3 MathML
2.12.4 Meta data
2.12.5 Multi-column layout in block-containers
2.12.6 xml:base
2.12.7 Background-color on change-bar
2.12.8 Block-progression-dimension of generated areas
2.12.9 Text flow around areas
2.12.10 Enhanced page master selection
2.12.11 Side-by-side
2.12.12 Multi-page images
2.12.13 Schema for XSL
3 References
In the current versions of XSL, integration with SVG is limited to using fo:instream-foreign-object or fo:external-graphic. Now we want to add a more profound integration that would allow to use SVG to define non-rectangluar area's, rounder corners, filling patterns, etc...
Currently XSL already provides support for formatting non-Western languages, however some advanced formatting can still not be done. We want to improve support for non-Western languages. For example Japanese Typesetting is described in JIS 4051, and that document is one of the inputs to a possible taskforce.
In XSL 2.0, the Working Group wants to add support for 'layout driven' documents. While producing output, and XSL formatter goes through the process of formatting the document. This process involves many calculations and algorithms, and that process is conceptually described in XSL by constraints and an area tree. Stylesheets for 'layout driven' documents must allow to specify more constraints and conditions involving the area tree, or other calculated values, to be specified.
Editorial note: Klaas Bals | |
We should state something about performance and how long a processor can take to format a document. |
In addition to the changes outline above, the XSL Working Group wants to make various other improvements.
By doing a more profound integration between XSL and SVG, XSL 2.0 will include the following functionalities. Many of these functionalities use SVG expressibility instead of using SVG features directly.
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.
'Layout driven' documents are documents with formatting that typically is not dependent upon the content and its associated markup. Rather it is dependent upon geometry or breakdown of space on a medium, and relationships between those portions of space. Layout-driven documents specify the layout first and then content is assigned to the spaces in the layout. Styling may be applied based on these spaces and generated content may be applied at appropriate breaks, e.g., jumps/continues.
To support 'layout driven' documents, XSL 2.0 will include the following functionalities.
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.
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).
Add support for specifying the fontsize of footnotes to be taken from the area tree, instead of from the formatting object tree.
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.
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.
Improve support for non-Western languages. 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 will be mainly based on a standard for Japanese layout, JIS X 4051. However, it will address also areas which are not covered by JIS X 4051. 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.
This may include CSS font-download as well as SVG font capabilities.
Editorial note: Klaas Bals | |
Make sure we check with Chris Lilley what he meant with fonts related to SVG. |
Editorial note: Klaas Bals | |
Bert Bos sent some email about Embedded OpenType (.eot) Format at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007May/0011.html . This is a specification from Microsoft (they're willing to donate the specificaion) that would allow to do font embedding. |
Give access to opentype features. (initial swash caps, oldstyle figures, ...).
Editorial note: Klaas Bals | |
A good overview (with images) of some opentype features is available at http://msdn2.microsoft.com/en-us/library/ms745109.aspx |
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. |
Add support for hanging punctuation, both for western as non-western languages.
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.
Editorial note: Klaas Bals | |
The email from Edward Jiang at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0004.html explains the extension of Oracle BI publisher to support tabs and tab stops. This message was followed by a thread started at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0011.html . And the email from Klaas Bals at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Jun/0005.html explains why he found that people need tabs and tab stops. |
For defining the tab stops, one could use a property called tab-stops.
<fo:block fo:tab-stops="left:108.0pt:space left:252.0pt:space left:360.0pt:space">...</fo:block>
Notice that the stop values are separated by space, and it follows following syntax: 'tab-stop-style:width:tab-style'
tab-stop-style includes: left, center, right, decimal (based on Microsoft Word's functionality)
tab-style includes: space, dots, middle-dots, hyphen, rule
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:
On http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Apr/0011.html it was proposed to use the following marking to represent a tab:
<fo:leader leader-length="tab-stop"/>
Allow forcing 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 treshold, justify it anyway.
Allow excluding specific characters or unicode classes (for example numerals) from word and letter spacing
Editorial note: Klaas Bals | |
This boils down to proposal #3 in an email from Anders Berglund at http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2007Feb/0003.html |
Add support to control word and letter spacing when mixing scripts.
Editorial note: Klaas Bals | |
We believe there are special rule, for example for Japanese |
Add support for skewing.
Editorial note: Klaas Bals | |
What exactly do we mean by this? Can it be applied on any object, or only text? Does it apply to single lines or to a block as a whole? Does it also modify the angle of the individual characters, or does it just influence the horizontal alignment of the text? How is this related to word an letter spacing? |
The following set of requirements is related to hyphenation. All hyphenation settings need to be language-dependent so that you can set different values for the various languages you use in a given document.
Allow to specify the number of syllables in addition to the number of characters to control hyphenation.
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. |
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. |
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 |
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
Be able to specify different instances of what the table header or footer should be depending on the different boundaries (page, column, region) etc.
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. |
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.).
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).
Improve absolute position, layering and positioning by extending the Z-index property so that it can cross formatting object boundaries.
Callouts
Editorial note: Klaas Bals | |
What exactly does this mean? Does anyone have a description and graphic for this? |
The ability to list all markers on the page (e.g. to list all indexterms on the page).
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.
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.
Editorial note: Klaas Bals | |
On the call we decided this was a column balancing issue, but when reading this, I think it has more to do with enhanced page master selection: depending on the page master you're on, do something else. |
E.g. balance two columns of a three-column layout, but do something else on a four column layout.
Keep marginalia together with other objects, such as blocks or inlines.
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 . |
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.
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 . |
Add support for adding annotations that appear in the output, e.g. comments or text highlighting in PDF.
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. |
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 . |
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 . |
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
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).
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 |
Allow to get feedback from the pagination stage back to the initial FO generation stage. If there was a standard way to do this we could develop, for example, multi-pass processes that could be conditioned on page layout results in a way that FO processes cannot be today except through proprietary extensions. It would also enable the development of, for example, loose-leaf publishing solutions. It might be as simple as standardizing the serialized representation of area trees or it might require the definition of some sort of input-structure to result page mapping format.
Below are some requirements that could be solved if there was a general mechanism to receive feedback from the pagination stage.
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 . |
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'.
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 . |
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:
Target Element | PDF Rendition | Anchor | Folio | Ordinal Page Number |
pub2.xml/section[@id='sec01'] | pub-1235-4567-01_v1.2.pdf | x476234 | 1-1 | 23 |
pub2.xml/section[@id='sec02'] | pub-1235-4567-01_v1.2.pdf | x679871 | 1-13 | 36 |
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 . |
Defining units of measurement in XSL-FO. This can currently already be be done in XSLT or by using XML entities.
Add support for multi-column layout in block-containers. Currently, only regions can have multiple columns.
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. |
Add support to specify a background-color on fo:change-bar.
Editorial note: Klaas Bals | |
Eliot Kimber suggested this. |
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.
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)
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).