Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The XSL 1.1 specification 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. There are two parts to XSL: XSL Transformations (XSLT) for transformation of documents and XSL Formatting Objects (XSL-FO) for formatting of documents. This is the requirements document for XSL-FO and not for XSLT.
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 is a First Public Working Draft of "Extensible Stylesheet Language (XSL) Requirements Version 2.0" which is expected to become a Working Group Note.
The XSL WG has provided a unique opportunity to provide feedback to the working group through a W3C Requirements Survey found at http://www.w3.org/2002/09/wbs/1/xslfo20requirements/ . Please take the time to fill out the survey and help us understand your priorities for the next release of XSL formatting objects. Additional comments and feedback on individual requirements should be provided using the W3C public Bugzilla system . If access to the bugzilla system is not feasible, you may send your comments to [email protected] . Each bugzilla entry and email message should contain only one error report. It will be very helpful if you include the string [FO2.0Req] in the subject line of your report, whether made in Bugzilla or in email. Archives of the comments and responses are available at http://lists.w3.org/Archives/Public/xsl-editors/ .
This document was developed by the XSL Working Group as part of the W3C XML activity .
This requirements document introduces planned new work for XSL-FO 2.0.
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 was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. 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
1.1 Feedback
1.2 Writing modes
2 Pagination and Layout
2.1 General Region
2.1.1 Non-rectangular areas
2.1.2 Add text to path
2.1.3 Runarounds
2.1.4 Copyfitting
2.1.5 Properties at non-tag boundaries
2.1.6 First line indent on first line of page, region or column
2.1.7 Initial Caps
2.2 Pages
2.2.1 Footnotes
2.2.1.1 Column wide
2.2.1.2 Multiple columns
2.2.1.3 Table footnotes
2.2.1.4 Coalescing footnotes
2.2.1.5 Restart numbering
2.2.1.6 Maximum size
2.2.1.7 Other properties
2.2.1.8 Properties from area tree
2.2.2 Floats
2.2.2.1 Page wide and column wide floats
2.2.2.2 Floats alignment
2.2.2.3 Stack floats
2.2.2.4 Distance of floats
2.2.3 Marginalia
2.2.3.1 Keep marginalia together with other objects
2.2.3.2 Large marginalia
2.2.4 Vertical Positioning
2.2.4.1 Feathering
2.2.4.2 Correlating vertical position
2.2.4.3 Vertical alignment within a page or column
2.2.4.4 Vertical alignment specific for the last column
2.2.4.5 Vertical justification across pages and columns
2.2.5 Tables and lists
2.2.5.1 Decimal alignment
2.2.5.2 Table header/footer on boundaries
2.2.5.3 Split tables
2.2.5.4 Repeat contents of split spanned cell
2.2.5.5 Cell borders extending beyond the table
2.2.5.6 Adjacent borders
2.2.5.7 Borders on break
2.2.5.8 Spanning cell over all row and columns
2.2.6 Side-by-side
2.2.7 Numbering
2.2.7.1 Additional numbering
2.2.7.2 Cross-references to other numbers
2.2.7.3 Calculations with page numbers
2.2.7.4 Multiple sets of page numbers
2.2.7.5 Control increments of page numbers
2.2.8 Cross-references
2.2.8.1 Textual cross-references
2.2.8.2 Cross-reference to a specific region on a page
2.2.8.3 Cross-reference ranges and coalescing
2.2.9 Markers
2.2.9.1 List all markers
2.2.9.2 Organize all markers
2.2.9.3 Coalescing markers
2.2.9.4 Generalized markers
2.2.10 Text before or after a break
2.2.11 Columns
2.2.11.1 Column balancing
2.2.11.2 Column spanning
2.2.11.3 Spanning columns in nested formatting objects
2.2.11.4 Strong vs. weak spanning
2.2.11.5 Multiple columns of different widths
2.2.11.6 Multi-column layout in all regions and block-containers
2.2.12 Layout master set
2.2.12.1 Interleaving layout-master-set
2.2.12.2 Repeatable sub-sequence-specifier
2.2.12.3
Change master every
n
pages
2.2.12.4 Background content
2.2.13 Variable-sized regions
2.2.14 Adjustable Region Sizes
2.2.15 Binding edge
2.2.16 Multi-directional page collation order
2.2.17 Spreads
2.2.18 Bleeds
2.2.19 Synchronize text of flows
2.2.20 Total block-progression-dimension
2.2.21 Different page geometry based on flows' content
2.2.22 Relationship of two objects
2.3 Feedback from pagination stage
2.4 Document collection
2.4.1 Master index
2.4.2 Hyperlink management
3 Expressions
3.1 Including information from formatting time
3.2 Pagination information
3.3 Output result of expression
3.4 User defined units of measurement
3.5 Getting values of properties
4 Inheritance
4.1 Inheritance down area tree
4.2 Inheritance at reference area boundaries
5 Composition
5.1 Fonts
5.1.1 Improved font support
5.1.2 Unicode ranges
5.1.3 Font dependent on script or language
5.1.4 Font specific features
5.1.5 Kerning
5.1.6 Ligatures
5.1.7 XSL-FO inside other languages
5.2 Force line justification
5.3 Alignment around breaks
5.4 Hanging punctuation
5.5 Tabs and tab stops
5.6 Word and letter spacing
5.6.1 Word and letter spacing exclusions
5.6.2 Punctuation spacing
5.6.3 Specify priority between word and letter spacing
5.7 Hyphenation and line breaking
5.7.1 Number of syllables
5.7.2 Syllable widows
5.7.3 Hyphenation exceptions
5.7.4 Line breaks without hyphen character
5.7.5 Word widows
5.7.6 Minimum length of last line
6 Further improved non-Western language support
7 Images
7.1 Cropping images
7.2 Rotate images in 90 degree increments
7.3 Rotate images over arbitrary angles
7.4 Callouts
7.5 Multi-page images
8 Improvements for specific output formats or devices
8.1 Annotations that appear in output
8.2 Base URL
8.3 Print specific properties
8.4 Marks for paper folding machines
9 Rendering
9.1 Animations with graphics
9.2 Other types of animations
9.3 Z-index
9.4 Border styles
9.5 Rounded corners
9.6 Color support
9.6.1 Transparency
10 Collaboration with SVG
10.1 Masks
10.2 Rotations
10.3 Transformations
11 Other
11.1 Foreign objects
11.2 Metadata on objects
11.3 Generalized metadata
11.4 xml:base
11.5 Schema for XSL-FO
11.6 Compatibility
14 References
The W3C is in the process of developing the second major version of XSL-FO, the formatting specification component of XSL. XSL-FO is widely deployed in industry and academia where multiple output forms (typically print and online) are needed from single source XML. It is used in many diverse applications and countries on a large number of implementations to create technical documentation, reports and contracts, terms and conditions, invoices and other forms processing, such as driver’s licenses, postal forms, etc. XSL-FO is also widely used for heavy multilingual work because of the internationalization aspects provided in 1.0 to accommodate multiple and mixed writing modes (writing directions such as left-to-right, top-to-bottom, right-to-left, etc.) of the world's languages.
The primary goals of the W3C XSL Working Group in developing XSL 2.0 are to provide more sophisticated formatting and layout, enhanced internationalization to provide special formatting objects for Japanese and other Asian and non-Western languages and scripts and to improve integration with other technologies such as SVG and MathML.
A number of XSL 1.0 implementations already support dynamic inclusion of vector graphics using W3C SVG. The XSL and SVG WGs want to define a tighter interface between XSL-FO and SVG to provide enhanced functionality. Experiments with the use of SVG paths to create non-rectangular text regions, or "run-arounds", have helped to motivate further work on deeper integration of SVG graphics inside XSL-FO documents, and to work with the SVG WG on specifying the meaning of XSL-FO markup inside SVG graphics. A similar level of integration with MathML is contemplated.
The XSL WG has provided a unique opportunity to provide feedback to the working group through a W3C Requirements Survey found at http://www.w3.org/2002/09/wbs/1/xslfo20requirements/ . Please take the time to fill out the survey and help us understand your priorities for the next release of XSL formatting objects. Additional comments and feedback on individual requirements should be provided using the W3C public Bugzilla system . If access to the bugzilla system is not feasible, you may send your comments to [email protected] . Each bugzilla entry and email message should contain only one error report. It will be very helpful if you include the string [FO2.0Req] in the subject line of your report, whether made in Bugzilla or in email. Archives of the comments and responses are available at http://lists.w3.org/Archives/Public/xsl-editors/ .
We use terms like top, bottom, vertical and horizontal in this document to be easy to understand. We know that when we write the specification, we have to talk in terms of before, after, start, end, block-progression-direction, inline-progression-direction etc, the same as XSL 1.0 and 1.1 did.
Add support for non-rectangular areas wherever appropriate. This is for areas where the content needs to be flowed inside an non-rectangular shape.
Run text on a path including flowing from one path to another. This goes further than simply including SVG, as we're also supporting the line breaking rules that XSL-FO provides. Text should be able to flow from one line to the next line of the multiline paths but it needs to be explicitly specified what each line of the path is, as we do not intend to stack paths automatically. The intent is to apply the normal line building properties to text on a path.
Add support for runarounds or intrusions (text flowing around illustrations, regions and other objects). This is related to effects obtained by overlapping areas of either rectangular or non-rectangular shape in any suitable combination, but it doesn't really require non-rectangular areas.
Allow one object to intrude into another:
Support multiple intrusions
Support intrusions into all 4 sides
Support specifying pull-quotes without the need to repeat the content of the pull-quote. This is related to 2.2.9.4 Generalized markers
Support cut-outs
The objects (both the intruder as well as the object intruded upon) may be of arbitrary shape.
Allow users to specify the relations between the objects that are impacted by the intrusion:
Specify where the objects should be positioned. The objects may be relatively or absolutely specified.
Specify separation/gap between intruders & other regions.
The intruder's size may be pre-defined or specified dynamically. It may be a region or a flowing object. An example of a dynamically sized object is a pullquote where the size of the pullquote depends on the amount of text, or a graphic where the size of is dependent on the external graphic.
Specify a priority between objects
Specify a keep/anchor between the text and the intruder. This is related to 2.2.22 Relationship of two objects
Add support for copyfitting, for example to shrink or grow content (change properties of text, line-spacing, ...) to make it constrain to a certain area. This is going to be managed by a defined set of properties, and in the stylesheet it will be possible to define the preference and priority for which properties should be changed. That list of properties that can be used for copyfitting is going to be defined.
Additionally, multiple instances of alternative content can be provided to determine best fit.
This includes copyfitting across a given number of pages, regions, columns etc, for example to constrain the number of pages to 5 pages.
Add the ability to keep consistency in the document, e.g. when a specific area is copyfitted with 10 pt fonts, all other similar text should be the same.
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.
Allow users to specify that first line indent should be different on the first line of a page, region or column. This is a specific case of 2.1.5 Properties at non-tag boundaries and is also related to 5.3 Alignment around breaks .
Add support for raised initial capitals and n -line dropped capitals. This includes support for the first n characters. See also 2.1.5 Properties at non-tag boundaries .
Add support for multiple columns in the footnote region, where the number of columns may be different from the number of columns in the page.
Add support for table footnotes. These are footnote bodies that get rendered within the table (as opposed to at the bottom of the page) when the footnote reference appears on the table fragment on that page.
Add support for coalescing footnotes. This means that the same footnote should only be shown once when it appears multiple times on the same page.
Allow users to specify the maximum size of the footnote area in relation to the body and for footnotes to continue on the next page.
Allow users to specify other properties of the footnotes, such as margins, spacing etc.
Add support for specifying properties such as the fontsize of footnotes to be taken from the area tree, instead of from the formatting object tree. This is related to 4 Inheritance .
Improve support for floats. Currently we can only float to the top.
We should differentiate page wide, column wide or n -column wide floats.
Add support for marginalia.
Keep marginalia together with other objects, such as blocks or inlines. We should specify the alignment of the marginalia, as this is typically a smaller font size. For example align the baselines, align the top of the two lines, etc. Support a variety of positions of marginalia, e.g. position them at the left on a left-hand page and at the right on a right-hand page.
Note:
In some cases, marginalia are seen as an alternative to footnotes, so some footnote properties should also apply to marginalia, for example numbering and restarting numbering.
The following graphic show an examples of marginalia:
The following picture shows collision of 2 marginalia:
This graphic shows marginalia on the two sides of the flow:
This graphic shows an example of the relative alignment of the marginalia and the text. At the top of the page, the first lines of the marginalia and the text are aligned at the before-edge. When in the middle of the page, the first line of the marginalia and the corresponding line of the text are visually aligned on a particular baseline (in the case of mixed text).
If marginalia become larger than the space on the page, they should force the text and/or the related marginalia to move to the following page. Also permit breaking of marginalia.
This graphic is showing the situation where some breaking is preferable:
This graphic shows one solution, by breaking the flow so that the entire marginalia is brought to the next page, together with the text it belongs to:
This graphic shows another solution, by breaking the marginalia:
Add support for feathering, to vertically adjust lines. Feathering is vertical justification with very small amounts.
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 (this is a common requirement when the sheets of paper are very thin).
Add support for vertical alignment, such as centering the content of the columns or aligning to the bottom within pages, regions or columns.
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.
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.
Allow users to specify that tables can be split horizontally. It should be possible to have a column repeated when the table is split horizontally, by specifying a row header. There should be a way to keep the split parts visually next to each other depending on binding edge.
In case a table is split over multiple pages and both the rows and columns don’t fit a page, allow users to specify which table part comes out in which order (rows first or columns first).
This graphic shows a table before it is split. Neither all of the rows, nor all of the columns fit on one page, so the table needs to be split.
The following graphics show 4 pages that contain the split table. The order in which the pages will come out depends on the users preference, and the two alternatives are marked with green (columns first) and blue (rows first) numbers.
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.
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.
When one formatting object is immediately preceding another in block-progression-dimension, be able to specify what to do with their adjacent borders.
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.
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.
Introduce a way to position objects next to each other. Side-by-side includes complex positioning and breaking rules (in some cases similar to the constraints necessary for marginalia).
Add support for line number, column number and region number. For example number only every fifth line, etc.
The following are requirements for line numbers, but they apply to columns numbers and region numbers as well:
Line numbering side (start/end/...)
Line numbering separation -- distance of number from the text
Line numbering format (1, 2, 3...; 001, 002, 003...; A, B, C...)
Line numbering text properties (font-family, font-size, ...)
Starting line number -- 1 by default, but can be changed by user
Continuation -- should numbering continue from previous object, or should be restarted
Line numbering restart -- where numbering restarts (document, page-sequence, object, page, column)
Line number only each n -th number
Line number separator
Line number alignment
Allow users to make cross-references to anything that can be numbered, such as the numbers introduced in 2.2.7.1 Additional numbering .
It should be possible to do calculations with page numbers. For example to determine the number of pages in a section.
Have multiple series of page numbers in the whole document that can be output on selected pages (even outputting multiple page numbers on the same page). As an example, take the case where a document contains both a letter and a contract. In that case, you want to be able to have a page number starting from 1 for the entire document, that is also output on all pages, as well as a page number starting from 1 for just the contract that is only output on the pages of the contract.
Specify that page numbers should not increment on certain pages.
For example, the case where back side containing the 'conditions of sale' shouldn't be numbered and thus the page number shouldn't be incremented. A document containing 4 pages, page 1 with page number '1', page 2 being the back side of page 1 containing conditions of sale and not numbered, page 3 with page number '2', page 4 being the back side of page 3 containing conditions of sale and not numbered again. What is actually being accomplished is simulating printing a 2 page document (with page numbers 1 and 2) on 2 sheets of preprinted paper, each containing the conditions of sale on the back side.
We want the formatter to detect where the cross-referenced object is located (e.g. where on the page, or on which page such as the previous page). We want to allow the insertion of variable text for cross-references depending on both the page number on which the cross-reference appears and the target page, for example 'see previous page' or 'see opposite page'.
Extend retrieve-marker and retrieve-table-marker to enable listing all markers on the page (e.g. to list all index terms on the page or show a list of destinations in a list of hotels). Provide in a way to ‘carry-over’ the markers from previous (not following) pages. This should be done in all cases, not just in the case the current page contains no markers.
When retrieving all markers of a page, add the ability to organize them. This includes removing duplicates, sorting markers and indicating how to format them (e.g. each marker on a separate line or separated with commas).
Markings at particular page, column, table (horizontal and vertical) or region breaks. For example add text ‘continued on next page’ or ‘continued from previous page’. The text may be just fixed text, or retrieved from the page or a cross-reference.
Allow the span property to have effect when specified on formatting objects that are not direct children of an fo:flow.
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.
Have sets of pages repeatable within the same page-sequence.
Allow specifying that every n -th page, a different master should be used. This is a specific case of 2.2.12.2 Repeatable sub-sequence-specifier . For example, use master A for page 1, 2, 3, 4, then master B for page 5, then master A again for 6, 7, 8, 9 then master B for page 10, etc...
Dynamically size the region-start, -end, -before and -after so that it sizes according to the content of the region. This may well be not applied to the current simple-page-master. This is a simple case of 2.2.14 Adjustable Region Sizes for the case where the page has a typical 'border layout'.
Support specifying which edge remains in its original position and which edge moves when the region grows (or multiple edges may move). This applies to all of the dimensions. Related to this is the notion of an anchored edge that can be anchored with respect to the page or with respect to another area. Some overlapping may occur with other regions that aren’t part of the specified constraints. The anchors are related to 2.2.22 Relationship of two objects
Add support for specifying the binding edge. This is related to duplex/simplex of 8.3 Print specific properties .
Add support for multi directional page collation order in a single document. For example a single book where the front part starts in one language and the backside starts from another language. Another example is that of Japanese magazines that combine vertical layout from the back and horizontal layout from the front.
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.
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. It has got to be in the context of the output media, so this is related strongly to 8.3 Print specific properties .
Synchronize the text of flows that have a relationship to each other, and specify how near or how far they can go from each other. The relationship between the text of the two flows may also be expressed using some form of anchors. This is related to 2.2.22 Relationship of two objects .
For example, this is needed to keep two translated paragraphs next to each other in a two column document where one column is in one language and another column in another language.
Allow users to specify the sum of the block-progression-dimensions of the generated areas instead or in addition to specifying the block-progression-dimension of each generated instance.
Support different page geometries based on the flows that have been exhausted and those that have still content to be placed. For example, when having two regions A and B, both laid out next to each other on a single page, once flow A is exhausted, make B use the entire available space on the page.
Give the ability to use information from the pagination step of one formatting episode in determining layout of the following formatting episode. This ability also allows making changes to the pages, reordering pages, merging multiple flows and do many other post processing tasks. One example of using XSL-FO for this is by representing the result of the first formatting episode each formatted page in a separate page-sequence, so that when this XSL-FO instance is fed into an XSL-FO formatter again, the same amount of pages would be generated as there are page sequences in the XSL-FO instance.
As a specific example, take the process that involves sending out a letter followed by a contract for a large number of customers. This involves an envelope machine that will take the individual sheets of paper and put them in an envelope. This process has the additional constraint that an envelope can only hold n pages, so when the letter + contract contain more than n pages, and extra sheet of paper must be produced that contains the address again, so that this contract can be sent in multiple envelopes. This envelope machine is typically driven by OMR marks, which are lines or markings on the paper that indicate which is the first/last page of the envelope. These markings typically also include a checksum that contains the sheetnumber so that the envelope machine can detect when it took two sheets at the same time. Adding these markings to the output involves logic that needs to know how many pages are generated.
The working group will investigate relationships between multiple input documents and multiple output documents.
The term 'document collection' refers to a document that is actually composed of multiple documents. Once this concept of ‘document collection’ is defined, we can add features that need the relationships between multiple documents such as a master index or hyperlink management.
Modify the expression language to allow expressions that include information that’s only available at formatting time.
Some examples of this are the size of a block, the height of a line, etc.
Be able to compute expressions that are based on information that is only available after the pagination stage. For example, this allows to calculate the subtotal of the current page (as opposed to a running total that is already supported in XSL 1.1 with table markers). Once this expression can be calculated, you can use 3.3 Output result of expression to output its result .
Allow users to output the result of expressions on area tree, traits, markers or text content. For example 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).
Inheritance of properties down the area tree (as opposed to the formatting object tree in previous versions of XSL).
One example of this is inheritance with footnotes that should inherit the properties of the footnote are as opposed to the properties of the area in the body that contains the referenced text.
Another example is the case where there are two regions on a page that contain the flowed text (text is flowed for to Region A, then to region B). Region A has a black background and region B has a white background. The text color should be white in region A and black in region B.
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. For more information on SVG fonts, see Chapter 20 of SVG 1.1 .
Use a different font-family (already supported by SVG) and different font-size (not yet supported by SVG) for characters depending on the Unicode range.
Make font-size and font-family dependent on the script or language.
Add additional properties to give access to font specific features, e.g. in initial swash caps, oldstyle figures, and/or other features such as those available in OpenType.
Allow users to specify constraints to control ligatures, like forcing the use of ligatures, or avoiding the use of ligatures even though they are available. This requirement includes the large number of parameters that may be necessary to control ligatures for those languages where the ligatures are font dependent, such as Arabic.
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.
Currently XSL has justification parameters for 'all text but the last line' and the 'last line'. Add properties to specify what the alignment should be for the 'last line before a break' and the 'first line after a break'.
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.
Allow excluding specific characters or Unicode classes (for example numerals) from word and 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 specifying the number of syllables in addition to the number of characters to control hyphenation.
Note:
We are concerned how to divide things reliably in syllables. (This requirement comes from the Print Workshop in Heidelberg.)
Add syllable level widow and orphan controls. We can only do this if we implement 5.7.1 Number of syllables .
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.
Allow the specification of a set of characters after which the composition process may introduce a line break without inserting a hyphen character. For example for '/' characters in URLs.
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.
This document will be an input to the XSL working group as a source of requirements.
Cropping images, including bleed and non-rectangular cropping. See 2.2.18 Bleeds and 10.1 Masks .
Add support for adding annotations that appear in the output, e.g. comments or text highlighting in PDF.
Add support for setting the base URL for output formats that support this, such as PDF or HTML.
Specifying print specific properties such as the following.
Input/output trays
Duplex/simplex
Dpi depending on output format
Grayscaling or patterns or colors
Glossy paper (has influence on formatting as well)
Crop marks
Registration marks
Bleeds (also described at 2.2.18 Bleeds )
This will probably be done with a Job Control specification such as JDF.
Add support for animations contained within the graphics.
Note:
This could be related to 10 Collaboration with SVG .
Add support for other types of animation. For example an ant crawling around the borders of a table, a business chart with drilldown/zoom functionality, go to next page every 3 seconds.
Note:
This could be related to 10 Collaboration with SVG .
Improve absolute position, layering and positioning by extending the Z-index property so that it can cross formatting object boundaries. Also support z-index on regions (also required for more complex page layout).
You should be able to specify these border styles for individual borders or individual corners. Patterns may be segmented, so that we have different borders for the corners etc.
Add support for extensible border patterns, e.g. with numbers and thicknesses of lines, dashes.
Tiled graphics and images as borders, for example, for borders typically surrounding a stock certiticate.
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. Working with SVG is part of the solution to other requirements outlined in this document.
By implementing XSL-FO and SVG, some of the extra conformance criteria that apply are inheritance at language boundaries, SVG transformations of XSL-FO result renditions, nesting languages.
One example of how SVG and XSL-FO can be used is shown in this picture, coming from the SVG Print 1.2 Primer dated 21 December 2007 .
Improve the embedding of foreign objects inside XSL-FO to allow a tighter coupling. Examples of these are SVG, MathML, XForms, etc.
Specify metadata that may influence the output, like PDF keywords, producer, etc., or be used for other purposes.