XSL-FO is the part of XSL that actually describes how a document should be formatted. It is based on a word-processing model for page layout as opposed to a desktop publishing model. As such, it is nearly impossible describe the exact positionings and layout of the text of a document. Instead, XSL-FO involves giving a general description of how text should be arranged in relation to other text, and the XSL-FO engine will choose an appropriate arrangement, much like Microsoft Word, Latex, or other programs based on a word-processing model. For complete control over the layout of a document, document designers still have to resort to other file formats like .pdf files.
The easiest way to understand the nature of XSL-FO is to look at an example. XSL-FO documents typically end with a .fob, .fo, or .xml ending. Like all XML, documents, an XSL-FO document requires a namespace and root node, as shown in the figure below:
|
The above figure uses fo to denote the formatting objects namespace and has a root node within which all the XSL-FO commands should appear.
As mentioned earlier, XSL-FO borrows its page formatting from DSSSL. DSSSL uses the desktop publishing concept of "master pages" for describing how pages should be laid out. Master pages are basically templates for how different types of pages should look. For example, in the diagram below, you will notice a distinct difference between the layouts of the front cover, back cover, left pages, and right pages of a book. Odd numbered pages have a "gutter" (an area set aside for the stitching necessary to hold a book together) on their right while even numbered pages have a gutter on their left. All the odd-numbered pages do have a similar format though as do the even-numbered pages. As such, a master page or template for all the odd pages and another master page for all the even pages can be defined describing how odd-numbered pages and even-numbered pages should be laid out.
At the start of an XSL-FO document, you have a describe the master pages used in the document. The description of the various master pages must occur within a layout-master-set tag. The example here will just use a single type of master page called "basepage" which will have a one inch margin running around its border.
|
Once the master pages are defined, it's then possible to put text onto these pages. To lay out text, one first has to define which master page should be used by defining a page sequence. Then, one defines a flow-some consecutive text that should be laid out across the pages defined. This text is then divided into individual paragraphs or blocks in XSL-FO terminology. Each block results in a new paragraph. Blocks can be further subdivided into inline regions for individual words, sentences, or other arbitrary sections within that block. The text in flows, blocks, and inlines can have text properties attached to them such as font size or font type. By default, these text properties are inherited by all text within those regions, but they can be overridden by giving new properties for these sub-regions. Below is an example of XSL-FO which defines two paragraphs, changes the size of the text in the middle of the second paragraph, and embed a small graphic in the document.
|
From the above figure, it should be apparent that XSL is very much like html/css in its terminology and nature. XSL-FO provides lots of control over how text should flow but doesn't provide exact control over layout.
There are several outstanding issues with XSL-FO, however. Many XML trade magazines and journals describe XSL as being the eventual replacement for HTML. Unfortunately, these issues may hinder the adoption of XSL-FO. The specification for XSL-FO is 400 pages long, and there are very few implementations of this specification. What implementations are available tend to focus on producing paged documents in .pdf format. At this point, it is not clear whether the lack of implementations is due to developers being reluctant to tackle the complexity of designing an XSL-FO renderer or whether there are some inherent flaws with the XSL-FO specification.
In addition, the XSL specification isn't clear on how to handle different media. For a web page, are you supposed to have one stylesheet for printing and another stylesheet for rendering to the screen? Or are you supposed to have one generic stylesheet for the document, and the renderer will interpret the instructions for page layout appropriately when displaying the document in a web browser? If you are designing documents only for the web, is it necessary to make use of the master page tags and exactly define the layout of the document or is it possible simply to supply the text without information about pagination?
Also, by being based on the CSS, XSL-FO inherits some of the weaknesses fundamental to CSS. Documents on the web typically come in two types: those that contain a lot of text and information and those that are interfaces for navigating a website. In the latter case, it is important that all the elements of the interface are laid out properly and are laid out in a device independent manner. One way to achieve device independence is to arrange document elements using device independent coordinates such as inches or centimeters. CSS and XSL-FO both permit this, but they do not provide any tools for guaranteeing that text will fit within a certain region of the document. If you're drawing a 2cm button on a web page and want some text to fit inside of it, CSS and XSL-FO do not provide the facilities for ensuring that the text will fit within the button. The text may be 1cm wide or it may be 3cm wide. The web page designer simply has no control over this. As such, one is forced instead to lay out elements using a generic constraint system where buttons and other elements will resize themselves to accomodate the size of text. Unfortunately, this is extremely challenging in general and is made even worse by XSL-FO and CSS because of the very primitive tools they provide for doing this. They simply weren't designed with heavy constraint based layouts in mind, so designers often have to resort to a complicated mix of regions, sub-regions, and tables to create a well-designed device independent interface from the specification.